Programs

A cedent rarely transfers its risk with a single contract. It assembles a program: the structured set of reinsurance protections bought to cover one set of exposure — a property-catastrophe book, a casualty account, a single large risk. A program is the container for everything a placement needs: the exposure being protected, the layers structured on top of it, and the terms that govern them. It is the unit a cedent buys, a broker places, and a reinsurer prices and renews.

Programs span a wide spectrum of uses. A regional insurer buys a property-catastrophe program to protect its homeowners book; a reinsurer buys a retrocession program to protect the book it has assumed; two carriers enter a risk-sharing agreement; a cedent sponsors a cat bond to move peak risk into the capital markets. The structures differ, but the idea is constant: a coordinated set of protections on one defined exposure.

This page is about how that set is put together — the common shape, a tower of layers, and the relationships a program can add on top of it.

The common shape: a tower of layers

Most programs are vanilla: a stack of excess-of-loss layers, each covering a band of loss above the one below it. The industry calls the stack a tower. A cedent that retains the first $10M of any catastrophe might buy a $10M xs $10M layer, a $30M xs $20M layer above it, and a $50M xs $50M layer above that — three layers covering loss from $10M up to $100M, each placed (often with a different panel of reinsurers) as its own contract.

In a vanilla tower the layers are independent. Each one filters the subject loss, applies its layer, and computes its gross loss without reference to any other layer — every layer reads the same exposure, each at a different band. Evaluate them in any order, or all at once; the program’s total ceded loss is the sum. Nothing here is new: it is the single-contract evaluation from earlier in the chapter, repeated once per layer and added up.

Key Insight

A program is not a new kind of object. It is a bundle of contracts — each still a composition of financial terms — collected because they protect one exposure and are bought together. The bundling is what makes it a program; the layers need not depend on one another. A plain tower of independent layers is already a complete program.

When layers reference one another

Some programs add relationships between layers, where one layer’s result changes what another layer sees. Three appear in practice:

• Inuring — one layer’s recoveries are subtracted from another’s subject, so the same loss is not recovered twice.
• Sourcing — one layer’s gross loss becomes another’s subject (the retrocession case).
• Top & drop — a single block of limit responds at a high attachment or drops down to a lower one, depending on how the year unfolds.

These are optional features, not part of the definition — a tower with none of them is still a program. But when present, they make the layers interdependent: a layer can no longer be evaluated in isolation, because its subject depends on another layer’s output. The rest of this page works through inuring in depth, since it is the relationship SunCoast’s program uses; sourcing and top & drop are deferred to their own sections.

SunCoast’s program

The risk-profiling story characterized SunCoast’s subject loss: roughly $275.6M of expected annual loss, hurricane-dominated, with exposure spread across the Gulf. SunCoast protects that book with three layers:

Layer	Type	Covers	Structure	Premium
C1	CatXoL	Florida hurricane, per occurrence	$30M xs $10M, 1 reinstatement	$20M
C2	AggXoL	CA/AZ earthquake, annual aggregate	$10M xs $15M	$5M
C3	AggXoL	All-US, annual aggregate, net of C1, C2	$50M xs $300M	$13M

Two of these are ordinary, independent layers: C1 caps individual Florida hurricanes, C2 caps a bad year of California quakes. C3 is the one added feature — a whole-book backstop that responds only in a genuinely catastrophic year, and only for loss C1 and C2 have not already absorbed. That “net of C1 and C2” clause is an inuring relationship. SunCoast’s program is not exotic: it is a standard catastrophe program with a single inuring edge on top of an otherwise vanilla structure.

C1 and C2 read the subject loss directly and can be evaluated in any order. C3 depends on both — it cannot be computed until they are, because its subject is defined in terms of their recoveries.

Inuring

Inuring is the relationship where one layer’s recoveries reduce the subject loss of another. “C1 and C2 inure to the benefit of C3” means C3 responds only to the loss left after C1 and C2 have paid. Its purpose is to prevent double recovery — the same dollar of loss being collected once by a lower layer and again by the backstop.

For SunCoast the mechanic is arithmetic on per-trial losses. Because C3 is an aggregate layer, the netting happens at the trial-aggregate level: for trial $j$, C3’s subject is SunCoast’s total annual loss minus what C1 and C2 recovered,

$$L_j^{\text{subject}(C_3)} = L_j^{\text{total}} - L_j^{\text{gross}(C_1)} - L_j^{\text{gross}(C_2)}$$

and C3’s aggregate layer covers that net figure:

$$L_j^{\text{gross}(C_3)} = \min\!\big(\max(L_j^{\text{subject}(C_3)} - 300,\; 0),\; 50\big)$$

No new financial term is involved — C3 is still an aggregate excess layer. Inuring changes only the loss it covers: the net aggregate rather than the gross one.

Watch Out

The trial-aggregate netting above is correct because C3 is an aggregate layer. If the inuring layer had per-occurrence terms, the netting would have to happen at the occurrence level — each occurrence’s loss reduced by the recoveries the lower layers paid on that occurrence, before the occurrence layer applies. Netting per-trial totals would be wrong there, because an occurrence layer depends on which occurrence the remaining loss belongs to, not on the annual sum alone. Inuring is applied at the resolution the downstream layer operates on.

Remember

Inuring is a property of the program, not of any one layer. C3’s own definition — an AggXoL at $50M xs $300M — says nothing about C1 or C2. The netting lives in how the layers are wired together. Move C3 to a different program and it covers a different subject; the contract itself is unchanged.

Where inuring changes the answer

