The scenario worldview

Everything in reinsurance analytics begins with a question: what could happen? Not what will happen — catastrophes are too rare and too variable for prediction — but what is the full range of plausible outcomes?

The answer comes from scenario-based simulation: generate thousands of possible futures of catastrophe activity, compute the losses for each, and use the resulting distribution to make decisions.

What is a scenario?

A scenario is one complete picture of what might happen — a possible future of catastrophe activity. “In this future, a Category 4 hurricane hits Miami in August, and a magnitude 7.2 earthquake strikes Tokyo in March. Nothing else.” Another scenario might have no hurricane season at all, but a devastating earthquake in California.

Most models simulate one year at a time, though some produce multi-year forecasts (e.g. for long-term capital planning or climate-adjusted views). Either way, each scenario captures the full set of loss-producing events — including the possibility of none.

Where do scenarios come from? Catastrophe models — maintained by vendors like Moody’s RMS, Verisk, and CoreLogic — generate scenarios through Monte Carlo simulation. Each model maintains an event catalog: a database of tens of thousands of physically plausible catastrophes (specific hurricane tracks, earthquake ruptures, windstorm paths), each with an estimated annual frequency and a deterministic loss for a given exposure. The simulation engine samples from these catalogs — respecting physical constraints (no North Atlantic hurricanes in January) and frequency distributions (how often does a Category 4 hit South Florida?) — to produce thousands of synthetic futures.

The output is a set of scenarios, each containing zero or more loss-producing events. We identify a scenario by its scenario_id. A scenario contains one or more occurrences — instances of catalog events that produce losses.

Scenarios are equiprobable and independent. In a simulation with $N$ scenarios, each represents a $1/N$ probability of occurring. They are independent of each other — the outcome of one scenario tells you nothing about another.

Key Insight

The equiprobable assumption is powerful: it means every statistical operation reduces to simple arithmetic on arrays. The mean is a sum divided by $N$. A quantile is a lookup after sorting. No probability density functions, no integrals — just counting and averaging.

In Practice

Production catastrophe models generate 10,000 to 1,000,000+ scenarios. The Helios Re dataset uses 20 for hand-computability. The concepts scale directly — the only difference is the resolution of the resulting distribution. With 20 scenarios, the finest probability increment is 5%. With 100,000 scenarios, it is 0.001%.

Some models also produce weighted scenarios with unequal probabilities. In that case, the simple arithmetic (divide by $N$, sort and index) must be replaced with probability-weighted versions: weighted averages for EL, weighted quantiles for VaR. The concepts remain the same; only the implementation changes. The Helios Re dataset uses equiprobable scenarios throughout.

Events and occurrences

Two terms that the industry uses loosely but that are worth keeping apart:

An event is a specific physical catastrophe in a model’s event catalog — a particular hurricane track, earthquake rupture, or windstorm path. Events have catalog IDs, annual frequencies (rates), and physical metadata (wind speed, magnitude, geographic footprint).

An occurrence is a loss instance within a scenario — one catalog event producing a loss in one simulated future. Each occurrence is identified by the composite key (scenario_id, timestamp, event_id). A scenario may contain zero, one, or many occurrences.

The distinction matters because different contract types operate at different levels:

• Occurrence contracts (CatXoL) evaluate each occurrence independently
• Aggregate contracts (AggXoL) accumulate losses across all occurrences in a scenario

This is the same occurrence-vs-aggregate distinction from the Products and Contracts section. We’ll formalize the difference in computational terms — specifically, what you group by before applying contract terms — in the Engineering chapter.

Terminology

The industry uses “event” for both the catalog entry and the loss instance in a scenario. This site keeps them separate because conflating them causes real confusion when discussing contracts that operate at different aggregation levels. Event = catalog concept (a physical catastrophe with a rate). Occurrence = loss instance (a specific event appearing in a specific scenario). When you see “OEP” (Occurrence Exceedance Probability), the “O” refers to occurrences, not events.

The SELT

The Scenario Event Loss Table (SELT) is the canonical data structure for scenario-based loss data.

Column	Type	Description
scenario_id	integer	Which simulated future
timestamp	date	When the occurrence happens within the scenario
event_id	integer	Which catalog event produced this loss
peril	string	Peril type (HU, EQ, WS)
geography_id	string	Geographic region of the loss
lob_id	string	Line of business
loss	float	Subject loss amount

The primary key of the SELT is (scenario_id, event_id, geography_id, lob_id). A single occurrence — identified by (scenario_id, timestamp, event_id) — can produce multiple rows if it affects more than one geography or line of business. A major hurricane might generate separate loss records for Florida and Texas, or for property and casualty lines.

The geography_id and lob_id columns define the resolution of the loss data. They determine how finely losses are broken down, and they matter because different contracts may cover different geographies or lines of business. A contract covering only Florida property would filter to geography_id = 'FL' and lob_id = 'Property' before applying its terms.

