Reinsurance Treaty and Cession Management: Knowing Exactly What You Keep After a Catastrophe

Why cession errors stay invisible until they are catastrophic

A reinsurance programme is a set of promises about what happens on the worst day. On every ordinary day, the difference between a correct cession and a slightly wrong one is a rounding error in a ceded premium account that nobody reviews. On the worst day it is the difference between a manageable loss and a capital event.

The way most carriers get here is not negligence. A quota share is genuinely simple, so it went in a spreadsheet. A surplus treaty was added, then a per risk excess layer, then a catastrophe programme with three layers and reinstatements, then facultative on a handful of large accounts. Each was added by an actuary or a reinsurance accountant who understood it perfectly. Eight years later the workbook has thirty tabs, links to two other workbooks, one of which now lives on a laptop, and the logic for applying inuring reinsurance in the right order exists only as a habit.

The exposure is concentrated in a specific place: the calculations that only run in unusual circumstances. Reinstatement premium after a large event. The interaction between a per risk treaty and a catastrophe treaty on the same loss. An event definition and hours clause determining whether two claims aggregate. A claim reopening after a treaty year has been closed. These are the ones nobody has tested, because they have not happened yet, and they are the ones that matter.

Problem one: a treaty is a contract, and contracts do not fit a fixed schema

Quota share cedes a fixed proportion. Surplus cedes by lines above a retention, which means the ceding percentage varies per risk with the sum insured. Per risk excess responds above an attachment point per risk. Catastrophe excess responds above an attachment per event, with a defined event, an hours clause, and a limited number of reinstatements, each carrying its own premium calculated pro rata to time and amount or on some other basis your slip specifies. Facultative sits on individual risks. Then inuring reinsurance determines the order in which these apply to the same loss, and getting that order wrong changes the recoverable materially.

Sapiens ReinsurancePro is the established cession engine in North America and it handles standard structures and statutory output well, which is the reason it is widely used. Effisoft WebXL plays a similar role internationally. Where both get uncomfortable is bespoke wordings, unusual commission bases and, most of all, restatement of prior treaty years when data changes underneath a closed period. DXC Xuber carries long London market heritage and broad functionality, and prospective buyers rightly ask about platform direction before committing to a multi year programme. Verisk supplies catastrophe modelling and industry data, which informs how you buy your programme rather than administering what you bought.

What a custom build does: model the treaty as a structure of typed layers with parameters drawn from the slip, then implement the cession as a calculation engine over that structure rather than as code per treaty. The test is simple. When your broker places next year's programme with a different attachment and an extra layer, is that a configuration change made by your reinsurance accountant in an afternoon, or a development ticket? If it is a ticket, the design is wrong.

Problem two: cessions must be reproducible years later, under changed data

Reinsurance accounting is unusual in that the past keeps moving. A claim reserve is revised. A policy is endorsed with retroactive effect. A subrogation recovery arrives four years after the loss. Each of those changes the cession for a treaty year you already reported on.

What a custom build does: calculate cessions as an event stream rather than a stored figure. Every cession posting references the policy or claim transaction that caused it, the treaty version and the parameter set in force. When a claim reserve changes, the system generates an adjusting cession rather than overwriting the original, so the ceded ledger reconciles to the gross ledger at every point in time and you can produce the position as at any prior date. This is what makes an audit calm and what makes a quarterly close possible without a reconciliation exercise. It is also the requirement that spreadsheets fundamentally cannot meet, because a spreadsheet recalculates and the old answer is simply gone.

Problem three: reinstatements and commissions are where the money is and the errors live

Reinstatement premium is due when a catastrophe layer is eroded, typically calculated pro rata as to amount and, depending on the wording, pro rata as to time. Get the calculation wrong on a large event and the error is six figures on a single layer. Profit commission depends on a defined result over a defined period, with expense loadings and loss carry forward provisions that differ per treaty and that regularly do not match what the reinsurer's own statement says. Sliding scale ceding commission adjusts with the loss ratio at defined points, which means the commission is provisional until the loss ratio settles, which it does slowly.

What a custom build does: express each of these as parameterised calculations attached to the treaty version, run them on a schedule, and produce a statement in the format the reinsurer expects with the workings attached. Then reconcile automatically against the reinsurer's or broker's statement and surface differences at line level. Reconciliation is the part carriers most often leave manual and it is where the recoverable balance quietly diverges from what the counterparty believes it owes.

