A warehouse fire on a Thursday night. On Friday the claims adjuster sets a reserve of $3.2 million. Nobody on the claims side thinks about reinsurance, and they should not have to. But the per-risk treaty has a reporting clause, the reinsurers’ claims teams like to set their own reserves before the broker’s weekly call, and the one thing a lead underwriter raises at renewal is the loss they read about in the trade press first.
On most ceded desks large-loss notification is a report someone runs on Monday, filtered on a number, and an email typed from it. It works until the week the report is not run. This post is about the agent that prepares the notice instead, what it will and will not put in it, and where a person stays in the loop.
When a claim counts as large
The agent runs on every claim event, after the engine has committed what the event ceded. It treats a claim as large in any of three cases:
- InsightCW sent a
claim.large_lossevent. The intake records it, marks the claim as large on the claim register, notes the contracts in force that would respond, and leaves the notice to the agent. - The claim register already carries the large-loss flag.
- The claim’s gross incurred is at or above the carrier’s large-loss threshold, $1,000,000 unless configured otherwise.
If CW’s large-loss event has already been noticed and the claim has still reached no layer, there is nothing new to say and the agent stops. Otherwise it gathers the facts.
Who it tells, and with what
The notice goes to the panel of every contract and layer the claim’s cessions touched: for each, the reinsurers on the layer (or the treaty, where the panel is not split by layer), their signed share, and the claims contact on the reinsurer record. The notice carries what the ledger knows — the claim number, insured, policy, line, loss date, cat code if any, gross incurred and paid, and for each contract and layer the amount ceded so far, paid and outstanding, and any part the layer could not take.
Every figure comes from a committed row and every address from the reinsurer record. That is the agent’s whole contract, written in its definition: it never invents “a recipient or a figure: no contact on file means a draft with no addressee, never a guessed one.”
flowchart LR
A["Claim event
engine has committed"] --> B{"Large?
event, flag
or over threshold"}
B -- no --> X["Nothing prepared"]
B -- yes --> C["Contracts and layers
the claim touched"]
C --> D["Their panel
share and contact"]
D --> E{"Contact
on file?"}
E -- some --> F["Held message to those
the rest named, not guessed"]
E -- none --> G["Draft with no addressee
nothing held"]
F --> H["Queue at L2
accept releases
reject cancels"]
G --> H
Held, then released
The draft is written into the outbox as held. The outbox worker only picks up pending rows, so a held message cannot leave from any server; the only way out is a person’s accept, or, if a carrier ever moves this checkpoint to L3, the close of a one-hour pull-back window. A reject cancels it. Outside production every release goes to a dry-run provider that records it and sends nothing.
The checkpoint, notice_send, starts at L2 — Ask first — and the
tenant ceiling keeps it there until the carrier raises it. A notice to the panel is the kind of
message where one wrong addressee costs more than a day’s delay, which is why the product
starts here and moves only on evidence.
What the analyst opens is a decision record, not an email. Its title names the claim and the gross incurred, which is also the money the queue sorts it by. Under the explanation the evidence is grouped by where it came from: the claim, from the claim register, linked to the claim’s recoverables; one line per contract and layer reached, from the loss cessions, with paid and outstanding; and one line per panel member, from the participations and the reinsurer record, with the share and the contact or the words no contact on file. The draft sits below that, exactly as it would be sent.
The use case, in one table
| A large loss, noticed to the panel | |
|---|---|
| Trigger | Any claim event after the engine commits; the claim is large by a claim.large_loss event, the register’s flag, or gross incurred at or above the threshold |
| Actor(s) | The ceded reinsurance analyst |
| Agent | Large loss notice agent |
| Grounded in | The claim register; the loss cessions on the claim (layers reached, paid, outstanding, uncovered); the participations; contact_email on each reinsurer |
| Prepares | A notice to the panel with the claim facts and the contracts touched, held in the outbox; the reinsurers without a contact listed by name |
| Checkpoint & default level | notice_send · L2 Ask first |
| What a person decides | Whether the notice goes; how to reach any panel member with no contact on file |
| What is recorded | The decision record (evidence per claim, layer and panel member, with the table each came from); the outbox row held, released or cancelled; the answer as feedback |
No contact, no addressee
The rule is easier to state than to keep. A drafting model asked to write to “the panel”
will produce something that looks like an address, and a desk under pressure will send it. So the
recipients are never the model’s: they are the contact_email on each reinsurer
record, and when that is empty the reinsurer stays in the evidence and in the proposal as a name
with no contact on file. When nobody on the panel has a contact, nothing is held at all;
the draft lives on the decision record, and the explanation says the notice has no addressee until
one is added.
On the demo ledger, as it happens, none of the five reinsurers on the cat panel has a contact on file. Every message the agents have drafted there — the statements and the chasers in the queue — carries an empty recipient list, and the screen says so.
Why the notice is per event
The agent runs once per claim event and never twice for the same one. That is what makes it safe to replay an event or resend a batch. It also means a large claim that keeps moving keeps producing drafts, one per movement once it has reached a layer; a draft still unanswered is replaced by the newer one rather than piled beside it. The desk decides which of those the panel needs; the record of each answer is what will, in time, tell the dial whether the agent’s idea of “worth telling” matches the desk’s.
What it does not do
- It does not read the treaty’s reporting clause. “Large” is one threshold per carrier, or InsightCW’s flag, until treaty wordings are stored. A treaty whose clause says $500,000 needs the threshold set to match, or CW’s event.
- It does not find the panel before a layer is reached. The panel comes from the contracts the claim’s cessions touched. A precautionary notice on a claim that has not yet reached any layer is drafted with no addressee; the person adds the recipients, or sends it from their own mailbox.
- It does not suppress small updates. Every movement on a claim that has reached a layer prepares a fresh notice. An unanswered draft is replaced by the newer one, but once a notice has been answered, the next movement — however small — brings another to accept or reject.
- A Change does not rewrite the held message. Changing the recipients or wording is recorded on the decision and as feedback, but the message released on accept is the one the agent drafted. To send something different, reject and send your own.
- It does not track the reply. Whether the reinsurer acknowledged the notice is not recorded by the product today.
If your large-loss notices go out when someone remembers to run the report, talk to us about the claims you would have wanted noticed last year.