Netting only matters in the trials where it moves a payout. Across SunCoast’s 20-trial demo tier, C3’s $300M attachment is cleared by the gross aggregate in seven trials — but in two of them, subtracting the C1 and C2 recoveries pulls the subject back below attachment, and C3 pays nothing:

Trial	Gross aggregate	C1 + C2 recoveries	Net aggregate	C3 on gross basis	C3 net of C1, C2
1	$616.2M	$8.2M	$608.0M	$50.0M	$50.0M
2	$489.1M	$32.3M	$456.8M	$50.0M	$50.0M
3	$468.2M	$42.3M	$425.9M	$50.0M	$50.0M
4	$309.2M	$13.9M	$295.3M	$9.2M	$0.0M
8	$303.2M	$0.0M	$303.2M	$3.2M	$3.2M
11	$305.3M	$37.9M	$267.4M	$5.3M	$0.0M
13	$378.2M	$22.3M	$355.9M	$50.0M	$50.0M

Trial 4 is the clearest. The gross book reaches $309.2M — just over C3’s $300M attachment — so a backstop applied to the gross aggregate would pay $9.2M. But C1 and C2 have already recovered $13.9M of that year’s loss; net of those recoveries the aggregate is $295.3M, below attachment, and C3 correctly pays $0. The $9.2M a gross-basis backstop would have paid was loss the lower layers had already covered. Trial 11 behaves the same way. Without the inuring edge, SunCoast would recover those amounts twice.

helios_re/program_ceded.py Python

▶ Run Reset

In Practice

Double recovery is a correctness problem with three faces, and only one of them is the engine’s fault:

1. Engine correctness. The implementation of the financial terms must not double-count — an aggregate layer that re-adds an occurrence, an inuring edge applied twice. This is a hard correctness bug, but a bounded one: careful engineering and thorough tests catch it, and once the terms are right it rarely resurfaces except when new functionality lands.
2. Mis-structured programs. Far more common, and much harder to catch automatically: the terms are correct but combined in a way that double-recovers. Two CatXoLs written $10M xs $15M and $10M xs $20M both cover the $15M–$20M band — a data-entry slip, a mis-read submission, or an inuring clause that was meant to apply and was overlooked. The engine cannot know this is wrong: the numbers are internally consistent — but not what the placement intended.
3. Deliberate overlap. Occasionally double recovery is contractually correct — a kick-back or bonus the available terms cannot express directly. A “5% discount on consumed-limit premium for large events” might be modelled as the coverage layer plus a second $10M xs $10M layer with a trigger at $100M and participation premium × 0.05 / limit, deliberately paying on top.

An engine can guarantee it evaluates the terms it is given correctly; it cannot guarantee the terms it is given are the program someone meant to buy. That gap is where structural review, reconciliation, and tests against expected payouts earn their keep.

Trial by trial, the three layers rarely peak together: C3 reaches its limit only in the four heaviest whole-book years (and pays a token $3.2M in trial 8), C1 spikes on Florida hurricane trials, and C2 contributes its steady earthquake band. How the layers are structured — here including the inuring edge — is what determines the capital the program demands, which the standalone pricing story works out.

C1 · FL hurricane CatXoL C2 · CA/AZ earthquake AggXoL C3 · All-US AggXoL (net of C1, C2)

SunCoast's program ceded to Helios Re, trial by trial. C1 tracks Florida hurricane years; C2 is a steady earthquake band; C3 — the All-US aggregate, net of C1 and C2 — hits its $50M limit in the four heaviest whole-book years (trials 1, 2, 3, 13), pays a token $3.2M in trial 8, and is otherwise dark — including trial 4, where the gross book cleared its attachment but netting C1 and C2 pulled it back under. The layers peak in different trials, which is why the program's capital comes in below the sum of the layers'.

Evaluating a program with edges

A vanilla tower imposes no evaluation order — its layers are independent, so an engine can run them however it likes. An inuring (or sourcing) edge changes that. For the SunCoast program, contract C3 cannot be computed until contracts C1 and C2 are evaluated, because C3’s subject is defined net of their recoveries. A correct evaluator processes a program in dependency order — a topological sort over its edges. In SunCoast’s program, C1 and C2 (no incoming edges) run first, in parallel; C3 waits for both.

For three layers this is obvious. For a real placement — dozens of layers, retrocessions sourcing off the gross book, sections inuring to one another — it is the difference between a correct evaluation and a subtly wrong one. The per-trial independence the toolkit established still holds within each stage, so the expensive part — running each layer across millions of trials — stays embarrassingly parallel. Only the thin edges between layers impose order.

Watch Out

When a program has edges, the dependency graph is best derived, not hand-maintained. That C3 depends on C1 and C2 falls out of C3’s subject being defined net of them; a separate, hand-kept “C3 depends on C1, C2” declaration drifts out of sync the first time someone edits a layer. Read the dependencies off the inuring and sourcing clauses; do not store them twice.

What carries forward

A program is a bundle of layers on a shared exposure — the unit a cedent buys to cover a defined risk. Most programs are vanilla towers of independent excess-of-loss layers, each a composition of financial terms evaluated on its own and summed. Some add relationships between layers — inuring (recoveries netted out of a downstream subject), sourcing (one layer’s gross becoming another’s subject), or top & drop (one limit, two attachment points) — which make the layers interdependent and impose an evaluation order, without changing what any single layer is.

With the program assembled, two questions follow. Pricing asks what the whole program is worth — the ceded distribution its layers produce and the capital their structure demands. Portfolio roll-up asks what the program does to a reinsurer’s wider book. Both are taken up in the Applications chapter.