Actuarial Modelling Gaps Under IFRS 17: What Existing Models Do Not Do

For most actuaries, the model is the fun part of the job. It is also the part of the IFRS 17 build that tends to surface the hardest strategic question: keep upgrading what you already have, or replace it with something purpose-built for the new standard. That question is not answered in the abstract. It is answered by walking through a specific list of things IFRS 17 requires the actuarial model to do, and checking — honestly — whether the model in front of you can do them.

What follows is the list I use when scoping this for clients. Each item is a real gap I have seen on live implementations across South Africa, Saudi, Malaysia, and Hong Kong. None of them are optional under the standard. What varies is how expensive they are to close inside an existing engine versus outside it.

1. Run order and analysis of change

IFRS 17 requires at minimum two classes of movement in the actuarial model: changes that unlock the Contractual Service Margin and changes that do not. For contracts measured under the General Measurement Model, the unlocking movements must be valued on locked-in discount rates, not current rates. That is a real constraint on the engine. It has to hold two parallel discount curves per measurement date and route each analysis-of-change step through the right one.

Most models built before the standard do not do this. They do a single-pass revaluation, output a movement, and move on. Splitting that movement into unlocking and non-unlocking categories, with discount-rate switching in between, is a structural change — not a post-processing fix.

On top of that, cash flows often need more granularity than the old model produced. Benefit outflow has to be split between amounts funded by underlying items and amounts funded by shareholders. Acquisition cash flows need to be isolated. Experience adjustments have to land in the right measurement-period bucket. The blanket question to ask is: can the current model run new run orders, under new financial assumptions, without hand-patched exports?

2. Level of aggregation

Under IFRS 17, the CSM is calculated at group level. For most insurers that level is below the level at which cash flow projections are currently performed. The model either needs to project at a lower level of granularity than before — in the limit, per contract — or the aggregation logic needs to be lifted outside the model into a downstream process.

The tradeoff is concrete. Per-contract projection gives the most flexibility for regrouping later. It also multiplies runtime and storage, sometimes by orders of magnitude. Group-level projection is faster but ties you to the grouping decision made at projection time, which is exactly the decision IFRS 17 does not want you to lock early.

The practical question: what is the lowest level at which the current model can produce projected cash flows, and how cleanly can it aggregate those cash flows across different granularities without re-running?

3. Profitability testing

The standard requires contracts to be grouped into onerous, no-significant-possibility-of-being-onerous, and remaining profitable cohorts at initial recognition. When the insurer does not have reasonable and supportable information to group at a higher level, this testing drops to the individual contract.

Contract-level profitability testing at portfolio scale is not a manual exercise. It has to be automated — policies tagged to cohorts by the model, tags persisted through projection, and the results fed back to the measurement process. If the existing actuarial model cannot tag and persist cohort membership through its run, that automation sits outside the model, and the risk of tag-drift between model and measurement becomes a reconciliation problem every close.

The right question to ask of an existing model: can it carry the group attribution through a projection, or does it lose it at every revaluation?

4. Simplification through grouping

If the model has to run contract by contract at every valuation, policy counts become a runtime problem quickly. The mitigation the standard allows is grouping — collapsing contracts into model points where reasonable and supportable information supports doing so.

Grouping is not a modelling trick; it is a data and governance exercise. It requires a rule for how the grouping is defined, evidence that the rule is reasonable, and a process that keeps the groups stable across reporting periods (or documents why they changed). The model is the consumer of the grouping, not the source of it. What it does need to do is accept grouped model points as input and preserve the linkage back to the underlying contracts, so the grouping can be unwound when regulators or auditors ask.

If the existing model’s model-point framework was designed for solvency or embedded value work, the linkage to underlying contracts is often implicit or missing. That is the gap.

5. Buy versus build

The three gaps above tend to make the build decision for you. More insurers I work with are treating IFRS 17 as the trigger to move off legacy actuarial platforms and onto vendor solutions purpose-built for the standard — with CSM engines, grouping modules, aggregation flexibility, and audit trails included in the base product.

Others, particularly those with strong in-house actuarial systems teams and modular existing platforms, have chosen to extend what they have. Both paths work. The decision framework I use is:

flowchart TB
    A[Starting model] --> B{Can it produce<br/>contract-level cash flows?}
    B -->|No| F[Replace]
    B -->|Yes| C{Can it run new run orders<br/>with locked-in discount rates?}
    C -->|No| F
    C -->|Yes| D{Can it carry group attribution<br/>through projection?}
    D -->|No| E{In-house team able<br/>to extend it?}
    D -->|Yes| G[Extend]
    E -->|No| F
    E -->|Yes| G
    F[Replace with vendor solution]
    G[Extend existing model]

The decision is not about which software is best in the abstract. It is about which of the five gaps you still have open, and whether the team you have can close them on the current stack faster than a vendor rollout would close them on a new one.

Closing thought

IFRS 17 did not politely extend existing actuarial models. It changed the run order, the discount-rate treatment, the level of aggregation, and the granularity at which profitability has to be tested. Models built to answer earlier questions — reserving adequacy, solvency capital, embedded value — are allowed to fail any of these new requirements, because the requirements did not exist when the models were specified.

The gap is not a failure of the existing models. It is a shift in what the actuarial model has to do. Treating IFRS 17 as the opportunity to name that shift honestly — and to decide, with eyes open, whether to extend or replace — is the most valuable piece of work the actuarial function can do in the first phase of a build.