IFRS 17 Data Requirements: What Insurers Need First

TL;DR

IFRS 17 data requirements are bigger than most insurers planned for. You need policy-level data, clean cash flows, and a data model that traces every number. This article covers the data you must hold, how to build the model, and where governance breaks. You’ll also get a data quality checklist you can use today. Fix the data first, and the calculation engine becomes the easy part.

Here’s an uncomfortable fact. Half of the 17 global insurers PwC surveyed in 2024 still say time constraints squeeze their calculation and reporting cycle. The engine isn’t the main culprit. The data feeding it is.

IFRS 17 data requirements reach far past anything IFRS 4 asked for. You now need contract-level detail, grouped by portfolio, annual cohort, and profitability. Every figure must trace back to source. Miss that, and your CSM drifts, your auditors push back, and your close slips.

We see this at Prima Consulting in almost every engagement. Teams buy software first and ask about data second. That order costs months.

So what does your data need to look like before any model runs? Let’s break it down.

What this article covers

• Which data fields IFRS 17 actually demands
• How to design a data model that audits well
• A checklist to test your data quality

What Are the IFRS 17 Data Requirements for Insurers?

Start with the simple version. IFRS 17 data requirements cover everything you need to measure insurance contracts at a granular level: who you insured, what you expect to pay, when, and what you’ve already paid.

That sounds familiar. It isn’t. Under IFRS 4, you could often work from aggregated books. Under IFRS 17, aggregation is the enemy.

Policy-Level Data You Can’t Skip

Policy-level data is the foundation. Without it, you can’t group contracts, and without groups, you can’t calculate a CSM. Full stop.

For every contract, you need the inception date, coverage period, boundary, premium pattern, product code, and portfolio tag. You also need the profitability class at initial recognition. That one field trips up more teams than any other, because legacy systems never stored it.

Reinsurance contracts follow the same logic. Each held contract needs its own data trail, linked to the underlying direct policies it covers.

Cash Flow, Claims, and Expense Data

Next come future cash flows. You need expected premiums, claims, commissions, and attributable expenses, all by contract group. Then you need actual claims and payments to compare against those expectations.

Claims data deserves its own warning. Development triangles from your reserving team rarely match the contract-level grain that IFRS 17 wants. Someone has to bridge that gap, and it’s rarely a quick job.

The right approach is to settle ownership early. Actuarial owns assumptions. Finance owns actuals. Data engineering owns the pipe between them.

That raises a bigger question. How fine does the grain need to be?

How Does the Unit of Account Change Your Data Granularity?

You might think the unit of account is an accounting concept only. It isn’t. It’s a data design decision.

IFRS 17 asks you to split contracts into portfolios, then annual cohorts, then groups by profitability. Each group becomes a unit of account. Your IFRS 17 data requirements include those three tags on every contract, from day one. If you want the standard’s logic in plain terms first, our guide to IFRS 17 explained walks through it.

BCG’s 2023 work on insurer data strategy points to new granularity requirements as a core driver of technology change. Its advice is to integrate finance, actuarial, investment, and risk data at the finest level you can support.

Think about it. If a group moves from profitable to onerous, which contracts moved? Can you point at them?

If you can’t answer in minutes, your granularity is too coarse.

A Quick Self-Check

What Does an IFRS 17 Data Model Look Like?

An IFRS 17 data model is the structure that holds your inputs, assumptions, results, and the links between them. Your IFRS 17 data requirements only work when the model is built in layers, not as one big table.

The Five Layers That Matter

1. Source layer. Policy admin, claims, reinsurance, and finance systems.
2. Staging layer. Where raw data gets cleaned, tagged, and checked against rules.
3. Calculation input layer. Contract-level inputs and assumptions, versioned.
4. Results store. CSM, risk adjustment, and liability outputs, kept by run.
5. Ledger and disclosure layer. The sub-ledger, the general ledger, and your notes.

Four or six layers also work. The layer count matters less than the rule behind it: nothing moves up without a check and a record.

Where Most Data Models Fail

They fail at the joins, not the tables. In practice, actuarial and finance use different definitions of “in-force,” and nobody notices until the CSM won’t reconcile.

Our friends at IFRS Tech wrote a useful piece on data model issues that covers siloed systems and missing lineage. I agree with their core point. A shared data dictionary beats a fancier database every time.

Here’s what I can’t tell you: how many GCC insurers have fixed this. I haven’t seen published figures for the region, and I won’t invent one.

If you’re weighing build against buy, our IFRS 17 consulting services team can review your current model against these five layers.

