IFRS 17 in 2026: Why Insurers Are Rebuilding Data Platforms

A mid-size European life insurer closed Q1 2026 with a 47 page IFRS 17 reconciliation spreadsheet, four actuaries on rotating overtime, and an external auditor asking the same three questions for the third year running. The same scene plays out in Madrid, Munich, Toronto, and Singapore. Three years into mandatory IFRS 17 reporting, most carriers are not having a system problem. They are having a data platform problem. The bolt-on solutions that got them through the first close have hit their limit.

This post is for insurance CFOs, CTOs, and actuarial systems leads scoping a replacement for spreadsheet-and-bolt-on IFRS 17 reporting. It walks through why the year-three stacks are still failing, what the contractual service margin actually needs from a data architecture, and the build patterns that survive quarter-close.

Why year-three IFRS 17 stacks are still broken

IFRS 17 has been mandatory for annual reporting periods starting on or after 1 January 2023, as set by the IASB. Most EU and APAC insurers published their first full audited IFRS 17 results in 2024 for FY2023. By 2026, the standard is no longer new. What is new is the cumulative weight of three years of monthly and quarterly closes on infrastructure that was supposed to be temporary.

Three failure modes recur across the carriers we have looked at:

1. Granularity explosion. IFRS 17 groups of contracts (unit of account) typically multiply data volume by 10 to 100 times relative to IFRS 4. A life insurer with 200 IFRS 4 product groupings ends up with 5,000 to 20,000 IFRS 17 cohorts once onerous groupings, annual cohort splits, and portfolio aggregations are applied. Legacy actuarial models were not built to emit results at this cardinality on a quarterly cadence.
2. Actuarial-to-finance handoff fragility. The CSM (Contractual Service Margin), risk adjustment, and present value of future cash flows live in the actuarial model. The general ledger lives in the ERP. Between them sits a chain of spreadsheets, scheduled jobs, and a sub-ledger that often started as a proof of concept. Each quarter, the chain breaks somewhere, and a senior actuary spends days reconciling.
3. Audit cost compounds. The auditor asks for the same control evidence every quarter. Without a deterministic data lineage from policy data through cash flow projection through CSM movement through GL posting, the answer is recomputed by hand each time. A typical EU mid-size insurer reports audit fees up 30 to 70% versus pre-IFRS 17 baseline, largely because the underlying data trail cannot be reproduced quickly.

The fix is not another bolt-on. It is a re-architecture around the CSM as a data product.

CSM as a data product: what the runoff engine actually needs

Under IFRS 17, the Contractual Service Margin represents the unearned profit on a group of insurance contracts. It is recognized in P&L over the coverage period. The CSM “runs off” as services are provided. Three measurement models drive this:

• General Measurement Model (GMM, sometimes BBA): the default. Full present value of future cash flows, risk adjustment, CSM.
• Premium Allocation Approach (PAA): simplification permitted for short-duration contracts (typically less than one year).
• Variable Fee Approach (VFA): for direct participating contracts. CSM is adjusted for changes in the value of underlying items.

Each model has its own CSM movement rules: locked-in discount rates, current discount rates, OCI option mechanics, unwinding of risk adjustment. A first-gen IFRS 17 stack often hardcodes one model per portfolio and breaks when a contract switches model boundaries (a guaranteed annuity rider on a unit-linked policy, for example).

A CSM engine that survives year three has four characteristics:

• Model-agnostic data contract. A single canonical schema for cash flow projections, risk adjustment outputs, and discount rate curves, regardless of which measurement model produces them. Downstream consumers do not need to branch by model.
• Immutable per-period results. Each reporting period produces a sealed result set. Late corrections create a new period record and a structured retrospective adjustment, not an in-place mutation.
• Lineage from policy to journal. Every CSM movement can be traced backward to the source policies and forward to the GL postings. This is what makes audit deterministic.
• Configuration as data, not code. Unit of account definitions, onerous groupings, OCI option settings change over time. They live in a versioned configuration store, not in actuarial model scripts.

Building this from scratch is a 12 to 18 month effort. Migrating to a vendor sub-ledger that already does it is typically six to nine months of integration plus three months of parallel run.

Sub-ledger architecture: SAP FPSL vs Aptitude vs build

The vendor landscape in 2026 is mature. The main contenders for the IFRS 17 sub-ledger:

• SAP Financial Products Subledger (FPSL). The default if the GL is S/4HANA. Tight integration with the SAP universal journal; high configuration overhead during initial implementation; strong ongoing operational fit.
• Aptitude IFRS 17 Solution. Independent sub-ledger with native CSM, OCI, and reinsurance held capabilities. Strong fit for non-SAP GLs and multi-GAAP shops; popular at Lloyds carriers and global multinationals.
• Moody’s RiskIntegrity for IFRS 17. Integrated with Moody’s actuarial pipeline (RAFM, AXIS). Common at carriers that already standardized on Moody’s actuarial tooling.
• FIS Insurance Risk Suite (Prophet + DCS). Prophet for actuarial projections, DCS as the IFRS 17 calculation layer; popular at life insurers with Prophet-heavy legacy.
• Aon PathWise. GPU-accelerated; selected for capital-intensive lines and Solvency II convergence projects.
• Custom build on a modern data platform. Real, but typically only at large carriers (>EUR 5 billion premium) with strong internal engineering and a CFO willing to fund a multi-year platform. The Norwegian and Dutch markets have produced several credible custom builds.

