Insurers buy insurance, and it changes the arithmetic of every claim
Reinsurance passes part of a carrier's risk to another carrier. For an engineer
it is not a financial abstraction — it is cession logic that runs over
policy and claim data and produces amounts a third party owes you.
The two shapes behave completely differently, and conflating them is the usual
domain error.
Proportional, such as a quota share, takes a fixed percentage of premium and
of loss. A 30% quota share means the reinsurer receives 30% of the premium and
pays 30% of every claim, from the first pound. Allocation is a multiplication.
Excess of loss pays only above an attachment point, up to a limit. A layer
written as 750,000 excess of 250,000 pays nothing until the loss exceeds
250,000, then pays up to 750,000 above it. Allocation depends on the size of the
loss, which means it depends on the total rather than on the payment in front
of you.
Claim CL-8841, ultimate incurred 900,000
Quota share 30%, inuring first -> reinsurer 270,000, retained 630,000
XoL 750k xs 250k applied to retention -> layer pays 630,000 - 250,000 = 380,000
Net retained by the carrier = 250,000
The phrase to notice is inuring: the order in which structures apply is set
in the contract, and applying the excess layer before the quota share gives a
different answer. That order is a property of the programme, not a default.
Payments are partial; the layer is not
This is where implementations go wrong. A claim is paid in instalments, and an
excess layer attaches on the claim's total, not on each payment.
An interim payment of 100,000 on a claim expected to reach 900,000 cedes nothing
to a layer attaching at 250,000 — the layer has not been reached. A later
payment that takes cumulative paid past the attachment point cedes partly, and
everything after it cedes fully until the limit is exhausted.
So cession is computed against the running cumulative for the claim, and
each payment's cession is the difference between the cumulative recoverable
before and after. Compute per payment in isolation and you will either cede
nothing or cede everything, and the error only shows up on claims that cross an
attachment point.
The same reasoning applies in reverse when a reserve is strengthened: the
expected recoverable moves even though nothing has been paid, and finance wants
that reflected.
The date mismatch that shapes the data model
Here is the detail that makes this a data problem rather than an arithmetic one.
Treaties are typically agreed by underwriting year — the year the underlying
policy was written. Claims arrive by accident date. A policy written in
November 2024 covers accidents into 2025, so a 2025 accident on that policy
cedes to the 2024 treaty, while a 2025 accident on a policy written in February
2025 cedes to the 2025 treaty.
One claims file therefore does not have "a treaty". It has whichever programme
covered the policy it belongs to, and two claims from the same week can cede to
structures negotiated a year apart with different attachment points and
different reinsurers.
The consequence for the schema is that a claim payment must remain sliceable,
years later, by treaty, layer, accident date, underwriting year and line of
business. Storing a single ceded_amount on the payment answers the accounting
question today and none of the questions asked afterwards.
A recoverable is an asset, not a discount
The reinsurance share is not a reduction of the claim. The carrier pays the
insured in full and separately holds a reinsurance recoverable, which is an
asset on its balance sheet and carries the reinsurer's credit risk.
Two things follow that candidates often miss. The gross figure remains the
claim's cost and is what the actuary reserves on; the net figure is a separate
view. And a recoverable that the reinsurer disputes or cannot pay is a bad debt,
which is why carriers monitor concentration by reinsurer and why a system has to
report exposure per counterparty rather than only in total.
Reporting to the reinsurer happens through a bordereau — a periodic schedule
of the premiums ceded and the claims and recoveries under the treaty. It is read
by a person at another company who will query anything that does not
reconcile, which is another reason the underlying detail has to survive.
Two complications worth naming
Reinstatements. A catastrophe layer that has been exhausted may be
reinstated, usually for an additional premium, and often a limited number of
times. So a layer's available limit is itself a moving quantity with its own
history, not a constant read from the contract.
Aggregation. Catastrophe cover attaches per event rather than per claim,
which means the system must group claims into events — one storm, thousands of
claims — and apply the layer to the aggregate. That grouping is a judgement
recorded against the claims, with an hours clause in the contract defining how
long a single event may last, and it changes the recoverable substantially.
What to keep
The short version of the whole answer. Keep every payment and every reserve
movement at gross, with the claim's accident date and the policy's underwriting
year attached. Store the cession as its own derived record per payment per
treaty per layer, with the treaty version and the cumulative position it was
computed against. Never store only the net.
That is enough to reproduce any cession on demand, which is what a reinsurer's
query two years later actually requires.
A treaty attaches by the year the policy was written and claims arrive by the
date of the accident, so the two never line up — which is why the payment has
to stay sliceable rather than netted.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).