What is the difference between treaty and facultative reinsurance, and where does cession show up in the systems you build?

Two axes people collapse into one

The treaty-versus-facultative distinction is about how cover is agreed, and the proportional-versus-non-proportional distinction is about how it responds. They are independent, and conflating them is the commonest error in an interview answer.

A treaty is an agreement covering a defined class of business, under which every qualifying risk written during the treaty period is automatically reinsured. The cedant does not ask permission risk by risk and the reinsurer does not underwrite them individually; the reinsurer underwrote the portfolio and the cedant's underwriting standards. Treaties are usually annual and renegotiated at renewal.

Facultative reinsurance is arranged for one specific risk. The cedant offers it, the reinsurer looks at that risk and accepts or declines, and cover is evidenced by a certificate for that risk alone. It is what you use for something too large, too unusual or explicitly excluded from the treaty. It carries per-risk administrative cost, which is exactly why the treaty exists.

Independently of that, cover can be proportional, where the reinsurer takes an agreed share of premium and losses, as in a quota share where the share is fixed or a surplus treaty where the share varies with the size of the risk; or non-proportional, where the reinsurer pays losses above a retention up to a limit, as in per-risk excess of loss, catastrophe excess of loss triggered by an event rather than a risk, or aggregate covers responding to a year's total. Facultative placements are commonly proportional but need not be, and treaties come in both flavours. Most insurers run a programme of several treaties and layers simultaneously.

Cession as a computation

Cession is the act of passing risk and premium to the reinsurer. In a system it is a calculation that runs at two moments and produces stored records both times.

On the inwards side, when a policy is written or endorsed, the cession engine determines which treaties in the programme apply, in what order, and what share or retention each takes. The output is a set of cession records: ceded premium per treaty, the cedant's retained share, and any ceding commission the reinsurer allows against the ceded premium to reflect the cedant's acquisition and administration costs.

On the claims side, when a loss transaction occurs, the same programme determines recoveries. For proportional treaties this is arithmetic on the share. For excess of loss it depends on where the loss sits relative to the retention and the layer limits, on whether losses from multiple policies aggregate into one event, and on how many times the layer can be reinstated. Event definitions carry real subtlety here, particularly hours clauses that bound how long a single catastrophe event may be treated as continuous.

The ordering question is called inuring. If a programme has both a quota share and an excess of loss, whether the excess applies to the gross loss or to the loss net of the quota share changes the net retained result, sometimes substantially. That ordering is a term of the contracts and must be configuration in the engine, not an assumption in code.

What this demands of the data model

Three things, and the second is the one that catches people.

First, the treaty is a versioned, effective-dated entity in its own right, with participants and their signed shares, because a treaty is typically subscribed by several reinsurers and a broker often sits between. Recording only a total ceded amount without the split by participant means you cannot bill or collect.

Second, cession is computed against the treaty in force on the governing date, and the governing date is a contract term rather than today's date. A risks-attaching treaty covers policies incepting during the treaty period, so the policy inception date governs and a loss occurring after the treaty expires is still covered. A losses-occurring treaty covers losses happening during the treaty period regardless of when the policy incepted, so the loss date governs. Using the current treaty because it is the one your query returns produces cessions that are simply wrong, and the error is invisible until a recovery is disputed.

Third, ceded and net figures are stored transactions, not derived-on-read views. This is the design decision worth arguing for explicitly. If ceded amounts are computed on demand from the current treaty configuration, then every reported reinsurance figure silently changes whenever anyone corrects a treaty record, which makes prior-period reporting irreproducible and makes reconciliation with the reinsurer impossible. Write a gross transaction, a ceded transaction and derive net from the pair; keep them in the same ledger and reconcile them as an invariant.

The consequence, which is a good thing to volunteer, is that a retroactive change to the underlying policy or a restated claim reserve forces the cession to be restated too. A backdated endorsement that increases the sum insured changes the ceded premium for the period in question, and the correction is a new dated cession transaction that reverses and re-issues. This is why the temporal design of the policy and claims systems and the reinsurance design cannot be decided independently.

Bordereaux

A bordereau is a periodic schedule of business or claims sent between parties, most importantly from a coverholder or managing general agent to the insurer whose capacity they are writing on, and onwards to reinsurers. Under a delegated authority, the insurer is on risk for policies it did not itself key: the bordereau is how it finds out what it is on risk for. Premium bordereaux list the policies written, claims bordereaux list the losses and movements.

Treating bordereau ingestion as a low-status file-loading job is a mistake with direct financial consequences. The data arrives as spreadsheets in formats that differ by coverholder and drift over time; it arrives late; it restates prior periods without saying which rows changed. Everything downstream depends on it, including your own reserving, your aggregate exposure monitoring and your own reinsurance recoveries. Market efforts to standardise the format exist, notably in the Lloyd's market, and adoption is partial.

The practical architecture is to ingest each submission as an immutable versioned file, validate on receipt against schema and business rules, reject or quarantine rather than partially load, and reconcile the submitted totals against the cash actually settled. Store what was submitted separately from your corrected interpretation of it, because when the numbers are challenged six months later you will need to show both.

Risk transfer as substance

One last point that engineers rarely raise and that earns disproportionate credit: a reinsurance contract only receives reinsurance accounting treatment if it genuinely transfers risk. A contract with terms engineered so the reinsurer cannot lose is financing dressed as reinsurance, and accounting standards require it to be accounted for as such. Practitioners use rules of thumb to test this and the precise requirements differ between accounting regimes, so name it as a judgement made by finance and actuarial rather than asserting a threshold. The system consequence is real, though: contracts need a flag for their accounting treatment, and it is not the engineer's to set.