Drought Monitoring

DS-BL

How to set a strike level for a vegetation index insurance contract

A reservoir reduced to a thin strip of water surrounded by a wide expanse of cracked, dry lakebed.

Setting a strike level is the part of index design where the spreadsheet meets the field, and where a bad call shows up two years later as an unpaid claim nobody can explain. The strike itself is just a number: the anomaly value below which the contract pays. Getting there takes four decisions, in order, and most of the arguments between underwriting and the grower come from skipping one of them.

Pick the baseline before you pick the number

A strike is meaningless without something to be a departure from. The common mistake is anchoring to last season, a single good or bad year that happens to be on file. Last season is weather, not climate. A strike built off one prior year will drift the first time conditions are even slightly unusual, because there's no long-run average telling you what "unusual" means for that region.

The baseline needs to span enough years to smooth out the outliers: a drought year, a flood year, a couple of average ones. Ten years is thin. Twenty-plus starts to look like something you can defend to a reinsurer. Whatever the window, it has to be computed region by region, because a vegetation index baseline for a river-valley block and a baseline for a dryland block three counties over are not the same curve, even in the same crop.

Choose the anomaly metric, not just the index

NDVI, EVI, or whatever greenness index the contract references is only the raw input. The strike is written against the anomaly: how far this month's reading sits from the baseline, expressed as a z-score, a percent-of-average, or a standardized departure. Each has tradeoffs.

Percent-of-average is readable to a grower and easy to explain in a claims letter, but it treats a 10-point swing in a region with a stable climate the same as a 10-point swing in a region that's volatile every year. A z-score corrects for that, because it's scaled by the region's own historical variance, but it reads like statistics to someone who's never seen one before. Pick the metric that matches who has to sign off on the payout decision, and state it in the contract wording before anyone argues about a specific month's reading.

Set the bands, then backtest

Once the metric is fixed, the severity bands come next: mild departure, moderate, severe, and the strike sits at the edge of whichever band triggers payout. This is where pricing discipline lives. Run the proposed strike against ten or twenty years of the same region's anomaly history and ask how often it would have fired, and whether those firings line up with years growers remember as genuinely bad ones. If a strike set at the 15th percentile of historical anomalies would have paid out six years in twenty, that's a loss ratio question, not a severity question, and it needs to go back to pricing before it goes to contract.

Basis risk is the thing that kills an index product's reputation faster than anything else: a payout that doesn't match what happened on the ground, or a bad season that never crosses the line because the strike was set loose. Both failure modes trace back to using too short a baseline, or to picking a single ground report instead of a consistent regional read. A monthly anomaly computed region by region against a multi-decade record, rather than a rainfall total from the nearest gauge, closes most of that gap because the index is measuring the crop's response rather than a proxy for it.

The deliverable that makes this workable in practice is an anomaly value and a severity class per region, refreshed every month and exported in a form that drops straight into a pricing model, whether that's a CSV for a loss-run or a map layer for a regional desk. Drought Monitoring runs that calculation on a wide-swath multispectral read, monthly, against the baseline for each region, so the strike conversation starts from a number instead of a guess.

If you're mid-renewal and need a region's anomaly history before the next pricing cycle, that's the starting point to work from.

Start a project

← Back to the blog