IFRS 17 Insurance Systems Architecture: The Four Components That Have to Talk

By the time an insurer is past the gap analysis and financial impact assessment, the question shifts from “what does IFRS 17 require” to “what do we have to build, and how does it fit together”. The answer is a systems architecture — four connected components, each with its own inputs, outputs, and failure modes. Getting the architecture right is what separates a programme that reaches parallel-run quietly from one that spends the last six months fighting reconciliation breaks.

This post walks through those four components at the level I use when scoping a build. Not the full catalogue of everything IFRS 17 touches — the standard reaches into expense allocation, tax treatment, reinsurance, and plenty else — but the architectural core that every other piece depends on.

1. The actuarial model

The actuarial model is where expected cash flows come from. Under IFRS 17, it has to do several things that most pre-standard models were not built for:

• Project at the right level of aggregation. CSM is calculated per group of insurance contracts. If the existing model projects at a higher level, either it needs to drop to group (or contract) granularity, or an aggregation layer has to sit downstream. Neither choice is trivial.
• Run new analyses of change. IFRS 17 needs movements split between those that unlock the CSM and those that do not. Unlocking movements for contracts measured under the General Measurement Model have to be valued on locked-in discount rates. That is a structural requirement on how the engine handles discount curves — two parallel curves per measurement date, routed through the right steps.
• Model investment components. If investment components are present and were not previously modelled, that capability has to be added.
• Feed downstream components. The model is no longer the end consumer of its own output. Its cash flow vectors, coverage unit schedules, and movement breakdowns flow into the measurement engine, which means the output shape has to match what the measurement engine expects.

Most insurers handle this by either upgrading their existing actuarial software or buying off-the-shelf solutions built for IFRS 17. The decision depends on how much of the above the current model already does, and how extensible the underlying platform is. The honest version of the question is: can the current stack reach IFRS 17 on an acceptable timeline, or is replacement the faster path?

2. The measurement engine

The measurement engine — often called the IFRS 17 accounting engine in vendor marketing — is the component that takes projected cash flows, applies the measurement model rules, and produces the carrying amounts of the group of insurance contracts over time. Specifically:

• Fulfilment cash flows, including risk adjustment
• Contractual Service Margin and its roll-forward
• Liability for Remaining Coverage and Liability for Incurred Claims
• The journal entries that feed the subledger
• The disclosure tables the standard requires

This is the component where most insurers choose a vendor rather than build. The reason is that the rules are detailed, they interact in non-obvious ways (CSM unlocking order, loss component reversal, OCI option mechanics), and the vendor solutions have multiple production-grade implementations to point to. Building this in-house is possible but rare.

The measurement engine’s boundary with the actuarial model is the input specification — what cash flow shape, what cohort attribution, what discount curves. The boundary with the staging platform is two-way: inputs come in, results go back out, and the platform holds the long-memory state (opening balances, locked-in curves by cohort) that the engine needs for the next period.

The measurement engine’s boundary with the general ledger is the posting logic. The engine produces journal entries; the GL has to consume them. That boundary is where the GL integration work lives, and it is rarely simple.

3. The staging platform

The staging platform is the data backbone. It holds source extracts, transformed data for every downstream consumer, and results that flow back from upstream systems. Without a staging platform with clear contracts to every other component, the architecture becomes a point-to-point mess that cannot survive the first auditor walkthrough.

What the staging platform has to hold:

• Source data from policy administration, claims, and general ledger systems, refreshed on the reporting cadence
• Transformed data in the exact shapes the actuarial model and measurement engine require
• Results flowing back from the actuarial model (projected cash flows, coverage units) and the measurement engine (carrying amounts, journal entries)
• Reference data needed to tag contracts into portfolios and groups
• Locked-in discount curves by cohort, as long-memory state

The design question is usually whether this should be a single database with coherent API access, a data lake, or a collection of purpose-built marts. For a first-generation build the single-database-with-API pattern tends to win, because it concentrates administrator effort and spreads the running cost across every consumer.

What matters more than the technology choice is that the staging platform has a defined contract with every other component — published input formats, published output formats, versioned transformation logic, reconciliation checks between producers and consumers. Architecture without contracts becomes a distributed spaghetti problem.

4. The general ledger integration

The last component is the integration between the measurement engine and the general ledger. The measurement engine produces a subledger — IFRS 17-native journals, organised by its own chart of accounts, at the grain of group of contracts. The GL is the insurer’s enterprise chart of accounts, organised for statutory and management reporting. Those two rarely match.

The GL integration has three parts:

• Chart-of-accounts mapping. Each vendor has its own account structure. That structure has to be mapped to the insurer’s GL accounts, which is a one-off exercise that is less glamorous and more time-consuming than it looks. Every line item under the vendor’s IFRS 17 model has to end up somewhere the GL can recognise.
• Subledger-to-GL posting. Journal entries from the measurement engine’s subledger have to be aggregated and posted into the GL at the right frequency, in the right shape, with the right reference information for downstream reconciliation.
• Parallel-run support. During the transition period, insurers run IFRS 4 and IFRS 17 in parallel. The GL integration has to handle both. That often means running two sets of postings against shadow accounts in the GL, or standing up a parallel GL instance, until cutover.

This is the work most insurers leave until last. It tends to punish that sequencing. The components that integrate with the GL — the measurement engine on one side, management reporting on the other — both make assumptions about what the GL can accept, and those assumptions rarely hold without rework.

5. How the four components connect

Sketched at the level of input-output contracts, the architecture is:

flowchart TB
    SRC[Source systems:<br/>policy admin, claims, GL extract]
    STG[Staging platform]
    AM[Actuarial model]
    ME[Measurement engine]
    GL[General ledger]

    SRC --> STG
    STG --> AM
    AM --> STG
    STG --> ME
    ME --> STG
    STG --> ME
    ME --> GL

Two things are worth noticing. The actuarial model does not talk directly to the measurement engine. Both talk to staging, which holds the shared state and enforces the input/output contracts. And the measurement engine’s output loops back to staging before it flows to the GL, because the GL integration layer needs the results aggregated and mapped before posting.

This is architectural discipline, not technology. The same pattern works whether the actuarial model is a vendor package or an in-house build, and whether staging is a warehouse or a lake. What matters is that the contracts between components are explicit, versioned, and reconciled.

Closing thought

The four components above are the ones I treat as the critical path on any IFRS 17 build. Missing any one of them — or letting the contracts between them stay informal — is the thing that turns an on-track programme into a reconciliation crisis in the final parallel-run cycles. The choice of vendor matters less than the discipline of naming each component, defining its boundaries, and not letting the boundaries blur while the programme moves fast.