Data Model Issues in IFRS 17 Are Stalling Insurers

Insurance finance and actuarial teams chasing IFRS 17 deadlines, only to find the data model breaking under live volume.

✓ Written by IFRS TECH’s advisory team · ✓ Serving GCC, Europe & APAC · ✓ Actuaries + CPAs + CFAs

TL;DR

An IFRS 17 data model for insurers fails most often at the integration layer, not the accounting layer. This article covers the three recurring data model issues in IFRS 17 for insurers, why they cause reporting delays, and what a working ifrs data management setup actually looks like. Fix the model before the next close, not during it.

When the Close Takes a Month, the Data Model Is the Problem

One insurer ran nine separate source systems into its IFRS 17 close, including a decades-old policy admin mainframe, and the reconciliation alone ate nearly a month each cycle.

That’s not an outlier. It’s close to the median for insurers who treated IFRS 17 as a reporting project instead of a data architecture project.

Here’s the thing: the standard itself isn’t what breaks. The model underneath it is.

What this article covers

• Why granularity requirements expose weak data models
• The integration gaps causing audit qualifications
• What a compliant ifrs 17 data model for insurers needs structurally

Most insurers we work with at IFRS TECH already had an actuarial model. What they didn’t have was a data layer built to feed it consistently across policy admin, claims, and finance. That gap is where IFRS 17 data model for insurers projects quietly fail.

Why IFRS 17 Breaks Data Models That Worked Fine Under IFRS 4

IFRS 4 let insurers report at a level of aggregation that hid a lot of sloppy data plumbing. IFRS 17 doesn’t.

The standard demands contract-level cash flow data, risk adjustment inputs, and discount rate assumptions, all traceable back to source. larger data volumes at far greater granularity than IFRS 4 ever asked for, and most legacy systems were never designed to deliver that.

The Three Issues That Show Up Every Time

1. Siloed legacy systems that were never meant to talk to each other

Policy admin, actuarial modeling software, and the general ledger usually grew up separately. One CIO put it this way: the hardest part wasn’t the accounting, it was getting the systems to pass data to each other without manual patching.

Different systems output different formats. Excel exports, flat text files, database tables. Stitch those together by hand and you get reconciliation headaches that repeat every single quarter.

2. Inconsistent data definitions across actuarial and finance

A “policy” means something slightly different in the admin system than it does in the actuarial model. Multiply that across nine source systems and small definitional drift becomes a material reconciliation gap.

You might think this is a minor naming issue. It isn’t. It’s the single biggest driver of restated CSM balances we see in post-implementation reviews.

3. No data lineage, so audit can’t trace a number back to its source

Auditors increasingly ask: where did this number come from, and can you prove it? Without lineage built into the model, that question stalls the entire close.

That said, none of this means insurers need to rip out core systems. It means the data model sitting between those systems and the IFRS 17 engine has to do work it was never asked to do before.

Quick Self-Check: Is Your Data Model the Bottleneck?

Ask yourself three questions before the next close.

• Can you trace any CSM figure back to its source contract in under an hour?
• Do actuarial and finance use the same definition of “in-force” without a translation step?
• Does adding a new reporting field require touching code, or just metadata?

If two or more answers are no, the issue isn’t your accounting policy choices. It’s the model.

What Insurers Got Wrong With Implementation Timelines

Many jurisdictions that delayed adoption are now moving into implementation, often on compressed timelines that repeat the same data architecture mistakes earlier adopters made.

A regional post-implementation survey found that respondents ranked additional data requirements and process changes as the top driver of operational strain, ahead of staffing or model complexity.

And the World Bank’s regional regulator workshops found that 46 percent of insurers in one panel saw a downside effect on shareholders’ equity tied to how liabilities were restated under the new standard. One in four felt almost no impact at all.

Insurers serving GCC markets specifically face an added wrinkle: regulatory reporting under SAMA and CBUAE frameworks layers on top of IFRS 17, which means the data model has to serve two masters, not one. That’s a structural requirement, not a nice-to-have.

What a Working IFRS Data Management Layer Looks Like

