Actuarial Cash Flow Projections Under IFRS 17: What the Projection Engine Actually Has to Produce

Once the strategic question of whether to extend or replace the actuarial model has been settled, a different problem surfaces almost immediately on any IFRS 17 build. The projection engine has to produce cash flows in a very particular shape for the measurement engine downstream. If those outputs are not right — at the right granularity, with the right decomposition, on the right discount curves, and on the right timing grid — the CSM engine cannot do its job. The measurement process breaks silently, usually at month-end, usually close to reporting day.

What follows is the operational view of what the actuarial cash flow projection engine has to produce under IFRS 17. This is not the gap-analysis of what existing models can and cannot do. It is the next question: if the engine can be made to produce what is required, what exactly is it required to produce?

1. The output shape the measurement engine needs

The measurement engine downstream does not consume a single aggregated cash flow vector. It consumes cash flows decomposed into categories that map to the IFRS 17 disclosure requirements, by group of contracts, by period, on two discount curves.

In practice that means at minimum:

• Expected present value of future cash inflows
• Expected present value of future cash outflows, split between attributable acquisition cash flows, attributable expense cash flows, claims cash flows, and other benefit cash flows
• Investment component cash flows (the portion of claims cash flows that is not contingent on the insured event)
• The coverage unit pattern required for CSM release

Each of those outputs needs to be produced per IFRS 17 group. Many projection engines built before the standard produce aggregate cash flows only, or aggregate at a policy-file level that does not align with the grouping rules. Reconstituting the decomposition after the fact is possible but fragile — it introduces an allocation layer that auditors then have to trace on every close.

2. Timing: valuation date versus accounting period

The actuarial projection has a valuation date. The measurement under IFRS 17 is for an accounting period. These two are not the same thing. The projection engine is being asked to support both: point-estimates at the valuation date, and period-movement between valuation dates.

The timing-grid issue surfaces in two places. First, the expected cash flow schedule has to be at a granularity the measurement engine can aggregate to accounting periods — monthly buckets are the practical minimum; annual buckets force the measurement engine to interpolate and that interpolation is not neutral for the CSM release. Second, the valuation-to-valuation roll-forward has to reconcile. If the opening cash flows on the current run do not tie to the closing cash flows on the prior run (after experience adjustments), the CSM engine cannot split the movement into unlocking and non-unlocking categories cleanly.

The practical test on an existing projection engine: run it at two consecutive valuation dates with the same assumptions and no experience. The cash flow schedule in the period should match exactly. If it does not, the engine is introducing noise that the measurement engine cannot reconcile.

3. Discount curve sourcing

For contracts measured under the General Measurement Model, the projection engine has to produce cash flows that can be discounted on two curves: the locked-in curve fixed at initial recognition (or at transition, depending on approach), and the current curve at the measurement date. The measurement engine needs access to both.

This means the projection engine cannot simply emit an expected-present-value number. It has to emit nominal cash flows, period by period, and let the measurement engine apply the right curve to the right movement class. Projection engines built for embedded value or Solvency II often work the other way — they bake the discount curve into the emitted present value — which means the downstream engine is working with curve-pre-applied numbers that cannot be unwound without re-running.

The curve sourcing question is not only the actuarial model’s problem. It is an integration problem. The projection engine has to know which curves are in scope, has to be able to persist the locked-in curve for every IFRS 17 group for the life of that group, and has to pass the curve identifier through to the measurement engine alongside the cash flows. That persistence is often where legacy projection setups struggle — they were never asked to hold a curve as a first-class artefact.

4. Cash flow decomposition for disclosure

The IFRS 17 disclosure requirements push the decomposition below what most projection engines track. Insurance acquisition cash flows have to be identified, separated, and projected. Non-attributable expenses have to be excluded. Investment components have to be split out of claims. For participating contracts, shareholder versus policyholder share of cash flows needs to be traceable.

The projection engine has three choices on each of these decompositions: produce them natively, produce them via tagging at projection time, or produce them through a downstream allocation layer. The first is most auditable. The second works if the tagging is deterministic and the tags survive the run. The third is the most common state on legacy engines and the hardest to defend in audit — an allocation layer that was not part of the projection is, in substance, an assumption applied after measurement, which the standard explicitly requires be documented as a methodology.

5. Reconciliation back to the roll-forward

The measurement engine will produce a reconciliation of opening CSM to closing CSM, categorised into experience adjustments, assumption changes, new business, and other movements. Every line in that reconciliation has to tie back to something the projection engine produced. If it does not, the explanation cannot be traced to source, and the actuarial function cannot sign off the disclosure.

The test for whether the projection engine supports this is practical: pull any line of the CSM reconciliation, walk it back to the specific cash flow movements that drove it, and see how many hand-offs sit between the disclosure number and the engine output. The target is one hand-off — projection output goes directly into the measurement engine, which produces the reconciliation. Every additional transformation layer in between is a place the reconciliation can drift.

Closing thought

The IFRS 17 projection engine is not a calculation; it is an interface. Most of the effort on a live implementation goes into making that interface reliable — getting cash flows out in the right shape, at the right granularity, on the right curves, in the right bucketing, with the right decomposition, reconciled period to period. The calculation itself, once the inputs are right, is straightforward. The difficult part is producing the inputs the downstream measurement engine is waiting for. Treating the projection engine as an interface problem rather than a calculation problem is how this part of the build actually closes.