A windstorm produces four thousand claims across three days. How does your system decide that is one event for reinsurance purposes, and what turns on the answer?

Per-risk cover and per-event cover ask different questions

Most reinsurance a system handles day to day responds to a single policy: a proportional treaty cedes a share of each risk, and a per-risk excess layer responds when one claim is large. Catastrophe cover is different in kind. It responds to an occurrence, meaning the aggregate of many claims across many policies arising from one thing happening, and it is bought precisely because a windstorm is not a large claim but a great many ordinary ones at once.

That changes what the system has to be able to compute. For per-risk cover the unit of account is a claim, and every claim can be assessed independently as it develops. For catastrophe cover the unit of account is a set of claims whose membership is not known when any of them is notified, whose boundary is defined contractually rather than physically, and which continues to grow for months. A recovery cannot be calculated claim by claim, because the retention applies once to the whole group.

The treaty defines the occurrence, and it does so by clock

The contract does not say "one storm". It defines a loss occurrence, and for weather perils it typically does so by stating that all individual losses arising from the same peril within a stated number of consecutive hours constitute one occurrence. The number of hours differs by peril, because a windstorm and a period of freezing weather have very different natural durations, and it is written into the treaty rather than derived from meteorology.

Two consequences follow, and both are the substance of the question. The first is that the field the whole calculation rests on is the date and time of loss, not the date of notification. A claim notified in November for damage sustained in September belongs to the September occurrence, and if the aggregation is driven off notification dates it will produce an answer that is wrong in a direction nobody can audit. The second is that with claims spread over three days, more than one placement of the window is available, and the cedant is normally the party entitled to choose where it begins.

Choosing the window is an optimisation, and not always in the obvious direction

The instinct is that one big occurrence is better than two small ones, because a single retention is deducted rather than two. That is usually right, and it is not always right.

Work the arithmetic on stated assumptions rather than asserting a conclusion. Suppose the retention is ten million and the first layer covers twenty million above it. Aggregate everything into a single occurrence of thirty-eight million and you retain ten, recover twenty, and are uncovered for the eight above the layer unless a second layer is in place. Split the same losses into two occurrences of nineteen million each and you retain twenty in total, recover nine from each, and recover eighteen. One occurrence is better here. Change the numbers so each half is comfortably inside the layer and the totals are close to the retention, and the comparison inverts. The decision depends on where the losses sit relative to the retention and the top of each layer, which is why it has to be computed rather than reasoned about by rule of thumb.

Two further terms make it harder. Layers usually permit only a limited number of reinstatements, and reinstating a layer after it has been used costs a reinstatement premium, so using up a layer twice in one storm carries a price that has to be netted against the extra recovery. And an annual aggregate deductible, where one exists, changes which occurrence is worth maximising: the first occurrence of the year may be absorbing a deductible that a later one would not.

flowchart TD
    A[Claims with loss date and time] --> B[Peril and geography assigned]
    B --> C[Candidate hour windows enumerated]
    C --> D[Occurrence grouping selected]
    D --> E[Retention applied once per occurrence]
    E --> F[Layers filled and reinstatements consumed]
    F --> G[Cession posted per policy and layer]

The step to watch is the third, because the candidate windows have to be enumerated from real timestamps before anybody can choose between them, and no system that stores only a loss date to the day can enumerate them at all.

What the claims system has to carry for this to be possible

Every claim needs a date and time of loss, a peril code that maps to the peril definitions used in the treaties, and enough geography to test whether it falls inside the territorial scope of the cover. Those three fields are captured at first notification, under pressure, by a handler whose priority is the customer, and they are consequently the least reliable fields in the record. That is a design problem rather than a training problem: the event assignment has to be revisable, and revising it has to be an ordinary, audited operation rather than a data fix.

An event identifier is the usual mechanism, attached to claims and revisable in bulk as the picture clarifies. Industry bodies in several markets publish catastrophe identifiers that participants can align to, which is worth adopting where it exists because it makes your view comparable with the reinsurer's. But your own identifier still has to exist, because the grouping you claim under the treaty is your assertion and has to be reproducible as it stood on the date you asserted it.

The regrouping problem is the part that hurts

A catastrophe develops for a year or more. Claims are notified late, reserves move, some claims turn out to belong to a different peril, and the aggregate crosses the retention weeks after the storm rather than during it. Every one of those changes can alter the optimal grouping, and by then you have already reported cessions, submitted bordereaux, taken credit for recoverables in your accounts and closed a reporting period.

So the cession has to be a restatable derivation rather than a stored figure with no provenance. That means the underlying claim payments and reserve movements stay immutable and sliceable by policy, treaty, layer, accident date and underwriting year, and the event grouping is a separate, versioned assignment on top of them. Recompute the recovery from the transactions under the new grouping, post the difference as a dated adjustment, and keep the prior version so that the bordereau you sent in March can still be reproduced exactly. The alternative, editing the recovery figure in place, leaves you unable to explain to a reinsurer why the number they were shown last quarter differs from the one in front of them, which is precisely the conversation in which you need to be able to explain it.

Where the strong answer separates from the adequate one

An adequate answer describes the hours clause and stops. A strong one says who decides, and treats that as the design requirement: the aggregation is a commercial election made by the cedant under a contractual definition, and it has to be made repeatedly on incomplete data with real money attached. What the system therefore owes the reinsurance team is not a single computed recovery but the ability to evaluate alternative groupings against the current claim population, see the retention, layer consumption and reinstatement cost of each, and record which one was elected and why. A recovery engine that hard-codes one grouping rule has quietly taken a decision that belongs to a person, and taken it before the information needed to make it existed.

The occurrence is a contractual object rather than a meteorological one, and the money turns on where the window is placed. That makes the loss timestamp the most financially significant field in a catastrophe claim, and the grouping a versioned decision rather than a derived fact.