Note

peril is technically a property of the event, not of the individual loss record — a hurricane is a hurricane regardless of where it causes damage. We include it in the SELT for convenience: it makes filtering and analysis by peril straightforward without requiring a join back to the event catalog.

Good to Know

The timestamp column captures when an occurrence happens within a scenario. This matters more than it might seem. For aggregate contracts that erode coverage over a period, the order in which losses arrive determines how much coverage remains for later events. A major hurricane in August leaves less aggregate limit for a windstorm in December. This temporal sequencing is one of the main reasons SELTs exist — and why simpler data structures that discard it cannot fully support aggregate analysis.

The SELT is both the input to and the output from every financial computation. Contract terms consume a SELT and produce a new SELT with transformed loss values. This symmetry — SELT in, SELT out — is a core design principle that enables composability, as we will see in the Engineering chapter.

The Helios Re SELT

Helios Re uses a simplified SELT with 20 scenarios and 2 occurrences per scenario. Here it is in full — you will see these numbers throughout the chapter.

helios_re/selt.py

▶ Run Reset

Event Loss Tables

Before SELTs, there were Event Loss Tables (ELTs). Understanding what they are, where they come from, and why SELTs supersede them for most analytics is worth the detour.

An ELT is the most common output format from catastrophe model vendors. Each row represents a single event from the model’s catalog, paired with a loss estimate and an annual frequency:

Column	Type	Description
event_id	integer	Catalog event identifier
rate	float	Annual frequency of occurrence
loss	float	Expected loss if the event occurs

A model’s event catalog might contain 50,000+ physically plausible hurricanes, earthquakes, and windstorms, each with its own rate. A rate of 0.002 means this event occurs on average 0.002 times per year — equivalently, once every 500 years. Note that rate is a frequency, not a probability: a rate of 2.0 means two expected occurrences per year, while the probability of at least one occurrence is $1 - e^{-\lambda} \approx 0.865$. For rare events (rate ≪ 1), the distinction is negligible; for frequent perils, it matters.

What you can do with an ELT:

• Compute expected annual loss directly: $\sum_i \text{rate}_i \times \text{loss}_i$
• Evaluate per-occurrence contracts (like CatXoL) on individual events
• Build occurrence exceedance probability (OEP) curves by treating events independently
• Assess contracts quickly — an ELT is compact and fast to process

What you cannot do with an ELT:

• Analyze aggregate contracts — there is no concept of which events happen together in a given year
• Capture temporal sequencing — events have no timestamps, so you cannot model how losses erode coverage over time
• Preserve co-occurrence patterns — a hurricane season with three landfalls looks the same as three independent hurricanes

This is where SELTs come in. A SELT groups events into scenarios, preserving which events co-occur and in what order.

From ELT to SELT: Converting an ELT to a SELT means running a Monte Carlo simulation. For each scenario, sample events from the catalog according to their rates, assign timestamps based on each peril’s seasonality distribution, and record which events occurred together. Some vendors expose the SELT directly; others provide the ELT and expect the user (or their platform) to perform the simulation step.

The reverse — collapsing a SELT back to an ELT — is simple but destructive. You aggregate across scenarios and discard the grouping. Information is lost.

Property	SELT	ELT
Temporal sequencing	Preserved (timestamps within scenarios)	Absent
Co-occurrence	Preserved (events grouped into scenarios)	Lost (events are independent)
Aggregate analysis	Natural (sum within scenario, respecting order)	Requires simulation
Data size	Larger ($N$ scenarios × occurrences)	Smaller (unique events × rate)
Primary use case	Full financial modelling	Quick screening, single-event analysis

Watch Out!

ELTs and SELTs are not interchangeable. Converting an ELT to a SELT adds information (which events co-occur, in what order). Collapsing a SELT to an ELT destroys it.

The temporal dimension is particularly important. A SELT preserves the order in which losses arrive within a scenario. For multi-peril aggregate coverage, this sequencing determines how coverage erodes and whether late-year events breach a reinstatement or exhaust the aggregate limit. An ELT has no concept of “earlier” or “later” — and without it, aggregate analysis is impossible without first simulating scenarios.

From scenarios to distributions

With a SELT, you have everything needed to build an empirical probability distribution over any quantity you can compute from losses. Sum all occurrence losses within each scenario, and you have a distribution of annual aggregate loss. Take the maximum occurrence loss per scenario, and you have a distribution of peak single-event loss.

For equiprobable scenarios, each scenario contributes equal probability mass. With the Helios Re SELT — 20 scenarios — each scenario represents a 5% probability.

The next section shows how to construct and read exceedance probability (EP) curves from this data — the most important chart in reinsurance analytics.