Skip to main content

Insurance 101 for Engineers

TL;DR: Insurance is pooled risk with a lot of clever plumbing. The plumbing includes reinsurance (insurers for insurers), parametric payouts (a sensor replaces an adjuster), latency and cadence (nothing is truly real-time), and basis risk (the gap between the sensor and reality). This post is how all of that fits together - and what engineers can steal from it.


The Village #

Twenty households in a village. Once a year, a hailstorm rolls through and destroys exactly one roof. Nobody knows whose. Replacing a roof costs 1,500 - which nobody has lying around, and which is enough to ruin a household.

So they make a pact. Every year, each household puts 100 into a shared pot. Whoever loses their roof takes 1,500 out. Nineteen households pay for a roof they’ll never need. One household loses a roof but doesn’t lose the farm. Everybody sleeps better.

That’s the whole idea. What each household pays is called a premium. The written promise (“in exchange for your 100, we owe you up to 1,500 if X happens”) is a policy. The money the unlucky household receives when the storm hits is the payout. The party holding the pot - responsible for collecting premiums, checking the maths still works, and paying out when things go wrong - is the underwriter.

That’s it. That is all insurance is: many people paying small predictable amounts so that a few can survive rare big losses. Every other word in the industry - deductibles, riders, tranches, cat bonds, reinsurance treaties, MGA arrangements - is engineering built on top of the pot.

Reinsurance in One Paragraph #

The village model works because the risk is uncorrelated. Roofs get hit one at a time; if it’s your roof this year, it wasn’t your neighbour’s. But some risks aren’t like that. Drought, earthquake, hurricane - one event hits every household at once. The pot cannot survive it. The fix is that the local underwriter buys their own insurance from a bigger underwriter, called a reinsurer. Reinsurers - Swiss Re, Munich Re, … - pool correlated catastrophes across the whole planet. A drought in one region doesn’t line up with a typhoon in another, so the global pool stays balanced when any single regional pool would tip over. Reinsurance is why national insurers can absorb national disasters without going bankrupt.

Where Classic Insurance Breaks #

The system depends on an adjuster: a human who visits the loss, inspects the damage, and decides what’s owed. In mature markets this works because the payout dwarfs the adjuster’s cost. Insuring a car worth 80,000? Sending an assessor is a rounding error - a few hundred, absorbed easily into the maths.

The system falls apart the moment payouts get small.

If the maximum payout is 300 and it costs 500 to send an adjuster, no amount of clever underwriting closes the gap. Every small claim would lose the insurer money before the payout is even paid. This isn’t a bad-business-model problem; it’s a physics problem. Humans don’t scale below a certain unit cost.

Whole categories of risk fall into this bucket:

  • Smallholder crop losses in emerging markets - a drought-affected maize plot the size of a football pitch, where a total-loss payout might be 300.
  • Small-value travel disputes - a delayed flight worth 150 in compensation.
  • Low-value theft - stolen bicycles and phones.
  • Cold-chain supply-chain disruptions - a shipment of vaccines that spent six hours above 8°C somewhere between the factory and the clinic.

In each case, the payout is real and the customer would happily pay a small premium for the peace of mind. And in each case, the classic model can’t serve them, because sending a human to verify is more expensive than the entire policy.

That’s not a small population. Estimates from IFAD put the un-served smallholder-farmer market alone at over 500 million households. Whole markets, invisible to insurance for structural reasons.

The Parametric Fix #

The move is elegant: don’t measure the damage. Measure the trigger.

Rewrite the policy: “If rainfall in your region during the maize-critical weeks falls below X millimetres, you receive Y - automatically. No claim, no visit, no dispute.” The trigger is a measurement, not an inspection. This is called a parametric policy (also index-based in the trade press). The word “parametric” is doing real work here - the payout is a function of a parameter, and the parameter is a number a machine can read.

Where does the measurement come from? The current stack:

