Loss Triangles Are Built by Hand, and Everyone Pretends That's Fine

Ask an actuary how the loss triangle behind the reserve estimate gets built and you'll often get a slightly embarrassed answer. Data comes out of the claims system, sometimes out of several claims systems, into a spreadsheet. It gets grouped, adjusted, reconciled against finance, and corrected for the known quirks that never got fixed at source. Then a reserving method is applied to it and a number goes into the accounts that materially affects the company's reported profit. The method is rigorous and well-documented. The data preparation feeding it frequently isn't.

Why the preparation is the weak link

Reserving methodology gets enormous scrutiny — peer review, actuarial standards, regulatory oversight. The pipeline that produces the triangle usually gets far less. It's treated as plumbing rather than as part of the estimate, even though a mis-grouped claim, an inconsistent transaction date, or a currency conversion applied at the wrong point moves the answer just as surely as a change in method. The rigour is concentrated on the last step of a process whose earlier steps are manual, undocumented, and dependent on whoever has done it before.

Where it breaks down

  • Manual assembly. The triangle is built through a sequence of extracts and spreadsheet steps that exist in one person's working file, not in a governed pipeline.
  • Inconsistent claim grouping. How claims map to reserving classes depends on fields that were captured inconsistently, so the cohorts aren't as clean as the triangle implies.
  • Silent corrections. Known data problems get patched during preparation, and the patches aren't recorded, so nobody can reproduce the triangle later.
  • No reconciliation trail. When the triangle and the finance ledger disagree, resolving it is detective work rather than a lookup.

Why it's a data-foundation problem

None of this is an actuarial-science problem — the methods are sound. It's that the input to those methods isn't produced by a governed, reproducible, auditable process. Move triangle construction out of spreadsheets and into a pipeline with defined claim grouping, recorded adjustments, and lineage back to source transactions, and reserving gets something it currently lacks: an input you can reproduce, explain, and defend. That's the same lineage-and-governance foundation behind regulatory reporting and model risk management, applied to the number that shapes your balance sheet.

What good looks like

  1. A governed triangle pipeline rather than a spreadsheet assembled by hand each quarter.
  2. Defined, consistent claim grouping so reserving cohorts mean what they claim to mean.
  3. Recorded adjustments so every correction applied during preparation is visible and repeatable.
  4. Lineage to source transactions so triangle-to-ledger differences are explainable, not investigated.

Reserving is one of the most consequential numbers an insurer produces, and it rests on a data preparation step that rarely gets the same scrutiny as the method on top of it. Making that input governed and reproducible is exactly the kind of work we do with insurers at IntelliBooks.

You wouldn't accept an unreviewed reserving method. It's worth asking why an unreviewed data pipeline feeding it is treated as acceptable.

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