The trial 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 trial-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 trial?

A trial 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 trial 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 trial captures the full set of loss-producing events — including the possibility of none.

Where do trials come from? Catastrophe models — maintained by vendors like Moody’s RMS, Verisk, and CoreLogic — generate trials 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 trials, each containing zero or more loss-producing events. We identify a trial by its trial_id. A trial contains one or more occurrences — instances of catalog events that produce losses.

Trials are equiprobable and independent. In a simulation with $N$ trials, each represents a $1/N$ probability of occurring. They are independent of each other — the outcome of one trial 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+ trials. The Helios Re dataset is fictitious data designed to mimic the structure and characteristics of real vendor model output, sampled down to 20 trials for hand-computability. All examples on this site work identically at full scale — the only difference is the resolution of the resulting distribution. With 20 trials, the finest probability increment is 5%. With 100,000 trials, it is 0.001%.

Some models also produce weighted trials 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 trials 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 trial — one catalog event producing a loss in one simulated future. Each occurrence is identified by the composite key (trial_id, timestamp, event_id). A trial 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 trial

This is the same occurrence-vs-aggregate distinction from the Products and Contracts section. The Financial Modelling chapter formalizes the difference as two distinct terms — occurrence excess and aggregate excess — that differ in what they group by before applying the attachment and limit.

Terminology

The industry uses “event” for both the catalog entry and the loss instance in a trial. 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 trial). When you see “OEP” (Occurrence Exceedance Probability), the “O” refers to occurrences, not events.

The TELT

The Trial Event Loss Table (TELT) is the canonical data structure for trial-based loss data.

Column	Type	Description
trial_id	integer	Which simulated future
timestamp	date	When the occurrence happens within the trial
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
cedent_id	string	Which cedent’s book the loss belongs to
loss	float	Subject loss amount
tiv	float	Total insured value of the exposed risk

The primary key of the TELT is (trial_id, event_id, cedent_id, geography_id, lob_id). A single occurrence — identified by (trial_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 TELT for convenience: it makes filtering and analysis by peril straightforward without requiring a join back to the event catalog.

TIV and the damage ratio

The last column, tiv, records the total insured value (TIV) — the sum of insured values of the exposure this occurrence touched, at the row’s geography and LOB resolution. Where loss says how much damage the event caused, tiv says how much insured value stood in its path.

TIV gives losses a denominator. The damage ratio of a set of TELT rows $S$ is the modelled loss per unit of exposed insured value:

$$\text{DR}(S) = \frac{\sum_{r \in S} \text{loss}_r}{\sum_{r \in S} \text{tiv}_r}$$

In English: add up the losses, add up the exposed TIV, divide. In code, it is one line per slice — df.groupby(dim).apply(lambda g: g['loss'].sum() / g['tiv'].sum()). A damage ratio of 12% means the events that struck this slice destroyed, on average, 12% of the insured value they touched — weighted toward the larger exposures. For a single occurrence — the largest in the SunCoast TELT, a $174.1M Texas hurricane loss against $700.9M of exposed TIV — the damage ratio is 24.8%: a quarter of the insured value in the storm’s path was lost.

Exposed TIV is not book TIV

The TELT carries only the insured value that modelled events touched. It does not contain the cedent’s full exposure schedule — that lives upstream, inside the catastrophe modelling process. You can compute “how severely do events damage what they hit” from a TELT; you cannot compute “what fraction of the cedent’s total book is at risk” without the exposure data itself. Keep the two denominators apart.

Good to Know

The timestamp column captures when an occurrence happens within a trial. 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 TELTs exist — and why simpler data structures that discard it cannot fully support aggregate analysis.

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

Sign convention

The loss column stores losses as positive numbers: a $46.9M loss is recorded as 46.9, and both loss and tiv are strictly greater than zero in a valid base TELT — model output entering the pipeline. (Transformed TELTs — the outputs of contract terms — may legitimately contain zero losses, but never negative ones.) This is the site’s sign convention, and it deserves a moment of attention before any metric is computed on this data — because the industry has two conventions, and they disagree.

Accounting and finance systems often represent losses as negative values. A loss is money flowing out, a premium is money flowing in, and the net position is a plain sum — no special-case arithmetic. Catastrophe model vendors and loss analytics platforms overwhelmingly do the opposite: a loss is a positive magnitude, because risk analytics asks “how big?” far more often than “which direction?”.

The choice looks cosmetic. It is not. It silently determines the orientation of every computation downstream:

Consequence	Loss-positive (this site)	Loss-negative
The “worst” trial	Largest value	Smallest (most negative) value
EP-curve sort order	Descending	Ascending
The tail	Top of the sorted table	Bottom of the sorted table
1-in-100 loss	99th percentile	1st percentile
Net of premium	Explicit subtraction: $\text{premium} - \text{loss}$	Plain sum: $\text{premium} + \text{loss}$

We use loss-positive throughout, for two reasons. First, it matches how the domain speaks and how the data arrives: “a $100M loss” and “the 1-in-20 loss is $616.2M” state positive magnitudes, and vendor catastrophe model output ships losses as positive values. Second, it keeps the tail machinery in the next two sections — distribution semantics and metrics — direct rather than mirrored: sort descending, the worst trials sit at the top, rank $r$ maps to exceedance probability $r/N$ with no negation anywhere.

The price is that losses and premiums no longer net by simple addition — combining them requires explicit subtraction. We consider that a feature. When financial record types beyond loss enter the schema (premiums, reinstatement premiums, expenses), each should be an explicit record type with explicit aggregation semantics — not a sign trick. Accordingly, a negative loss in a TELT is a validation error: not a recovery, not a premium, not a correction. Validate it at every ingestion boundary — one line buys a lot of safety:

assert (telt['loss'] > 0).all(), "negative loss: sign-convention violation"

Mixed sign conventions fail silently

When loss-negative data is fed into a loss-positive pipeline (or vice versa) without conversion, nothing crashes. Sorts run, quantiles compute, reports render — but the tail now selects the best trials instead of the worst, “worst-case” metrics come out implausibly small, and a contract that attaches at $50M never triggers because every loss sits below $50M. If sources with opposite conventions are merged, losses partially cancel in aggregation. Sign-convention mismatches are among the most common integration bugs when combining data from multiple vendors or internal systems — check the convention of every new data source, and convert at ingest, never downstream.

If your organization uses the loss-negative convention, everything on this site still applies — the metrics section shows exactly what to flip.

The Helios Re TELT

Each of Helios Re’s cedents has its own TELT with 20 trials. The number of occurrences varies by cedent and trial — some trials contain a single event, while others contain a dozen. Here is SunCoast Insurance’s TELT, the one we will use most throughout this chapter.

helios_re/show_telt.py Python

▶ Run Reset

Event Loss Tables

Another common data structure produced by vendor catastrophe models is the Event Loss Table (ELT). Understanding what it is, where it comes from, and why TELTs supersede it 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 TELTs come in. A TELT groups events into trials, preserving which events co-occur and in what order.

From ELT to TELT: Converting an ELT to a TELT means running a Monte Carlo simulation. For each trial, 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 TELT directly; others provide the ELT and expect the user (or their platform) to perform the simulation step.

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

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

Watch Out!

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

The temporal dimension is particularly important. A TELT preserves the order in which losses arrive within a trial. 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 trials.

From trials to distributions

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

For equiprobable trials, each trial contributes equal probability mass. With the Helios Re TELT — 20 trials — each trial 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.