Problem four: recoverables and collateral are a credit exposure nobody owns

Ceded reserves are an asset on your balance sheet only to the extent the reinsurer pays. Statutory reporting requires you to report reinsurance recoverables by counterparty, with collateral considered, and unauthorised reinsurers require security in the form of letters of credit, funds withheld or trust arrangements. The aging of a recoverable is credit risk, and in many carriers it is tracked by a person who chases balances by email.

What a custom build does: maintain the recoverable balance per counterparty per treaty year as a ledger, age it, hold collateral instruments with expiry dates against the exposure they secure, and alert when a letter of credit approaches expiry with an uncovered balance behind it. Produce the counterparty schedules statutory reporting requires directly from that ledger rather than assembling them each quarter. Where a carrier has been through a reinsurer downgrade or dispute, this module usually pays for itself once.

What a treaty system must include

• Typed treaty structures with layers, retentions, limits, aggregates, event definitions and hours clauses drawn from the slip, versioned per treaty year
• An inuring order that is explicit configuration rather than an assumption baked into calculation code
• Event driven cession postings that reference the originating policy or claim transaction and never overwrite history
• Reinstatement, profit commission and sliding scale calculations as parameters, with workings retained for every run
• Automated reconciliation against reinsurer and broker statements at line level
• Recoverable ledger by counterparty and treaty year, with collateral instruments, expiries and aging
• Ceded IBNR allocation consistent with the actuarial method your team actually uses
• As at date reporting, so any prior period position can be reproduced exactly

What it costs and how long it takes

A first release, meaning treaty structure modelling, automated premium and loss cession for proportional treaties, and a ceded ledger reconciling to gross, runs $110,000 to $240,000 and ships in 14 to 20 weeks. A full platform adding excess of loss with reinstatements, facultative, commission calculations, statement reconciliation, recoverable and collateral tracking and statutory schedule production runs $300,000 to $700,000 across 9 to 18 months.

What pushes cost up in this category: the number of distinct treaty types and how bespoke the wordings are, since a slip with a negotiated aggregate feature is a modelling exercise, not a field. Historical treaty years, because loading and reproducing prior years is a data project with its own timeline and you should decide deliberately how far back you go. Multiple legal entities with inter company reinsurance, which adds elimination logic. Assumed business, if you also accept cessions, since the mirror image doubles the model. And the quality of your gross data, which is the real constraint: cession accuracy is bounded by whether your policy and claim records carry the attributes your treaties key on, and in many carriers they do not.

Build versus buy for treaty management

Buy a package if your structures are conventional, your volume is moderate and your priority is statutory output with a vendor name your auditors recognise. ReinsurancePro and WebXL are reasonable choices in that situation and the implementation is predictable.

Do neither, for now, if you run two simple quota shares and a broker prepares your bordereaux. Spend the money on gross data quality, because that is what constrains every future option you have.

Build when two or more of these are true. Your programme includes structures your package handles by manual adjustment, which is a polite way of saying the spreadsheet is still in use after implementation. You need to restate prior treaty years cleanly and currently cannot. Your recoverable and collateral position is tracked outside any system. You write assumed as well as ceded business. Or the calculation knowledge sits with one or two people and the operational risk of that has been raised in a board paper, which is where these projects usually originate.

How to choose a developer for reinsurance work

Ask them to explain how a single large loss flows through a per risk excess treaty and a catastrophe treaty where one inures to the benefit of the other. If they need to look it up, that is fine and honest. If they do not know the question matters, they will build you something confidently wrong.

Ask how they handle a claim reserve revision in a closed treaty year. The answer must be an adjusting posting that preserves the original, never a recalculation that replaces it. This single design decision separates a system your auditors trust from one they will not.

Ask how a new treaty year with different attachments and an added layer gets configured. If the answer involves a development cycle, you have bought a bespoke spreadsheet with a login page.

Ask who owns the code, the treaty configurations and the cession history, and put it in the contract before kickoff. Your cession history is a statutory record and your treaty configurations encode contracts you are bound by. At Digital Heroes the client owns all of it from the first commit, and any arrangement where your ceded ledger lives somewhere you cannot fully extract from should be refused.