Claims System Modernization

Part 4 covered the system that decides what to charge. This part covers the system that decides what to pay. The claims platform is where the promise the policy made comes due — and where the financial and reputational stakes of legacy software are most visible. A rating error costs margin over time; a claims error shows up immediately, in mispaid claims, distorted reserves, and the customer experience at the worst possible moment. Modernizing claims is core work with the volume turned up.

What a claims system carries

A claims system runs the loss lifecycle:

• First notice of loss (FNOL) — intake, triage, and assignment.
• Investigation and adjustment — gathering facts, applying coverage, negotiating.
• Reserving — the estimate of ultimate cost, set and revised through the claim’s life. Reserves are not bookkeeping; they feed financial statements and statutory reporting.
• Adjudication — applying the policy and the rules to decide what is owed.
• Payment and recovery — issuing payments, pursuing subrogation and salvage, handling reinsurance recoveries.

And it integrates outward at least as widely as the PAS: it reads policy and coverage from policy administration, posts money through billing, cedes losses to reinsurance, feeds fraud detection and analytics, and produces a stack of regulatory and statutory reports. Each integration is a contract, and in a legacy system most of those contracts are undocumented.

Where the rules hide, and why they bite

Like the rest of the core, the claims logic that matters is undocumented and load-bearing — but two things make claims distinctly unforgiving.

Reserving and adjudication touch the financials directly. Reserves roll up into the numbers the company reports and the regulator examines. Adjudication decides cash out the door. A rule silently dropped in a rebuild — a reserve-adjustment trigger, a coverage interaction, a payment-timing rule — doesn’t fail loudly; it quietly produces wrong reserves or mispaid claims that may not surface for months, by which time they’re expensive and embarrassing.

The rules are wrapped in workflow and judgment. A claims system encodes not just hard rules but the process — routing, escalation, authority limits, the special handling for litigated claims or catastrophe events. Telling the genuine adjudication rule from the workflow convention from the dead branch is the same business-rule recovery problem from earlier in the series, applied to logic that’s interleaved with decades of process accretion.

Slice the claims book; prove reserves and payments match

The execution mirrors the rest of the core, tuned to what claims can’t afford to get wrong.

1. Recover the adjudication and reserving rules as living specs, including the integration contracts to policy, billing, reinsurance, and reporting. Validate with the adjusters and analysts who still hold the why.
2. Slice by claim type or line of business. A claim type — auto physical damage, a particular liability line, workers’ comp medical — is a coherent slice with its own rules, reserving practice, and reporting. Rebuild it end to end before the next.
3. Prove parity on real claims. Run the modern slice in the shadow of the legacy system against real and historical claims, and compare the outputs that matter: the reserve set, the adjudication decision, the payment amount and timing, the data posted to downstream systems. This is parity validation. On reserves and payments, identical-in, identical-out is the standard.
4. Migrate open claims in cohorts. A facade routes claim handling to the modern slice once it’s proven, and open claims move in controlled cohorts with rollback available, so adjusters experience continuity rather than a cutover weekend.

This is the incremental-versus-big-bang choice again, and claims is where the case for incremental is most visceral: a botched big-bang claims cutover means losses you can’t process, reserves you can’t trust, and policyholders waiting on payments — the exact moment an insurer most needs to be reliable.

The open-claims problem

Claims modernization carries a complication the other core systems have in milder form: the book is in motion. A policy in force is relatively static between transactions; an open claim is a live, changing case — reserves being revised, payments being issued, correspondence and documents accumulating, litigation timelines running. You can’t pause a claim while you migrate it, and you can’t lose a single dollar of its history.

That makes the data migration its own discipline. Open claims carry years of accreted state — financial transactions, reserve history, diary entries, documents, recovery and reinsurance positions — and all of it has to land in the modern system intact and reconcilable to the legacy record. The practical answer is the same slicing logic applied to data: migrate open claims in cohorts, reconcile the financials of each cohort against the legacy system before trusting it, and keep the legacy system authoritative until a cohort has proven out. Long-tail claims — workers’ comp, certain liability lines that stay open for years — may simply run off on the legacy system rather than migrate, because the cost and risk of moving a claim with a decade of history outweighs the benefit. Letting the tail run off while new claims open on the modern system is often the cheapest safe answer.

What “better” looks like — after parity

It’s worth being concrete about the upside, because claims is where modernization’s payoff is most tangible once the platform is safe. A modern claims core makes straight-through processing of simple claims feasible, surfaces the data that fraud and analytics models need, gives adjusters tooling that doesn’t fight them, and integrates cleanly with the digital channels customers now expect at the worst moment of their year. None of that is the reason to modernize the platform — and none of it should be conflated with the parity-preserving rebuild. It’s the reason the modernized platform is worth having: once the new system provably pays and reserves identically, you finally have a foundation you can improve deliberately, instead of a system you’re afraid to touch.

Where AI changes the economics

The slow, expensive part of claims modernization is mapping adjudication and reserving logic out of a system that’s accreted process for decades and reading every integration contract it depends on. AI-accelerated discovery reads the claims code, the data flows, and the downstream interfaces together and drafts the rules and contracts as reviewable specs — the analysis-time gain of roughly 10× over manual review that makes recovering the whole claims path feasible rather than sampling it and hoping. Senior engineers and claims experts validate; parity proves the rebuild. AI reads at scale; people and evidence decide what’s true.

Parity first, redesign second

Claims modernization tempts teams to redesign the process while they’re in there — and sometimes that’s right, because the legacy workflow really is the constraint. But conflating two changes is dangerous: re-architecting the platform and redesigning the claims process at the same time makes it impossible to tell a parity failure from an intended change. The disciplined sequence is to modernize to behavior parity first — prove the new system pays and reserves identically — and then improve the process deliberately, as its own change with its own validation. Parity is what lets you tell “we changed this on purpose” from “we broke something.” And as ever, a stable, low-volume, cheap-to-run legacy claims workload under no pressure can be a legitimate candidate to leave in place.

Where this leads

We’ve now walked the three core systems — policy, rating, claims — and the same answer keeps surfacing: recover the rules, slice it, prove parity. That raises the question every insurance program eventually argues about: do you buy a packaged core or build your own? Part 6, Core Insurance Modernization: Build vs Buy, frames that decision honestly — including why the build-versus-buy question matters less than how you execute either path.