An actuarial certificate signed under Turkish life and pension regulation is not a suggestion. It carries legal weight with EGM, it anchors technical provisions in the statutory accounts, it feeds the reinsurer's own reserving, and increasingly it sits under an IFRS-17 auditor's microscope. The number on that certificate is defensible. The dataset that produced it, in most Turkish pension and life shops I've seen, is not.
This is a specific kind of problem, and it is worth being precise about it.
The Certificate Is Reproducible. The Input Isn't.
When an actuary signs a certificate for a pension fund's technical reserves — BES katılım hesapları, garantili birikim ürünleri, annuity portfolios in payout phase — the sign-off attaches to a specific model run against a specific dataset at a specific cut-off. The model is versioned. The assumptions are documented in the technical memo. The output is archived.
What is almost never archived, in a way you can actually reload months later, is the dataset the model consumed.
What gets stored instead is one of:
- The source of truth at cut-off date (the policy admin system snapshot), which is not the same thing as what the model saw
- The aggregated result the actuary reviewed (cell-level reserves, mortality experience by cohort)
- A CSV extract dropped into a shared folder, sometimes on the actuary's laptop, sometimes in an email attachment
None of these is the intermediate state. The actual dataset the actuary signed off on lived somewhere between the extract from the policy system and the model input file, after cleansing rules, exclusion filters, cohort assignments, assumption mapping, and — critically — manual overrides applied by the actuarial team during the close.
Where the Reconstruction Breaks
Say EGM comes back in Q3 and asks a pointed question about a specific cohort in the year-end certificate. Or a reinsurer disputes mortality experience underlying a treaty renewal. Or the IFRS-17 auditor wants to trace CSM movement back to policy-level cash flows.
You go to reconstruct. Here is where it falls apart:
- The policy admin system has moved on. Surrender activity, fund switches, contribution changes, and status transitions all continued after cut-off. Point-in-time recovery may or may not exist. In some legacy systems it does not.
- The cleansing rules were code. Code that has since been updated. The rule that excluded a particular class of dormant contracts in December may have been rewritten in February for a different reason.
- Assumption tables were rebased. The mortality table version, the lapse assumption grid, the technical interest rate mapping — these are referenced by ID, and the ID may point to a newer row now.
- Manual overrides are undocumented. The actuary corrected 47 policies with garbage birth dates by hand in an Excel step nobody logged. Those corrections are not in the pipeline. They are in a file called
duzeltmeler_final_v3.xlsx. - The extract job itself is not deterministic. It runs against a live database with a
WHERE effective_date <= '2024-12-31'filter, which is fine, except that back-dated corrections booked in January change what that query returns in March.
So when you rerun the pipeline, you get a dataset that is close to what the actuary saw. Not the same. Close.
Why This Matters More Now
Two things have raised the stakes.
First, IFRS-17. The standard demands traceability from disclosed figures back to underlying cash flow inputs at a granularity Turkish life insurers were not previously asked to maintain. Auditors are not satisfied with "the model produced this number and the actuary signed it." They want to see the inputs.
Second, EGM's supervisory posture has shifted toward asking for post-hoc reconstruction of specific portfolio slices, not just re-signing of aggregate figures. When they ask why the reserve for a particular product line moved the way it did, "we can rerun the model" is not the answer they want.
What Actually Fixes It
This is not a modelling problem. The models are fine. This is a data engineering problem dressed up as an actuarial governance problem, and it needs to be treated as such.
Concretely:
- Snapshot the model input, not the source. The exact file the actuary signed off on — post-cleansing, post-override, post-cohort-assignment — should be immutable and stored with a hash. If it is not the artifact under version control, you cannot claim reproducibility.
- Version the cleansing code and pin it to the certificate. The pipeline that produced the input file should have a git SHA recorded on the certificate cover memo. Not "the pipeline as of December." A specific commit.
- Kill the Excel override step, or log it. Manual corrections during close are inevitable in Turkish market conditions — data quality in older policy admin systems is what it is. Fine. But every override needs to be captured as a structured delta file that is part of the archived input, not a laptop artifact.
- Freeze assumption tables by ID and date. Mortality tables, lapse grids, discount curves — each version needs an immutable identifier that never gets reassigned. The certificate references specific IDs.
- Point-in-time reconstruction is a design requirement, not a nice-to-have. If the policy admin system cannot reproduce its state at cut-off, that is an audit finding waiting to happen. Fix it, or build a parallel snapshot layer.
The Uncomfortable Part
Most of the actuarial teams I have worked with in Turkey know this. The senior actuaries know exactly which parts of their close process are fragile. The problem is that the fragility has never actually cost anyone anything — until IFRS-17, until an aggressive reinsurer, until a specific EGM inquiry. The pipeline was built to produce a number that would not be seriously interrogated. It is now being seriously interrogated.
The certificate is a signed legal opinion. Treat the dataset behind it with the same seriousness, or accept that the opinion is more certain than what it rests on.