IFRS 17 Was a Data Project Disguised as an Accounting Standard

Insurers spent years and fortunes implementing IFRS 17, and most of them filed it under "finance transformation." That framing is why so many of the programs were painful and why the pain isn't over. IFRS 17 was never really an accounting change you could hand to the actuaries and the finance team. It was a data project — one that demanded granular, reconciled, traceable data at a level most insurers had never assembled — wearing an accounting standard's clothing.

Why the standard is a data problem

The old world let insurers report at a fairly aggregated level. IFRS 17 changed the unit of account: measurement at the level of groups of contracts, with explicit tracking of the contractual service margin, risk adjustment, and the release of profit over time. To produce those numbers you need data at a granularity — cohort, contract group, cash flow, assumption version — that legacy policy and finance systems were never designed to expose. The accounting rules were the visible part; the invisible part was that your data had to become finer, cleaner, and more connected than it had ever been.

Where the programs actually struggled

  • Granularity that didn't exist. Reporting by groups of contracts requires data sliced that way from the source. Many insurers discovered their policy systems couldn't produce it without heroic reconstruction.
  • Actuarial and finance on different data. IFRS 17 forces these two worlds to agree on numbers built from the same source. When they'd historically worked from separate extracts with subtly different definitions, reconciling them was the real project.
  • Assumption and cash-flow lineage. The standard demands you can explain how a figure was built — which assumptions, which cash flows, which version. That's data lineage, and lineage you didn't capture can't be produced after the fact.
  • The reconciliation burden. Movement analysis between periods, at the new granularity, turned into a data-integration exercise nobody had scoped as one.

Why the pain didn't end at go-live

Many insurers got to compliance through a heroic, semi-manual reporting solution — a bespoke calculation layer stitched to spreadsheets and reconciliations, run by a small team who understand the wiring. It produces the numbers, but it's fragile, slow, and expensive to run every reporting cycle, and it depends on institutional knowledge that walks out the door at retirement. Compliance was achieved; a sustainable data foundation was not. The second act of IFRS 17 is turning that heroic effort into something industrialized — which is, again, a data problem, not an accounting one.

What "done properly" looks like

  1. Granular data from the source. Contract-group-level data produced by the policy and claims systems, not reconstructed downstream every quarter.
  2. One reconciled number. Actuarial and finance building from a shared, governed data foundation so the figures agree by construction, not by month-end negotiation.
  3. Assumption and cash-flow lineage captured as data flows, so movement analysis and audit questions have answers you can generate, not reconstruct.
  4. An industrialized pipeline that runs the cycle repeatably, without depending on a handful of people and a maze of spreadsheets.

The insurers who found IFRS 17 least painful weren't the ones with the cleverest accounting interpretation — they were the ones whose data foundation could already produce granular, reconciled, traceable numbers, or who used the program to finally build one. Everyone else bought compliance and inherited a fragile machine. Turning that machine into a durable, reconciled, lineage-complete data foundation is exactly the kind of work we do with insurers at IntelliBooks.

IFRS 17 is often described as the biggest accounting change in a generation. It was really the biggest data change — and the insurers who understood that are the ones not dreading every reporting cycle.

Comments

Post a Comment

Popular posts from this blog

Why Your Insurance Data Warehouse Didn't Fix Anything

You built the data warehouse. It took eighteen months and cost more than planned. Policy data, claims data, billing — it's all in there. The project was declared a success and everyone moved on. And yet: underwriting still can't see the whole customer. The AI initiative is still stalled. Someone still asks for a report and waits three weeks. Nobody says it out loud, but the question hangs there — what exactly did we buy? You're not alone, and it isn't because you built it badly. It's because a warehouse solves a problem you didn't have. The problem a warehouse solves Warehouses solve location . Before: your data was in eight systems. After: it's in one place. That's genuinely valuable — you can run a query across policy and claims without begging two teams for extracts. But notice what that fixes: it fixes where the data is . It doesn't touch what the data means , whether it's trustworthy, or whether the records refer to who you think t...
Read more

Embedded Insurance: Why the API Is the Easy Part

Embedded insurance is the idea that coverage should be offered at the moment of need, inside someone else's product — travel insurance at checkout, device protection when you buy the phone, cover for the rental car in the booking flow. It's one of the fastest-growing distribution models in the industry, and every insurer has a strategy slide about it. Most of those strategies underestimate the same thing, and it isn't the partnerships or the product. It's the data plumbing. Everyone assumes the API is the hard part. The API is the easy part. What embedded insurance really demands The promise of embedded is speed and invisibility: a customer buys a flight and, in the same breath, is offered exactly the right travel cover at exactly the right price, and accepts with one tap. No forms, no friction. Deliver that and you've won. But "exactly the right cover at exactly the right price in one tap" makes brutal demands on your back end: You must price i...
Read more

Insurance Knowledge Graphs: The Foundation AI Needs Before It Can Think

Every insurer wants enterprise AI. Few realise they're missing something much more fundamental. Knowledge. Not data. Knowledge. Insurance companies already possess enormous amounts of information. Policy systems contain customer records. Claims platforms hold loss histories. CRM systems track interactions. Document repositories store underwriting reports. Data warehouses consolidate analytics. Yet AI still struggles to answer surprisingly simple questions. Not because the information doesn't exist. Because the relationships between that information remain invisible. Data tells you what exists A customer database tells you who someone is. A policy database tells you what they bought. A claims system tells you what happened. An accounting platform tells you what was paid. Each system is internally consistent. Together they rarely behave like a connected enterprise. Humans mentally assemble those relationships every day. Computers usually canno...
Read more