What Data Is Needed for the IFRS 17 CSM?

The CSM is where data problems turn into money problems. IFRS 17 data requirements for the CSM are strict for a reason: a wrong input at initial recognition carries through every period after it.

For each group, you need the fulfilment cash flows at initial recognition, the risk adjustment, the discount curve used, and the coverage units. You also need every later change: new business, experience variances, assumption updates, interest accretion, and releases.

Coverage units are the sleeper. They drive how much CSM you release each period, yet many teams only decide how to count them in the final weeks before go-live.

Don’t do that.

Store the discount rate curve and the assumption set with every run, too. When an auditor asks why Q2 differs from Q1, you’ll need both versions on hand.

Why Does IFRS 17 Data Governance Break Down?

You might expect technology to be the problem. Usually it’s ownership. IFRS 17 data governance is where most data requirements quietly fail.

KPMG’s 2023 review found that many insurers hadn’t yet settled how to find, clean, and store high-quality data, and that teams were fixing errors through manual workarounds. Spreadsheets filled the gaps. Auditors noticed.

Then there’s the handover problem. In PwC’s 2024 survey, 38% of insurers said project teams hadn’t yet handed IFRS 17 over to business-as-usual staff. When the people who built the data flows leave, the knowledge goes with them.

Who owns your data governance right now? Not who should. Who does?

Data Lineage in Plain Terms

Data lineage is the record of where each number came from and what happened to it on the way. In other words, it’s your proof.

Good lineage lets you click a CSM figure and walk back to the policy, the extract date, and the rule applied. Bad lineage means someone opens a spreadsheet and hopes.

A lot of this gets worse across regions. A GCC group with entities in Saudi Arabia and the UAE faces SAMA and CBUAE reporting on top of the standard, and each regulator wants its own cut of the same data.

Reconciliation Is Not Optional

Reconcile calculation inputs to the finance ledger before the actuarial model touches them. Reconcile outputs again afterward. Two checkpoints, every cycle.

That discipline is exactly what our IFRS 17 Implementation Challenges Guide flags as the line between a clean close and a restated one.

One more thing. Our own advisory team has helped insurers across Saudi Arabia, the UAE, and Pakistan trace these breaks back to a handful of root causes. It’s rarely exotic.

IFRS 17 Data Quality Checklist: 8 Checks Before Your First Run

Use this list to test your IFRS 17 data requirements while there’s still time to close gaps.

1. Every contract carries a portfolio, cohort, and profitability tag.
2. Contract boundaries are stored, not assumed.
3. Premium, claim, and expense data reconcile to the ledger.
4. Reinsurance contracts link to the policies they cover.
5. Discount curves and assumptions are versioned per run.
6. Coverage unit logic is documented and approved.
7. A named person owns each data domain.
8. Any figure traces to its source in under an hour.

Score yourself honestly. Fewer than six passes? You’ve got work to do before the engine matters.

For deeper help closing those gaps, our IFRS advisory support covers data readiness reviews.

Most of these checks cost little. The expensive part is finding out late.

Where to Start With IFRS 17 Data Requirements This Quarter

Start small. Pick one product line and run the eight-point checklist against it. You’ll find the real gaps in a week, not a quarter.

Then fix data governance before you fix tooling. A good data model without an owner decays within two reporting cycles.

That’s the whole game. Treat IFRS 17 data requirements as a finance and actuarial project, not an IT ticket, and the calculation engine will do what you bought it to do.

FAQs: IFRS 17 Data Questions

What data is needed for IFRS 17?

IFRS 17 data requirements start with contract-level data for every policy: inception date, boundary, premium pattern, portfolio, cohort, and profitability class. You also need expected and actual cash flows, claims, expenses, reinsurance links, discount curves, and assumptions. Each item must trace to a source system and a named owner.

What is an IFRS 17 data model?

An IFRS 17 data model is the layered structure that stores inputs, assumptions, calculation results, and the links between them. It typically runs from source systems through staging, calculation inputs, a results store, and a sub-ledger. Its job is to make every reported number traceable.

Why is data lineage important for IFRS 17?

Data lineage shows where each figure came from and what changed it. Auditors use it to test your CSM and liabilities. Without it, you can’t prove a number, and unprovable numbers lead to qualified opinions, restatements, and slow closes.

How granular must IFRS 17 data be?

Granular enough to assign every contract to a portfolio, annual cohort, and profitability group. In practice, that means policy-level data, not aggregated books. If you can’t move one contract between groups and see the CSM change, your granularity falls short.