IFRS 17 Testing: Proving the Data Around the Engine

IFRS 17 testing has two halves. The first is validating the accounting engine and actuarial models, which belongs to finance and actuarial teams. The second is proving that the data flowing into and out of them is complete, accurate and correctly attributed, release after release.

Most IFRS 17 problems after go-live sit in that second half. Every change to a policy, claims or billing system can change the data the engine depends on, often without anyone realising it affects IFRS 17 at all.

IFRS 17 Insurance Contracts has applied to annual reporting periods beginning on or after 1 January 2023, and it’s widely seen as a data-intensive standard. Insurers spent years building the data pipelines it needs. This guide is about keeping those pipelines correct as your operational systems keep changing.

Why IFRS 17 Results Depend on Operational Systems

The IFRS 17 engine measures groups of contracts using data that starts life in your policy administration, claims, billing, reinsurance and finance systems. Contract attributes decide which portfolio, annual cohort and profitability group a contract joins. Premiums, claims and expenses drive the cash flows, and dates drive recognition. Change any source system, and the result can quietly change too.

Which IFRS 17 Testing Belongs to QA?

QA owns the data and the flows. Finance and actuarial teams own the measurement. Drawing that line clearly avoids two common failures: QA teams trying to validate actuarial judgements they aren’t qualified to assess, and accounting teams assuming source data is right just because the engine ran without errors.

Touchstone sits in the QA rows: source system data, pipeline outcomes and reconciliations.

What Breaks IFRS 17 Data After Go-Live?

Operational change. New products, configuration changes, vendor releases, migrations and integration updates all happen without anyone thinking about IFRS 17, yet each can alter the attributes or cash flows the engine reads. The engine keeps running, the numbers keep coming, and the error stays hidden until a reconciliation break or an audit query.

Common causes:

• New products or variants whose attributes do not map to an existing portfolio or grouping rule.

• Changed effective-date handling after a vendor release, shifting which period a transaction falls in.

• Endorsement and cancellation logic changing the cash flows sent downstream.

• Reinsurance links broken when contract identifiers change.

• Migrations that alter issue dates or product codes, moving contracts between cohorts.

• Field mapping changes in the pipeline that truncate, default or misclassify values.

How Should Insurers Test the Data Flows Around IFRS 17?

Test from the operational event to the engine input: create the event in the source system, follow the data through the pipeline, and check that it arrives with the right attributes, amounts and dates. Then reconcile totals between source systems, engine inputs and ledger postings for each period. Run both on every change that touches a source system.

A practical approach:

1. Define representative contracts per portfolio: Including each product, cohort boundary and profitability indicator the grouping logic uses.

   
   

2. Drive operational events: Issue, endorse, cancel, claim and pay through the source systems, at dates either side of period and cohort boundaries.

   
   

3. Check engine inputs: Confirm attributes, amounts and dates for each event in the data delivered to the engine.

   
   

4. Reconcile: Compare totals by portfolio and period across source systems, engine inputs and ledger postings.

   
   

5. Regress on change: Trigger the flow tests whenever a source system, pipeline or mapping changes.

How Does This Apply to US GAAP LDTI?

US insurers reporting long-duration contracts under the FASB's targeted improvements (LDTI) face a similar dependency on operational data: cohorts, cash flows and assumptions drawn from administration systems.

The same principle holds. Measurement belongs to actuarial and finance; proving the data flowing in is complete and correct belongs to testing.

How Does Virtuoso QA Touchstone Test IFRS 17 Data Flows?

Touchstone drives operational events through policy, claims and billing systems and checks the data that results, from source to engine input to ledger, in a single journey.

Requirements come from data specifications and grouping rules, results are deterministic, and every source system change triggers the flows it could affect.

• The Analyst reads IFRS 17 data specifications, grouping rules, mapping documents and source system change notes, and proposes requirements, each citing its source.

• The Architect builds journeys that create contracts and events in source systems and follow the resulting data through the pipeline.

• The Autopilot runs those journeys on a deterministic engine in your CI pipeline whenever a source system, pipeline or mapping changes.

• API and data checks confirm attributes, amounts and dates at each stage and reconcile totals by portfolio and period.

• Change tracing links a product launch, vendor release or mapping change to the IFRS 17 data requirements it affects.

Touchstone doesn’t validate measurement models or accounting judgements. It proves that the data those models rely on is right.

When auditors ask how a source system change was controlled, Virtuoso QA’s release evidence shows the requirement, result, approver and build behind every data check.

Also read: our guide to insurance integration testing covers the payment, reinsurance, finance and data warehouse feeds that sit alongside IFRS 17.

From policy issue through billing, claims and reinsurance, Virtuoso QA’s insurance testing keeps the operational data behind your financial reporting accurate through every release.

Illustrative scenario: a new product variant and the wrong portfolio

This scenario is illustrative and does not describe a specific firm. A European life insurer launches a new variant of a protection product. The product team configures it in the policy administration system with a new product code.

The IFRS 17 grouping rules and mapping documentation are sources in Touchstone, and the product launch triggers the data flow journeys. One check fails: the new product code is not in the mapping table, so contracts arrive at the engine with a default portfolio attribute. The mapping is updated before the first quarter-end, and the evidence shows the launch, the failed attribute check, the fix and the passing reconciliation.