Ask any actuarial modeling team what happens when the mortality table gets updated, and you'll hear something like: "We'll use the new one from the next valuation date." Ask the data team what happens to the reserves calculated last quarter under the old table, and you'll get a shrug. Ask the IFRS 17 team what happens to the CSM roll-forward that already closed, and you'll get a longer, more nervous pause.
This is the actuarial assumption change problem. It is not a modeling problem. It is a data lineage problem dressed up as an actuarial one, and almost every life insurance and pension company I've seen in Turkey handles it the same way: apply forward, ignore backward, hope no one reconciles.
An assumption is not a parameter — it is a coordinate
When you change a mortality table — say, moving from CSO 2001 to a locally-calibrated 2015-2020 experience table, or shifting the improvement scale on an annuity book — you are not adjusting a knob on a model. You are redefining the coordinate system in which every past reserve calculation lived.
The reserve for a 45-year-old male annuitant computed in Q2 was not just a number. It was a number that meant something given a specific mortality assumption, a specific discount curve, and a specific lapse table. Change any one of them, and the historical number no longer maps cleanly to the current one. The delta between the two is real economic information — it belongs somewhere in the financial statements or the disclosure notes — but most pipelines have no place to put it.
Where the propagation actually hits
A mortality table update in a life or pension carrier propagates into at least five places, and rarely into all of them coherently:
- Statutory reserves. The BEL and risk margin under Solvency II or the local equivalent (in Turkey, the SEDDK technical provisions framework) need to be re-run. Fine — that's what actuarial valuation systems do.
- GEV / EEV submissions. The embedded value roll-forward has an "assumption change" line specifically for this. It expects you to quantify the effect. That means you need the old model and the new model to both be runnable on the same opening portfolio.
- IFRS 17 measurement. Under the General Measurement Model, changes in non-financial assumptions adjust the CSM. Under the Variable Fee Approach, they might hit P&L directly. The distinction depends on whether the change relates to future service — which requires you to attribute the delta by cohort, by contract group, and by coverage period.
- Reinsurance treaty accounting. If the ceded portion uses a different assumption basis, you now have a gross-versus-ceded mismatch that has to be explained.
- ALM and hedging. The duration and convexity of the liability book shifts. If someone was hedging on last quarter's numbers, they're now hedging a portfolio that no longer exists in that form.
Each of these consumers needs a different slice of the same assumption change event. And each of them typically pulls from a different downstream mart.
The pipeline pattern that fails
The standard architecture I keep seeing:
- Actuarial system holds the assumption tables as reference data, versioned by "effective date."
- Valuation runs pick up whichever version is active on the run date.
- Results land in a reserves mart, keyed by policy and valuation date.
- Downstream reports read from the mart.
This pattern silently assumes that assumption changes only affect future runs. It has no concept of "the same valuation date, recomputed under a new basis." When the actuary updates the mortality table, the old results in the mart are neither invalidated nor annotated. They just sit there, referenced by every historical report, quietly inconsistent with the new basis.
When the internal audit team or the regulator asks: what would the Q2 reserves have been under the current mortality assumption? — the honest answer is usually that no one can produce it without a special project.
What the pipeline should actually track
An assumption change is a first-class event. It deserves its own table, its own audit trail, and its own downstream fan-out. Concretely:
- Every valuation result needs two dates, not one. The valuation date (what point in time is being measured) and the basis date (which set of assumptions is being applied). A Q2 reserve computed under the old table and the same Q2 reserve recomputed under the new table are two different rows, not one row overwritten.
- Assumption sets should be immutable and versioned. Not by "effective date" alone, but by a basis identifier that never changes once published. When actuarial republishes a corrected table, that is a new basis, not an edit to the old one.
- Every downstream report should declare which basis it was produced under. The GEV submission for Q2 was produced under basis v14. When basis v15 is adopted, the system should be able to regenerate Q2 under v15 for comparison, without touching the original v14 output.
- The delta between bases is a computed artifact, not a manual reconciliation. It should fall out of the same infrastructure that produced the original numbers.
The Turkish regulatory context makes this worse
Local experience tables are less mature than SOA or CMI equivalents, so tables get updated more frequently as experience data accumulates. Pension companies operating under the BES framework have annuity conversion assumptions that shift as the population data improves. Life carriers using foreign group tables adjusted with local factors face an even messier version: the base table changes on one cycle, the adjustment factors on another.
Every one of those changes is an assumption event. Every one of them requires a delta calculation that most systems cannot produce cleanly. And under IFRS 17, which most Turkish insurers are still stabilizing, the CSM attribution of these changes is auditable in a way it never was under the previous local GAAP.
The uncomfortable question
If your regulator asked tomorrow for a bridge between last year's closing reserves and this year's opening reserves, decomposed by: model changes, assumption changes, experience variance, and new business — could your data pipeline produce it without a two-month manual project?
For most life and pension companies I've worked with, the answer is no. Not because the actuaries don't understand it, but because the data infrastructure was built as if actuarial assumptions were configuration, not history.
They aren't configuration. They're part of the coordinate system every reserve number lives inside. When you change them, you don't just update a parameter — you rewrite the meaning of every historical number in the book. The only question is whether your pipeline knows it.