Sensor typeExamplesTypical cadenceTypical latency
Geostationary weatherGOES-R, Meteosat, Himawari10-15 minseconds to minutes
Weather stationsNOAA GHCNhourly to daily1 day
Reanalysis productsECMWF ERA5hourly5 days to 3 months
Precipitation missionsNASA/JAXA GPM, CHIRPS30 min to 1 day4 hours to 3 weeks
Radar satellitesSentinel-1, Capella, ICEYE6-12 days12-48 hours
Optical satellitesSentinel-2, Landsat 8/9, Planetdaily to 16 days12-24 hours
On-chain oraclesChainlinkon demandblock time
Purpose-built sensorsocean buoys, GPS trackers, seismographsvariesseconds to hours

Derived products layered on top of the raw feeds add another dimension: rainfall estimates from radar, soil moisture, vegetation greenness (a leaf under drought stress reflects light differently to a healthy one), sea-surface temperature. And on-chain oracles replace the adjuster entirely with a smart-contract input - the parametric branch that grew out of smart-contract programmability.

The property that makes parametric so powerful: the marginal cost of a measurement doesn’t scale with the number of policies. A satellite pass over one field costs the same as a satellite pass over a million fields. Suddenly the maths that classic insurance couldn’t close does close, easily.

One common misconception worth defusing: parametric is not “faster claims processing.” There is no claim to process. It’s a fundamentally different truth model.

Latency and Cadence: Nothing Is Real-Time #

People new to sensor-driven products often reach for “real-time” as if it means “as it happens.” It doesn’t - not for satellites, not for weather stations, not for anything. Two words used every day inside the industry make the trade-offs precise, and both of them are already in your engineering vocabulary in a different guise.

Latency - the gap between an event happening and the data about it being usable. Never zero.

Cadence - how often you get a fresh measurement of the same place. Sets the resolution of your understanding through time.

Concretely: a Sentinel-2 pass captures an image at 10:00; the raw data hits a ground station 45 minutes later; the derived product (rainfall estimate, greenness index) is ready 6 to 24 hours after that - that’s the latency. And the same satellite only revisits the field every 5 days - that’s the cadence. Different sensors trade these differently: geostationary weather refreshes every 10-15 minutes but at much coarser resolution; a weather station reports hourly; a cold-chain temperature logger reports every 60 seconds.

Latency and cadence timeline showing three samples on a time axis and their delayed data-usable points
Figure 1: cadence sets how often the sensor fires; latency sets how long each firing takes to become usable

The pair matters because they trade off against each other and against cost. High-cadence, low-latency, high-resolution: pick two. Once you say it that way it looks like exactly the sort of trade-off engineers reason about every day - because it is. When someone in this industry says “real-time monitoring”, they mean “latency short enough and cadence high enough that decisions are timely relative to the physical process being monitored.” A rainfall product with 24-hour latency and 5-day cadence is real-time for a drought playing out over eight weeks. It is emphatically not real-time for a flash flood playing out over eight minutes.

The engineering translation: you already know this pattern. Metrics scraped every 15 seconds have a cadence of 15 seconds. The p95 dashboard refreshes with a latency of maybe 30-60 seconds behind reality. The word “real-time” in front of any monitoring product deserves the same suspicion in insurance as it does in engineering.

Basis Risk: The Honest Catch #

The moment you replace an adjuster with a measurement, you introduce a new problem: the measurement is not the loss.

Rainfall averaged over a 5-kilometre grid cell is not the same as the rainfall on a specific field within that cell. The satellite says the region got enough water; a farmer in a rain shadow within that cell did not, and the crop failed anyway. The trigger doesn’t fire. The payout doesn’t happen. The insured is destroyed and receives nothing.

Grid cell showing a sensor average of 50mm covering three fields with 20mm drought, 60mm and 90mm healthy - the drought field receives no payout despite the crop failure
Figure 2: the satellite average hides the field that actually needed help

That gap has a name: basis risk. It is the difference between what the sensor says and what actually happened to the insured. Every parametric product has it. It cannot be eliminated - a proxy is a proxy - but it can be minimised with better data (higher resolution, more accurate models, ground-truthing) and disclosed honestly.

