The Number Nobody Could Explain

The demo was going well. That should have been the first warning.

On the screen was a claim recovery figure — the amount the reinsurers owed back on a large loss. Seven figures. The kind of number that, if it's wrong, someone eventually loses their job over. The system had computed it in the time it takes to blink. Quota share applied, excess-of-loss layers stacked correctly, reinstatement premium netted off, currency converted, the lot. Clean. Elegant. Right.

The room was impressed. The math was beautiful.

Then someone at the far end of the table — not an actuary, not an engineer, just a quiet finance person who'd sat through a thousand of these — asked the only question that has ever mattered in this business.

"Where did that number come from?"

And the room went quiet in a way that told me everyone had assumed someone else knew.

Here's what I've learned after years inside reinsurance platforms, and it's the opposite of what everyone believes going in:

The math is the easy part.

I know how that sounds. Reinsurance has a reputation for being mathematically brutal — the layers, the treaties, the actuarial modelling, the Greek letters. And yes, the formulas have teeth. But a formula is deterministic. Feed it the right inputs and it produces the right output, every time, forever. Once you've built the calculation engine correctly, the math never surprises you again.

The inputs surprise you. Constantly.

Because "where did that number come from" is not a question about arithmetic. It's a question about lineage — the full chain of custody of a single figure, back through every rule, rate, version, and decision that produced it. And in reinsurance, that chain doesn't just run deep. It runs backwards through time.

Let me show you what was actually sitting behind that seven-figure recovery, because this is where the real complexity lives.

Start with a simple-sounding question: which treaty applied?

Obvious, right? The one in force. Except a claim doesn't happen when you process it. It happens on the loss date — which might be eighteen months before anyone keyed it in. So you don't want the treaty in force today. You want the treaty as it existed on the day the loss occurred. Two different worlds, and the system has to know which one you're standing in.

Now make it worse. That treaty was amended after the loss date. A participant's share was adjusted retroactively — a correction, a novation, a late endorsement. So now there are two versions of the truth: what was true then, and what we later decided was true then. Both are real. Both matter. An auditor will ask for one; a reinsurer's disputes team will ask for the other.

I wrote once that reinsurance stays under-digitised partly because the data is messy and shared — every party in a deal holding a slightly different version of the truth. That's true, and I stand by it. But it undersells the problem. The versions of the truth aren't only spread across parties. They're spread across time — and time is the one axis you can't email someone to reconcile.

This is the part outsiders never see coming. In most systems, data has one timeline. In reinsurance, every number lives on at least two: the world as it was, and the world as we now know it to have been. Get those tangled and your recovery isn't wrong by a rounding error. It's wrong by a reinsurer's entire share.

We're not done. We haven't even reached the hard part.

That recovery didn't come from one treaty. It came from a sequence of them — and the sequence is load-bearing. One layer's recovery reduces the base that the next layer calculates from. Reinsurance that "inures to the benefit" of other reinsurance. Apply them in the wrong order and every downstream number is quietly, confidently wrong. Not crash-wrong. Plausibly wrong. The most expensive kind.

I once described the "simple" change a stakeholder requests that quietly breaks how a treaty settles at quarter-end. This is the machinery underneath that sentence. It breaks quietly precisely because the arithmetic still looks perfect — nothing errors, nothing crashes. What shifted is the lineage beneath the number, and lineage doesn't announce itself. It just waits for someone to ask.

Then currency. Which exchange rate? The one on the loss date, the accounting date, the settlement date? Pick the wrong "as-at" and you've introduced a discrepancy that no one will notice until the year-end reconciliation, when it will be someone's problem for three weeks.

Then reserve development. The claim isn't static. It breathes. Reserves move quarter after quarter for years, and every movement has to re-trace the entire lineage above — same treaty version, same order, same rates — and restate the prior figures without corrupting them.

So when the quiet finance person asked "where did that number come from," the honest answer was: from a loss that happened on a date, filtered through a treaty as it existed on that date but as amended by a decision made later, applied in a specific order relative to other treaties, converted at a rate as-at another date, and developed across eleven quarters, each of which has to remain independently reconstructable.

That's not a calculation. That's an act of memory.

Here's the reframe that changed how I see these systems entirely.

A reinsurance platform's real product is not computation. Anyone can compute. Its real product is defensible memory — the ability to stand in front of an auditor, a regulator, or a reinsurer who is refusing to pay, point at a number, and reconstruct, without hand-waving, exactly how it came to be. As of any date. Under any version of the truth. In a currency, in an order, through a chain of amendments, with every link intact.

Systems that only get the math right feel amazing in the demo. They fall apart the first time reality asks them to explain themselves. Because reality doesn't dispute your arithmetic. It disputes your provenance. Nobody has ever argued that two plus two isn't four. They argue about which two you used, and when it was true, and who changed it.

The teams that struggle in reinsurance are the ones optimising the engine. The teams that win are the ones who treat lineage as the actual product and the math as a feature of it.

The demo, in the end, was fine. We could answer the question. It took a few clicks to walk the recovery back to its origin, and the finance person nodded, satisfied, and moved on. Nobody clapped. Nobody remembers it.

But that quiet moment taught me more than any calculation ever did.

The hardest part of a reinsurance platform isn't the math. The math is a solved problem sitting in a stored procedure. The hardest part is being able to look at any number, on any day, and answer the question that ends every argument in this industry before it starts:

Where did that come from?

I've argued before that reinsurance is the most under-digitised corner of insurance, and that the next wave of value is hiding exactly there. This is where it hides. Not in a faster calculation engine — in a system that remembers. And I've argued that I'd rather build a rough version of a thing than write a perfect description of it. This is the same instinct aimed one level deeper: in reinsurance, the most valuable thing you can build isn't the feature. It's the trail the feature leaves behind.

Build the system that can always answer that, and the math will take care of itself.

Build the one that can't, and no amount of beautiful arithmetic will save you the day someone finally asks.