Forget rebuilding everything. The fix is usually narrower than insurers expect.

A metadata-driven integration layer lets you define field mappings once and apply them across every source system, instead of rewriting transformation logic per feed. One insurer used exactly this approach to unify nine disparate systems into a single common format without touching the underlying legacy code.

That’s it. No platform replacement. Just a translation layer that actually understands what “policy,” “premium,” and “claim” mean across every system feeding it.

Three Things That Actually Move the Needle

1. Data lineage built into the pipeline, not bolted on after the fact for audit season.
2. A shared data dictionary that actuarial, finance, and IT all sign off on.
3. Parameterized business rules, so a new discount rate or grouping change doesn’t require a system redesign.

I don’t have long-term data on how these fixes hold up over a five-year reporting cycle. Nobody does yet. IFRS 17 is still young enough that most of what we know is drawn from the first two or three reporting years.

Proof It Works: Nine Systems, One Format

A Southeast Asian insurer with nine source systems, including a legacy mainframe and standalone actuarial software, cut its close cycle dramatically after consolidating field mappings into a single metadata layer. See how IFRS TECH approaches this for insurers running similarly fragmented environments.

Most insurers reported an alternative profit measure such as operating profit as their headline metric in a 2025 panel study of 23 insurers and reinsurers, which only works if the underlying CSM and risk adjustment figures are traceable in the first place.

What Auditors and Regulators Are Now Asking For

Audit qualifications in early IFRS 17 adopters weren’t usually about the accounting choices. They were about insurers being unable to show their work.

Costs haven’t gone away either. EY’s review of implementation outcomes flagged ongoing cost pressure as insurers continue investing in systems, processes, and people well past go-live.

PwC’s review of finance function impact, drawn from a survey of 17 insurers across 37 detailed questions, found the strain extends well beyond the close itself into how finance teams operate day to day.

What really matters here isn’t the audit opinion. It’s whether finance and actuarial teams can answer a regulator’s question on the spot instead of scrambling for three weeks.

Building This Into the IFRS 17 Data Model for Insurers From Day One

Insurers starting implementation now, particularly in jurisdictions just adopting the standard, have one advantage early adopters didn’t: a clear list of what goes wrong.

Build the data model with lineage and a shared dictionary from the start, and the close cycle that took one insurer nearly a month becomes a matter of days. Skip that step, and you’ll be retrofitting it under audit pressure within eighteen months. Most teams choose the second path anyway, usually because the first one looked optional at the time.

What You Now Know

• IFRS 17 data model issues stem from system fragmentation, not the accounting standard itself.
• Inconsistent definitions across actuarial and finance cause most CSM restatements.
• A metadata-driven integration layer fixes the core problem without a full system replacement.

The teams getting through this cleanly aren’t the ones with the biggest IT budgets. They’re the ones who treated the IFRS 17 data model for insurers as infrastructure, not a one-time reporting fix. Get the data model right, and IFRS 17 compliance stops being a quarterly fire drill.

Common Questions on IFRS 17 Data Model Issues

What causes most IFRS 17 data model issues for insurers?

System fragmentation is the main cause. Policy admin, actuarial, and finance systems were built separately and rarely share consistent data definitions, which creates reconciliation gaps during every close.

How does poor IFRS data management affect audit outcomes?

Without data lineage, auditors can’t trace a reported figure back to its source contract. That gap is what drives qualified opinions and extended audit timelines, not the accounting policy choices themselves.

Do insurers need to replace core systems to fix their data model?

Usually not. A metadata-driven integration layer can unify multiple legacy sources into one consistent format without a full platform migration.

How long does a typical IFRS 17 reconciliation cycle take with a broken data model?

Insurers running fragmented systems have reported close cycles stretching close to a month. A properly mapped data model can cut that to days.

Is the IFRS 17 data model issue specific to large insurers?

No. Smaller insurers and takaful operators in the GCC face the same problem, often worse, since they layer SAMA or CBUAE regulatory reporting on top of IFRS 17 with fewer dedicated data resources.