IFRS 17 Accounting Engine Input Requirements: The Data Bottleneck

On every IFRS 17 programme I have worked on, the slowest workstream was data. Not methodology, not the accounting-engine configuration, not even the actuarial model rebuild. Data. Getting cash flows, reference tables, discount curves, and policy attributes out of eight source systems and into the precise shape an accounting engine wants them in is where calendar time disappears. It is also the workstream that is hardest to budget for in advance because the shape of the required inputs is not fully visible until the vendor engine is selected.

What follows is the input landscape as I see it across vendors. The categories are stable; the schemas are not. Understanding the categories — and which data source each one pulls from — is how you avoid finding out in user-acceptance testing that a column you need does not exist in any upstream system.

1. What the engine actually wants

Every IFRS 17 accounting engine I have worked with, regardless of vendor, asks for variations on the same underlying inputs. The labels differ. The file formats differ. The normalisation level differs. The conceptual content is stable.

Expected cash flows related to future service, in their respective currencies. Expected cash flows related to past service — incurred but not yet paid, and the unwind of prior-period expectations. Actual cash flows received and paid during the period. Coverage units and their amortisation pattern, used to release CSM and notional deferred acquisition costs. Discount curves — opening, closing, and locked-in at cohort inception — attached to each group of contracts. CSM group reference data with portfolio, cohort, profitability category, and currency attributes. Hierarchy and currency information describing the group structure of the insurer. Portfolio-level policy and methodology choices. Run-order configuration for the sequence in which cash flows are processed. And workspace-level configuration for the reporting period itself.

That is the canonical list. The mapping tables between a company’s own cash flow variable names and the vendor’s required variable names often sit alongside these inputs as a separate feed — and are surprisingly often the piece that breaks.

2. Where the data actually comes from

The inputs above do not come from one place. They come from four distinct sources, each with its own owners and its own update cycle. Understanding which source feeds which input category is the starting point for any data-workstream design.

From the actuarial models: expected cash flows, coverage units, amortisation patterns, risk adjustment (if calculated outside the engine), and the underlying projection outputs. This is the largest feed by volume and the one with the most structural transformation required. Model outputs are typically at contract or model-point level and need to aggregate to group-level inputs for the engine.

From the policy administration and general ledger systems: actual cash flows received and paid, claims data, expense allocations, and historical premium and claim movements. These are typically at transaction level and need to be aggregated to the same grouping dimension as the model outputs.

From economic data sources: discount curves and exchange rates. These feeds are small in volume but high in frequency — typically updated at every reporting period — and need to be version-controlled carefully because locked-in curves have to persist across periods.

Created specifically to configure the engine: CSM group reference tables, portfolio policy choices, run-order configuration, hierarchy definitions, and mapping tables. This data is not sourced from any upstream system. It is designed and maintained by the IFRS 17 team itself as part of the build.

3. The four ETL processes, not one

A common mistake in early programme design is to treat the data workstream as a single ETL pipeline. It is not. It is four pipelines with different characteristics, and treating them as one creates governance confusion and ownership gaps.

The actuarial-model pipeline extracts projection outputs, transforms them into the group-level structures the engine expects, and validates that the totals reconcile to the model’s own control totals. This is typically the heaviest pipeline in both compute and data volume.

The administration-system pipeline extracts actual cash flows, aggregates them to the grouping dimension, and reconciles to the general ledger. The reconciliation point matters — actuals have to agree to the GL before they go to the engine, not after.

The economic-data pipeline is small and relatively simple, but its versioning discipline has to be strong. Locked-in curves stored at cohort inception must not drift over time. Opening and closing curves must tie back to the economic source with a documented lineage.

The reference-data pipeline is almost entirely manual and entirely insurer-specific. It is where most of the close-cycle errors I have seen originated — a cohort mapping that was right in period one and wrong in period three because an analyst updated it without a change record.

4. The questions that expose vendor differences

Vendor engines differ on a handful of specific input-design questions. Asking these questions up front, before selection, is how buyers avoid expensive surprises during implementation.

Tagging. How do you tag policies to CSM groups — using functionality inside the vendor solution, or using a profitability-testing tool that sits upstream of the model? If upstream, how does the tag persist through subsequent model runs?

Mapping over time. How does the solution handle policy-to-group mapping changes in subsequent reporting periods? Does it support explicit transfers between groups with the right accounting treatment?

Discounted versus undiscounted. Does the engine expect present values, or projected undiscounted cash flows with discount curves applied internally? This choice pushes work either upstream into the actuarial model or downstream into the engine, and the tradeoff is real.

Opening values. Does the engine populate opening values from the previous period automatically, or must the user supply them as explicit inputs each period? If the latter, closing-value storage outside the solution becomes load-bearing infrastructure.

Risk adjustment. Is there a built-in risk adjustment calculator, or must the insurer build a separate RA model and feed results in? The second option is more flexible but adds a whole workstream and another reconciliation.

Discount curve carry-forward. Does the engine persist locked-in curves internally, or does the insurer need to store and re-supply them each period?

Assumption management. Is there an assumption-update mechanism inside the engine, or must all assumption changes flow in through the actuarial-model feed?

Expense allocation. Can the engine allocate expenses across groups, or must the expense allocation be done upstream and fed in as cash-flow-level inputs?

The answer to each question moves work either inside the engine or outside it. The total work is broadly constant; where it lives is not.

5. Who should actually do this

This is the part of the workstream where the professional-skill mix matters. Actuarial colleagues can do light data transformations — most of us have written enough SQL and enough model-output wrangling to produce a working pipeline for a single run. But the IFRS 17 data workstream at production scale is not a single run. It is a recurring, auditable, controlled process across multiple source systems with reconciliation gates and versioning requirements.

That is data administration work. It wants people who specialise in ETL design, database performance, lineage tools, and change control. An actuarial team that insists on owning the data pipeline end-to-end will either burn out, or produce a pipeline that passes the first close and breaks in the third.

The better model, which I have seen work well on two recent implementations, is a joint team: actuaries who own the semantics of the inputs and the reconciliation logic, and data engineers who own the pipeline implementation and the lineage. The handoff is explicit: actuaries specify what the input should contain and how it should reconcile; data engineers build the process that produces it.

Closing thought

The accounting-engine input requirements are visible on the vendor’s data dictionary. The data work behind them is not. Every vendor on the market accepts broadly the same categories of input; every insurer implementing the standard has to design four pipelines to produce them; and the difference between a pipeline that passes audit and one that generates weekly fire-drills is down to which questions the team asked up front. Treating data as the second-most-important workstream on an IFRS 17 programme is a recurring error. It is the first.