Run-Off Books: The Data Nobody Owns Anymore

Every insurer of any age carries business it no longer writes. A line it exited, a portfolio it acquired and wound down, a product withdrawn a decade ago. The policies are closed to new business but the liabilities are alive — claims still arrive, reserves still move, regulators still ask questions. And the data behind that run-off book sits in a system nobody actively develops, maintained by people who have mostly moved on, governed by no one in particular. It's the quietest data risk on the balance sheet.

Why run-off data decays

Attention follows new business. The systems and data supporting the active book get investment, migration, and governance; the run-off portfolio gets left where it is, because migrating it has cost and no upside anyone can point to. Over time the people who understood its quirks leave, the documentation ages, and the platform drifts further from anything current. The liabilities don't shrink as fast as the institutional knowledge does, and eventually you're administering claims against data you can no longer fully explain.

Where it breaks down

  • No owner. The business unit that wrote it is gone, so nobody is accountable for the data's quality or continuity.
  • Frozen platforms. The book sits on a system that's out of support, hard to query, and expensive to keep alive purely to answer occasional questions.
  • Lost context. The people who knew what the fields meant and which records were exceptions have retired or left.
  • Invisible in group reporting. Because it isn't in the main pipeline, run-off data gets bolted onto reporting by hand each period.

Why it's a data-foundation problem

Run-off isn't a technology problem so much as an ownership-and-continuity one. The liabilities can outlive the systems by decades, so the data needs to be extracted into a governed, documented, queryable form that doesn't depend on keeping a dying platform breathing. Do that and you can decommission the old system, answer regulatory questions as a query rather than an archaeology project, and fold run-off into normal reporting. It's the same migration-and-governance foundation the active book needs — applied to the part of the business nobody is arguing for.

What good looks like

  1. A named owner accountable for run-off data, not an orphaned portfolio.
  2. Data extracted into a current, governed store so the liability doesn't depend on a frozen platform.
  3. Documented meaning — field definitions and known exceptions captured before the last person who knew them leaves.
  4. Included in normal reporting rather than bolted on manually each quarter.

Run-off books carry real liabilities on data that is quietly rotting because nobody's job depends on it. Extracting, documenting and governing that data before the knowledge disappears is exactly the kind of work we do with insurers at IntelliBooks.

The business stopped writing it years ago. The obligations, and the questions, didn't stop with it.

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