Setting an ILS parametric trigger

A parametric trigger is a physical threshold that determines whether a payout occurs: sustained winds above some speed inside a defined box, a magnitude above some value near a defined point, a river gauge above some stage. The threshold is objective, which is what makes the instrument work — and it is also what makes it monitorable, which is what this feature does.

Creating a trigger

Go to Triggers and create one. A trigger needs four things:

A peril. Earthquake, hurricane, wildfire, or flood. This determines which live feed the trigger is evaluated against and which measurement types are offered.

A geography. Either a point with a radius, or a polygon for territory-based structures. Point-and-radius is the right choice for a trigger written around a specific facility or city. A polygon is the right choice when the bond documentation defines a box or a set of counties — match the geography to the documentation, not to your intuition about where losses will fall.

A measurement and threshold. The physical quantity the trigger is written on — wind speed in knots, a hurricane’s central pressure in millibars, magnitude, a river gauge’s height above its flood stage in feet (not the gauge’s own stage: a 2 ft trigger fires when the river is 2 ft over flood stage, whatever that gauge’s flood stage is), storm surge in feet, or the percentage of a fire not yet contained — and the value at which it fires. Central pressure is the one that fires at or below its value, because a lower pressure is a stronger storm, and it asks whether the storm’s center is inside your area rather than whether its winds reach a point. Industry-loss thresholds are not offered: Calchis carries no industry loss index (PCS or PERILS), so it has nothing to measure one against. Enter the threshold exactly as the documentation states it. The platform does not round or reinterpret.

The decision a breach forces. Optional, and the reason the trigger exists: “convene the committee and decide whether to hedge before the next advisory”. It is sent with the breach webhook and email as Decide: …, so the person paged at 3am reads what the position needs decided, not only what was measured.

A warning level. The percentage of threshold at which you want to be told. This is the difference between finding out that a position is in play while there is still time to act, and finding out afterwards. Set it deliberately, per position: a trigger you can act on at short notice can sit closer to the threshold than one that needs a day of internal process.

How evaluation works

Triggers are evaluated every five minutes against the latest data ingested from the federal sources — USGS for seismic events, the National Hurricane Center for tropical cyclones, and the stage stated in National Weather Service flood warnings for flood. Each source updates on its own schedule (the hurricane feed every 30 minutes, for example), so a reading is only as current as its source’s last update.

Magnitude is compared on energy, not as a plain ratio. The magnitude scale is logarithmic, so an M5.6 is not 80% of an M7.0 — it released about 1% of the energy. For magnitude triggers the percentage is the reading’s seismic moment as a share of the threshold’s, which puts the default 80% warning level at about M6.94 for an M7.0 trigger. Each reading also records the magnitude type USGS reported, and says so when it is not moment magnitude (Mw), the scale parametric earthquake terms are usually written on.

The full method, including where each reading is taken and what happens when an agency revises a figure, is on How Calchis determines a trigger.

When a trigger becomes approaching or breached, its owner is emailed at once, unless Trigger Alerts by Email is switched off at alert settings — a switch of its own, separate from area alerts, so turning those off does not silence a breach. The unsubscribe link in a trigger email stops trigger emails only. Any webhook or email integration you set up is notified too. When an event enters a trigger's geography, the platform begins tracking the measured value against the threshold and records the percentage reached.

A trigger moves through four states, and the dashboard colors each one:

• Monitoring — an event is in the geography but well below threshold
• Approaching — the measured value has crossed your warning level
• Breached — the threshold has been met or exceeded
• Resolved — the event has ended without further movement

State changes are what generate alerts. A trigger sitting in Monitoring for three days does not page you.

The audit trail

Every evaluation is written to a permanent record: the measured value, the threshold, the percentage, the source of the measurement, and the timestamp. This is not incidental logging — it is the artifact your compliance team will ask for.

The value of the record is that it shows the state of knowledge at each point in time, from the authoritative source, rather than a reconstruction after the fact. When a counterparty asks what was known and when, the evaluation history is the record you can point to. It does not settle the bond: the calculation agent’s determination does.

Trigger history is available per trigger in the interface and through the API for programmatic export.

Alerts

Where alerts go depends on your plan — see pricing for what each tier includes. Webhook delivery is the option to use if you want trigger state changes to land in your own systems rather than an inbox; payloads are signed so the receiver can verify them.

Set the alerting path up before hurricane season, not during it. The first time a webhook endpoint is exercised should not be the night a position is in play.

A note on what this is not

Trigger monitoring tells you what the authoritative source is currently reporting for a physical measurement in a geography you defined. It is not a payout determination, it does not replace the calculation agent, and it does not model your loss. It closes the gap between an event happening and you knowing your position is exposed to it.

For indemnity-triggered instruments, none of this applies — those settle on actual claims, not physical measurements, and no real-time physical feed can anticipate them.

Where to go next

The cat bond catalog is the reference side of the same workflow. If you are monitoring positions across many locations, portfolios aggregate exposure.

Backtest: what the record says

Run backtest on a trigger's page replays the historical record through its terms: the North Atlantic best track (IBTrACS) for wind speed and, from 1990, central pressure; the USGS catalog for magnitude. It reports each storm or earthquake that would have fired it, how far over the threshold, and the return period the record implies. Zero firings is reported as a lower bound on rarity, never as a rate, and a geography outside the catalog is declined rather than reported as zero.

A trigger written on box or polygon terms (zones and tiers) is replayed year by year instead: each year of the record is settled by the same evaluator that settles the live trigger, with the risk period moved to that year. It reports the years that paid, the tier and zone that decided each, the share of years that reached a tier and the mean payout over the record.

On box or polygon terms, the trigger page also reads NHC's current forecast against your zones: whether the forecast track enters each zone, when and at what forecast wind, and whether the cone reaches it. For wind terms it shows the tier that wind would reach if the forecast verified; NHC does not forecast central pressure, so pressure terms show where the track goes and no tier. It is a forecast, superseded by each advisory, not a determination.

Every hurricane backtest counts only NHC's own records: the points IBTrACS interpolates every three hours between NHC's fixes are set aside, and the result says how many.

Linking a trigger to a position

On the ILS dashboard, each position has Link a trigger. Only triggers of the position's own peril are offered (any peril, for a multi-peril position). A linked trigger shows its latest reading on the position, and when it approaches or breaches it writes an alert to that position, listed under Unread alerts.

On a phone, the triggers list shows one card per trigger with its status and percentage of threshold, instead of the table.