A claim payment goes out. How does your system work out how much of it a reinsurer owes, and what does that require you to have kept?

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.