A cat layer pays out and puts its limit back. The contract says how: one reinstatement, at 100% additional premium, pro rata as to amount and as to time. Everyone on the desk agrees what that sentence means. Then the spreadsheet charges premium on a reserve that was never paid, or charges again when the reinstated limit erodes a second time, or forgets that the loss happened with four months of the treaty year left. The error is found when the reinsurer’s statement disagrees with yours, which is the most expensive place to find it.
In InsightCede the reinstatement premium is not typed. It is a consequence of the ledger, raised by the engine in the same transaction as the loss cession that caused it, and explained by an agent before the notice reaches the panel.
The rule, as the engine applies it
Every time the engine writes a loss cession to a layer, it asks four questions in order.
- Is it paid? A reserve reinstates nothing until it is paid. Outstanding erosion uses capacity but raises no premium.
- Does the layer reinstate at all, and does it have a premium? A layer with no reinstatements, or no layer premium, raises nothing.
- Is a reinstatement left to buy? The layer can reinstate its limit as many times as the contract grants, and no more. The engine adds up what has already been reinstated on the layer; the reinstated limit is not reinstated again. If nothing remains, the layer is simply eroding its last limit.
- How much, then? The layer premium, times the share of the limit reinstated, times — when the layer is pro rata as to time — the unexpired part of the treaty term at the loss date, times the reinstatement rate.
The two fractions are kept to four decimals on the row, so any premium can be reproduced from the row alone. And when a paid loss comes back down — a recovery, a voided payment — the engine writes a negative row that gives back what that claim had bought, never more.
flowchart LR
A["Loss cession
on a layer"] --> B{"Paid?"}
B -- reserve --> X["Nothing raised"]
B -- paid --> C{"Reinstatement
left to buy?"}
C -- no --> Y["Nothing raised
last limit eroding"]
C -- yes --> D["Layer premium
x share of limit
x time left x rate"]
D --> E["Premium row
on the period's account"]
E --> F["Agent checks used
against allowed
drafts the notice"]
Reproduced from the demo ledger
The demo programme’s position shows $724,929.26 of reinstatement premium. It comes from three rows on one treaty year, VSURE-PROP-CAT 2025: layer 1 is $15M xs $5M with layer premium $1,275,000, layer 2 is $30M xs $20M with layer premium $1,350,000, each with one reinstatement at 100%, pro rata as to time, on a term the engine counts as 364 days (1 January to 31 December).
| Event | Layer | Paid to layer | Share of limit | Time left | Premium |
|---|---|---|---|---|---|
| Windstorm, 16 Aug | 1 | $15,000,000 | 1.0000 | 137/364 = 0.3764 | $479,910.00 |
| Windstorm, 16 Aug | 2 | $8,435,097 | 0.2812 | 0.3764 | $142,888.97 |
| Hailstorm, 2 Nov | 2 | $14,000,000 | 0.4667 | 59/364 = 0.1621 | $102,130.29 |
| Hailstorm, 2 Nov | 1 | $15,000,000 | — | — | nothing: the one reinstatement was bought in August |
| Freeze, 8 Dec | 1 | $0 (exhausted) | — | — | nothing: $13,000,000 retained |
| Total | $724,929.26 |
The fourth row is the one spreadsheets get wrong. The November hailstorm paid layer 1 its second $15 million — the reinstated limit — and the engine raised nothing, because there was no reinstatement left to buy. Charging it would have doubled the layer’s reinstatement premium. The fifth row is what happens next, and it is the subject of the post on exhaustion.
To check the second row by hand: the windstorm paid $8,435,097 into layer 2, which is 0.28117 of its $30 million limit, kept on the row as 0.2812. The loss date left 137 of 364 days, 0.3764. $1,350,000 × 0.2812 × 0.3764 × 100% is $142,888.97. Every row carries the claim, the cession that triggered it, the limit reinstated, both fractions, the layer premium and the result, so a reinsurer who disagrees can be answered with the row rather than a reconstruction.
What the agent adds
The reinstatement agent runs on the claim event, after the engine commits. If the event’s loss cessions raised reinstatement premium, it reads the rows and the layer, and checks the reinstatements used against those the contract allows. Within the allowance, it drafts the notice to the layer’s panel: the layer, the claim, the premium due, reinstatements used: 1 of 1. If the check ever failed, the overrun would be named in the record as a concern. The engine derives the used count from the ledger and caps it, so in practice the check confirms rather than catches — which is the point of checking a figure you did not compute.
The notice is written held at L2, Ask first, on the
reinstatement_send checkpoint. The agent’s definition is short: grounded in the
reinstatement premium rows and the layer’s reinstatements; never invents “a
premium: the engine raised it; the agent checks and explains it.”
The use case, in one table
| A layer reinstated, and the premium noticed | |
|---|---|
| Trigger | A claim event whose paid loss cession reinstated a layer, after the engine commits |
| Actor(s) | The ceded reinsurance analyst; finance, which sees the premium in the net cost of reinsurance |
| Agent | Reinstatement agent |
| Grounded in | The reinstatement premium rows the engine raised; the layer’s reinstatements and reinstatements used; the layer’s panel and contacts |
| Prepares | The reinstatement premium notice to the panel, held; a named concern if more reinstatements were used than allowed |
| Checkpoint & default level | reinstatement_send · L2 Ask first |
| What a person decides | Whether the notice goes; whether the layer’s terms in the programme match the contract the premium was computed from |
| What is recorded | The premium row (limit reinstated, both fractions, layer premium, premium due, the cession that triggered it); the decision record with the check; the outbox row; the answer as feedback |
Where it shows up for finance
Reinstatement premium is a cost of cover, not a share of subject premium, so the Position screen keeps it on its own line — owed by us for putting limits back — and adds it into the net cost of reinsurance beside the ceded premium less ceding commission. A CFO reading the programme’s cost for the year sees it move the day the loss is paid, not when the statement goes out.
Why the premium is the engine’s, not the agent’s
A reinstatement premium is arithmetic on contract terms and committed paid loss. That is exactly the work a deterministic engine should do and a model should not: the same inputs give the same cents, every time, and the row says how. The agent’s job is the part a person would otherwise do after the arithmetic — check it against the layer, explain it, and draft the letter.
What it does not do
- It only knows the terms it was given. The rate, the reinstatement count and whether the layer is pro rata as to time come from the programme. If they were keyed wrong, the premium is computed correctly from the wrong terms — and the agent, which checks the count, not the contract, explains it fluently.
- Time is counted in days between the dates on the treaty. A 1 January to 31 December term is 364 days to the engine. If your wording counts 365, the fraction differs in the fourth decimal.
- One notice per event. When one payment reinstates two layers — the demo windstorm did — the agent prepares a single notice carrying the total premium, labelled with one of the layers; each premium row is listed separately in the evidence.
- Words for a return are the model’s. If the model cannot be reached, the stand-in wording is written for a charge, so a reversal’s notice needs reading before it is accepted.
- A Change is not re-sent. Edits are recorded on the decision; the message released on accept is the agent’s draft.
If your reinstatement premium is worked out in a spreadsheet after the statement disagrees, send us one layer’s terms and its paid losses and we will reproduce the premium row by row.