Latency and cadence are their own kind of basis risk - temporal, not spatial. A trigger that fires two weeks after the drought ended is technically correct and operationally useless. A cadence too coarse to catch a short but intense event misses it entirely.

The rule of the trade: hiding basis risk is worse than owning it. A farmer whose crop failed and who received no payout because the sensor said “rain enough” is the worst kind of dissatisfied customer, and word travels fast. Products that acknowledge basis risk up front, show the trigger publicly, and offer a well-signposted appeal path for edge cases build trust. Products that pretend the sensor is infallible get burned the first time reality disagrees.

Basis risk is what you’re actually paying for when you buy a cheap parametric product. The maths gets to close because the customer takes the residual risk of the sensor being wrong. That is a legitimate trade - as long as everybody knows they’re making it.

Where Parametric Already Lives #

This is not theoretical. Parametric products are already deployed at scale in several places worth naming. Emerging-market crop insurance is the largest use case by policy count.

DomainProvidersTrigger source
Emerging-market crop insuranceWorld Bank GIIF, ILO Impact Insurance, IFADCHIRPS satellite rainfall + regional models
Public-sector catastrophe coverCCRIF SPC, PCRICEarthquake magnitude, wind speed, excess rainfall
Travel delayMajor card networks + insurersAirline delay APIs
Blockchain-native parametricEtherisc, Arbol, NaymsChainlink on-chain oracles
Corporate weather derivativesCME Group weather futuresTemperature, rainfall, hurricane indices

What Engineers Can Steal From This #

Every parametric mechanism above has an engineering twin. Naming them lets you carry the mental model back to your own work.

Insurance conceptEngineering twinThe pattern
AdjusterOracle, health probe, external monitoringTrusted third-party as truth source
Damage-triggered payoutIncident-driven alertPost-hoc, needs a human
Parametric triggerSLO / error-budget burn alertAlert on the condition, not the damage
Automatic payoutAutomated rollback on thresholdDecision without a meeting
Basis risk in payoutsMetric != user experienceEvery proxy has a gap
Sensor cadence + latencyMetric scrape interval + dashboard lag“Real-time” is relative

Oracles vs. adjusters. A parametric policy replaces a human decision with a trusted external measurement. Distributed systems solve the same problem the same way: consensus oracles, health-check probes, external monitoring services, third-party audit logs. “Oracle” is one of the few terms that means roughly the same thing in insurance, distributed systems, and blockchain - a trusted external source of a fact, so parties who don’t trust each other can still transact.

Basis risk in monitoring. Your latency histogram is not your user’s experience. Your synthetic health check is not real user traffic. Your Kubernetes readiness probe is not application health. Every observable metric has basis risk relative to the thing you actually care about. Naming this explicitly - “how big is our basis risk on this SLI?” - is a healthier engineering conversation than pretending the metric is the truth.

The general principle: when the human decision is the bottleneck, replace it with a measurement and own the basis risk that appears. The trade-off is always there. The discipline is naming it.

Mini-glossary #

  • Premium - the regular payment the insured makes for coverage.
  • Policy - the contract; the specific promise for a specific amount, in exchange for the premium.
  • Payout - the money paid when the covered event occurs.
  • Underwriter - the entity that holds the risk and issues the policy.
  • Reinsurer - an underwriter for underwriters; absorbs correlated catastrophic risk across the globe.
  • Adjuster - the human who inspects the loss and decides what’s owed.
  • Parametric / index-based - a policy where a measurement, not an inspection, triggers the payout.
  • Latency - the gap between an event happening and the data about it being usable.
  • Cadence - the interval between successive measurements of the same thing.
  • Basis risk - the gap between what the sensor says and what actually happened to the insured.
  • Catastrophe bond (cat bond) - a debt instrument where investors take on catastrophe risk in exchange for higher yield; often parametric.
  • Oracle - in engineering and in blockchain-native insurance, a trusted external source of a fact.

The maths always closes. Somebody takes the residual risk. The discipline is knowing who.