The build-versus-buy decision usually comes down to two factors: how aligned the GL is to an existing vendor’s stack, and how willing the actuarial team is to share a data contract with finance. Where actuarial and finance still treat each other as external clients, a packaged sub-ledger imposes the necessary structure faster than a custom build can negotiate it.

Actuarial to finance: a data contract that survives quarter-close

The data contract is the single most undervalued artifact in IFRS 17 architecture. It defines the shape, the cadence, and the responsibility split between the actuarial model and the finance sub-ledger.

A working contract has the following sections:

• Granularity. The minimum unit of disclosure (group of contracts) and the dimensions on which it is sliced (line of business, currency, cohort year, onerous status, measurement model).
• Schedules. What is produced when. The actuarial pipeline closes by day 6 of the month after period-end. The sub-ledger close happens day 7 to 10. The disclosures are signed off day 12.
• Numeric semantics. Sign conventions, rounding rules, currency conversion timing. Most quarter-close disputes are sign convention disagreements that nobody caught at design time.
• Reconciliation tolerances. Per metric, per portfolio, the maximum tolerated difference between source and destination. Outside tolerance triggers escalation; inside tolerance is auto-confirmed.
• Late adjustment protocol. What happens when actuarial reopens a result after sub-ledger close. Almost always: a structured retrospective adjustment journal, not an in-place mutation.

Writing this contract is a four to six week exercise with actuarial, finance, and IT in the room. Most carriers that did not write one in 2022 to 2023 are writing one now. The ones that wrote one early are closing in five days where their peers are closing in fifteen.

Solvency II 2025 revisions and the OCI option

Directive (EU) 2025/2, amending the Solvency II Directive, entered into force on 29 January 2025. Member state transposition is due by 29 January 2027. The Solvency II revisions change the long-term guarantee package, the volatility adjustment, the risk margin calculation, and the proportionality regime.

The interaction with IFRS 17 is subtle but material. Carriers using the OCI option (locking in the discount rate at initial recognition and routing financial result movements through OCI rather than P&L) are particularly affected. The new Solvency II long-term guarantee parameters change the assumed yield curves; the discount rate used for IFRS 17 OCI may diverge further from the Solvency II curve, complicating reconciliation between the two frameworks.

For a 2026 data platform, the implication is that the discount rate service must be model-aware. It cannot return a single curve for both IFRS 17 and Solvency II. It must return a versioned set of curves, with metadata indicating which framework, which date, which calibration source. Carriers running both frameworks off a single hardcoded curve set are accumulating reconciliation debt that will surface in 2027 transposition reviews.

Disclosures and audit: closing the reconciliation gap from day one

IFRS 17 disclosures (IFRS 17.93 to 132) are extensive. The required reconciliations include opening to closing balances of insurance contract liabilities, by major component (LRC, LIC, CSM, RA), with separate disclosure of new business, changes in expectations, experience adjustments, and CSM amortization.

A first-gen stack typically produces these disclosures from a downstream reporting tool (Tagetik, OneStream, SAP BPC) that consumes the sub-ledger output, applies its own logic, and emits the note schedules. Every time the underlying data changes, the downstream reconciliation must be redone. By year three, the reconciliation has become a four-person job.

The structural fix is to make the disclosure schedules a direct read off the sub-ledger, with the reporting tool acting purely as a presentation layer. Every disclosure line item maps to a sub-ledger query. When the auditor asks for the supporting detail behind a disclosure number, the answer is the query, not the spreadsheet.

This is achievable in the second half of a replatform project. The blocker is usually that the sub-ledger was implemented with disclosure as an afterthought; the data model has the right numbers but not the right slices. A retrofit of disclosure-shaped views typically takes one to two quarters.

A 12 month replatform plan that does not freeze the close cycle

If the year-three stack is too painful to keep but the close cycle cannot be frozen, the achievable scope for a 12 month replatform:

1. Quarter 1: data contract and discovery. Write the actuarial-to-finance data contract. Audit current pipeline failure modes. Inventory all CSM, OCI, and reinsurance held special cases. Make the build-vs-buy decision.
2. Quarter 2: sub-ledger implementation, parallel run setup. Stand up the new sub-ledger on one portfolio (typically a clean PAA book). Run in parallel with legacy for one full quarter.
3. Quarter 3: portfolio migration in waves. Migrate remaining portfolios in priority order. Each wave is a discovery, parallel run, signoff cycle. Resist the temptation to migrate everything in one wave; it always breaks.
4. Quarter 4: disclosure refit and audit pivot. Rebuild disclosure schedules as direct sub-ledger queries. Walk the auditor through the new lineage. First fully clean close on the new stack.

The replatform succeeds when the close time drops by half or more and the audit fee stops growing. Carriers that completed this transition in 2025 are reporting close cycle reductions from 14 to 6 working days, with no increase in audit findings. The ones still on bolt-on infrastructure are watching their close cycle expand as cohorts age and the CSM runoff complexity grows.

Three years in, IFRS 17 is no longer a project. It is the operating model. The carriers that recognize this and re-architect accordingly are pulling ahead. The ones still patching are paying twice: once in close cost, and again in the audit fees, regulatory queries, and lost product agility that come with an unreliable financial close.