IFRS 17 Data Gaps and Challenges: Staging Platforms, Vendor Inputs, and the Transformation Layer

Most IFRS 17 projects I have scoped spend more time on data than on anything else. More than the actuarial model rebuild, more than the accounting engine configuration, and almost always more than the methodology papers. The reason is simple: the standard requires contract-level or group-level information flowing through multiple systems on a fixed reporting cadence, and that pipeline has to be built before anything downstream can be tested. Policy administration systems that were fine for IFRS 4 and solvency reporting are rarely fine for IFRS 17 without work.

This post walks through the data workstream the way I scope it on client engagements — the staging platform, the vendor input problem, and the transformations that connect them.

1. What the data workstream actually contains

The data workstream is not one activity. On a live build it decomposes into four distinct pieces of work that run in sequence with overlap:

• Understanding what inputs each downstream system needs — the actuarial model for cash flow projection, the measurement engine for CSM and risk adjustment, and the posting layer for journals and disclosures.
• Building or adapting a staging platform that holds source data, transformed data, and any results that flow back from upstream systems.
• Piping data from source systems into the staging platform, and from the staging platform into the downstream systems.
• Building transformation logic inside the staging platform so that every consumer receives data in the exact shape it expects.

The thing that makes this hard is not any single step. It is that the four pieces cannot be done strictly in order. You cannot finalise staging design until you know which vendor you chose, but you need staging stable before the vendor can do a dry run. Every project I have seen has had to iterate through this circularity.

2. Understanding vendor input requirements

Each IFRS 17 vendor has its own input specification — the file shapes, the keys, the cohort tagging conventions, the way opening balances are provided, the way cash flow vectors are labelled. The specifications are long, and the edge cases (currency handling, reinsurance, investment components, contract boundary changes) are where the real work sits.

There are two practical tips I would give any team starting this:

First, get the vendor and the implementation partner to walk you through the input spec before you commit to it. The document alone is not enough. You need someone who has configured the engine against real insurer data to explain why certain fields exist, which ones the engine is strict about, and which ones tolerate missing values.

Second, stand up a test dataset early — even synthetic, even small. A five-contract dataset pushed end-to-end through staging into the engine will teach you more about input requirements in a day than a week of reading the specification. This is what prototype tooling exists for, and it pays back immediately on the transformation design.

3. What a staging platform is, and why it matters

A staging platform is an intermediate data store that sits between the insurer’s source systems (policy admin, claims, general ledger) and the upstream IFRS 17 systems (actuarial model, measurement engine, posting logic). It holds source extracts, transformed data ready for each consumer, and — importantly — results flowing back from upstream systems for the next cycle.

The relationship is cyclic, not linear. Expected cash flows come out of the actuarial model, land back in staging, get transformed into the measurement engine’s input format, and flow upstream again. Closing CSM balances come out of the measurement engine, land back in staging, and become opening balances for the next period. Staging is the long-memory component in the architecture.

The typical data points held here are:

• Opening and closing balance information by group of insurance contracts
• Locked-in yield curves and current discount curves
• Projected cash flow vectors at the right granularity
• Coverage units by period
• Experience data, actuals, and analysis-of-change inputs
• Any reference data needed to aggregate contracts into groups and portfolios

There are architectural debates about whether this should be a single database with coherent API access, a data lake, or a set of purpose-built marts. The single-database-with-API pattern is usually the lowest-friction choice for a first-generation build — it concentrates administrator effort on one system, and it spreads the running cost across every downstream consumer.

4. Building or adjusting the staging platform

The effort required depends on where the insurer is starting from. If source data is already consolidated in a warehouse with decent quality controls, the work is mostly additive — new transformation logic, new tables for IFRS 17 specific items, a new delivery contract with downstream systems. If source data is spread across legacy policy admin systems with inconsistent extracts, the work is structural.

The most common gaps I see on this part of the build:

• Source extraction is slow or manual, especially from legacy platforms, which makes the monthly close timeline unrealistic.
• Required fields are not being extracted today because they were never needed — contract boundary indicators, acquisition cash flow tags, reinsurance linkages.
• Data needs enrichment that does not exist in source — for example, cohort tags that combine year of issue, portfolio, and profitability, which need to be constructed in staging.
• The data is spread across multiple systems in different formats with no authoritative source.
• The team does not have database administrators or data engineers with capacity to take on the work.
• The actuarial model cannot aggregate its own output to IFRS 17 group level, and an external aggregation step has to sit inside staging.

Any one of these is enough to make staging the critical-path item on the programme. Two of them together is the default starting condition.

5. Transforming data into vendor input format

Transformation work can only really start once three things are true: the vendor has been chosen, the staging platform holds source data in a consistent format, and the team has a working understanding of both their own data and the vendor’s input requirements. Before those three conditions hold, transformation code you write is speculative and usually gets thrown away.

Once the conditions are met, this is a data-engineering problem, not an actuarial one. The right skills are people who know how to move large datasets quickly — SQL, Python with pandas or Spark, whichever ETL tooling the insurer has standardised on. The right pattern is to build transformations as idempotent, rerunnable jobs with logging and reconciliation, not as one-off scripts.

Two patterns I have seen work well:

• Treat every transformation as a contract between staging and a downstream consumer. Version it. Document the shape on both sides. Have a reconciliation check between input and output that runs on every job.
• Separate the “make it match the spec” transformations from the “fix the source data” transformations. The former should be narrow and stable; the latter are where the complexity lives, and they need ownership.

6. How to make the workstream tractable

The data workstream is daunting, but it is also the place where an IFRS 17 programme can buy itself operational upside. A warehouse that is stable enough for monthly IFRS 17 reporting tends to be stable enough for internal management reporting, regulatory solvency reporting, and downstream analytics work that had been deferred for years.

A strategy that tends to hold up:

• Stand up the staging platform or make it reporting-grade, even if it duplicates some existing infrastructure at first.
• Get deep on the vendor’s input requirements early, with the vendor in the room.
• Staff the transformation layer with data engineers, not actuaries doing ETL on the side.
• Build reconciliation and data-quality checks into every stage, not as an audit afterthought.

Closing thought

Most of the IFRS 17 cost overruns I have seen came from underestimating the data workstream. The symptoms show up everywhere else — the actuarial model cannot be tested, the engine fails dry runs, the disclosures do not reconcile — but the root cause is almost always upstream. Getting staging, vendor inputs, and transformations right early is the cheapest piece of insurance an implementation programme can buy for itself.