Every insurance data engineer eventually runs into the same uncomfortable fact: a claim marked settled is not the same as a claim that is financially closed. Subrogation is where that gap becomes impossible to ignore.
When a health or life insurer pays out on a claim and then recovers part of that payout from a liable third party — a negligent driver, an employer, a manufacturer, another carrier — the recovery arrives weeks, months, sometimes years after the original claim was booked, reserved, released, and reported. The recovered amount is not a new transaction in any meaningful accounting sense. It retroactively alters the net cost position of a claim your pipeline already tombstoned.
And that is where the trouble starts.
Settled Does Not Mean Closed
Most claim data pipelines I have worked with — and I have owned a few in Turkish life and pension shops — treat the claim lifecycle as a forward-only state machine. Claim opened, reserved, adjusted, paid, settled. Once settled, the record is frozen for downstream consumers: the actuarial cube, the IFRS 17 measurement model, the regulatory reports to the regulator, the reinsurance cession files, the management P&L.
The pipeline was designed on an assumption that looks reasonable on a whiteboard: settled events are terminal. They are not. Subrogation blows that assumption apart because:
- The recovery is legally tied to the original claim, not a standalone event.
- The net loss ratio, the loss development triangle, and the case reserve history all shift when the recovery lands.
- Reinsurance recoveries and cession accounting are pegged to net loss, not gross loss.
- Regulatory reporting periods have already closed on the gross number.
So now you have a recovered amount that logically belongs to a claim record whose immutability your entire downstream stack depends on.
The Parallel Ledger Nobody Designed
What happens in practice is that subrogation gets shunted into a parallel ledger. Sometimes it is an Excel file maintained by the recovery unit. Sometimes it is a separate table in the claims system with a foreign key nobody joins on in the warehouse. Sometimes it is a general ledger adjustment booked at the portfolio level with no per-claim traceability at all.
I have seen all three in production, occasionally in the same company. The consequences are predictable:
- Actuarial models understate recovery patterns because the recovery data lives outside the loss triangle source system.
- IFRS 17 CSM calculations get manual overlays because the measurement model cannot reopen fulfillment cash flows for closed cohorts without breaking the audit trail.
- Reinsurance disputes multiply because the ceding calculation uses gross figures the reinsurer then contests against their own net view.
- Regulatory filings and internal management accounts disagree on the same claim, and neither side is technically wrong.
The recovery unit, meanwhile, is measured on cash collected. They have no incentive to fight for a data model that stitches their world back into the claim record. Their spreadsheet works fine for them.
Why Reopening the Claim Is Not the Answer
The naive engineering response is: just reopen the claim record when a recovery lands, restate the net cost, and let the pipeline propagate the change. I have watched this fail three times.
It fails because downstream systems are not idempotent with respect to restated history. Reopening a settled claim from Q1 2023 in Q4 2024 triggers:
- Re-emission of the claim to every consumer subscribed to the claims topic, most of which have no logic to handle a restatement versus a new event.
- Recalculation of loss triangles that were the input to reserves already booked and audited.
- Version conflicts in the regulatory reporting layer where the prior filing has been signed off by the CFO and submitted to the regulator.
- Cascading changes to profit-sharing and agent commission accruals that were paid out months ago.
You are not just changing one number. You are asking the entire finance stack to admit a prior period was wrong, when accounting standards give you perfectly legitimate mechanisms — subsequent event recognition, recovery income booked in the current period — to avoid that admission entirely.
What Actually Works
After enough scars, the pattern I trust is this:
- Model subrogation as a first-class event linked to the claim, not a mutation of the claim. The claim record stays immutable at settlement. The recovery is a separate fact with a strong reference back.
- Expose two views downstream: gross-settled and net-of-recovery. Let each consumer pick the semantic they need. Actuarial wants net-of-recovery over the development period. Regulatory reporting wants gross-as-filed. Reinsurance wants both, depending on the treaty.
- Book recoveries in the current accounting period with a link to the origination period. This respects the accounting closing discipline without losing the analytical linkage.
- Give the recovery unit a real system, not a spreadsheet. As long as recoveries live in Excel, the parallel ledger will keep drifting from the claims warehouse and someone will be reconciling it by hand at every quarter close.
- Track recovery expectation, not just recovery realization. The moment a subrogation case is opened by the recovery lawyers, that is signal. Capturing expected recovery lets the actuary model recovery lag as a proper stochastic process rather than a surprise cash inflow.
The Broader Lesson
Subrogation is the cleanest example, but it is not the only one. Reopened claims after litigation, ex gratia payments booked against previously denied claims, retroactive premium adjustments, cohort transfers under portfolio migrations — insurance financial data is riddled with events that violate the closed-means-closed assumption.
If your pipeline was built on that assumption, you are not running an insurance data platform. You are running a snapshot generator that happens to work most of the time. The subrogation case is where you find out which one you actually built.
Design for restatement from day one, or accept that your finance team will be reconciling parallel ledgers forever. There is no third option.