Innovation

Parametric Insurance Beyond Catastrophe: Cloud Outages, Sensors and AI Performance

Parametric cover used to mean hurricanes and earthquakes. In 2026 it pays out for cloud downtime, shaking at one building, and AI models that stop performing.

On 20 October 2025, an outage in Amazon Web Services’ largest cloud region took down a long list of businesses that had nothing wrong with their own systems.

Guy Carpenter put the insured loss somewhere between $300m and $1bn. Weeks later, that range was still the best anyone had.

Parametrix put the financial damage to US companies at $500m to $650m. CyberCube reckoned close to 70,000 organisations were affected worldwide. And while the rest of the market was still arguing about which of those numbers was right, Parametrix had already paid claims. No adjuster, no proof-of-loss submission, no argument about causation. A monitored service was down for longer than the agreed threshold, so the policy paid.

That is parametric insurance, and until recently it mostly meant hurricanes, earthquakes and rainfall. It has escaped catastrophe, and the reason is more technical than actuarial.

The constraint was measurement, not modelling

A parametric product needs one thing above all: a measurement both sides trust, available fast enough to be worth paying on.

For decades that limited the category to whatever national agencies already measured. Weather and seismology, essentially.

Two developments moved the boundary. Sensors got cheap and dense enough to measure conditions at a specific building rather than across a region. And digital infrastructure became continuously observable by third parties, so the uptime of a cloud region or a SaaS platform is now a matter of public record rather than a vendor’s word.

Once you can measure something independently, in near real time, at the resolution of a single insured, you can write a trigger on it. The underwriting question changes from “what will this loss cost” to “what can we measure, and how closely does it track what the client actually loses”.

AIG put the cover on a policy its clients already buy

On 13 August 2026, AIG launched a parametric cloud outage solution built with Parametrix, available in the US as an endorsement for eligible cyber clients.

The structure repays a closer read than the announcement does.

  • The trigger is a formula, not a claim. Payout is calculated from measured downtime and its financial impact against predefined policy triggers.
  • A two-hour waiting period, then no monetary retention. Short outages are excluded by time rather than by deductible, which suits a risk where the distinction that matters is duration, not severity.
  • The index is somebody’s full-time job. Parametrix monitors more than 750 data centres and tracks over 9,000 software and technology providers across SaaS, PaaS and IaaS. The monitoring is the product as much as the wording is.
  • Distribution is an attachment. Rather than launch a standalone policy and build a channel for it, AIG bolted the cover onto something its clients already hold.

The demand behind it is not hypothetical. Enterprise spending on cloud infrastructure services reached $129bn in the first quarter of 2026 alone, up 35% year over year, and concentration has followed the money: when a handful of regions underpin a large share of commerce, one outage becomes a correlated event across thousands of unrelated businesses.

The CrowdStrike failure of 19 July 2024 had already shown what that looks like from the loss side, taking out roughly 8.5 million Windows devices and, on Parametrix’s estimate, $5.4bn of direct losses among Fortune 500 companies alone.

Twenty-one days after Ica

Peru, 19 May 2026: a magnitude 5.8 earthquake hits Ica.

A commercial client there held a ShakeNet Parametric policy from Liberty Mutual Reinsurance and Safehub, bought the previous October through Price Forbes Latam. The claim was paid 21 days after the event.

The speed is the headline. The sensor is the story.

Safehub’s trigger came from its own sensor network combined with government seismic data, producing highly localised shaking maps. Traditional earthquake parametric pays on magnitude and distance from an epicentre, which is a proxy for what a specific building actually experienced. Measuring the shaking at the site removes a layer of guesswork.

Which is the single most important idea in modern parametric design: the closer the measurement gets to the insured, the smaller the gap between what the policy pays and what the client lost. Everything else in the category is a variation on that sentence.

Worth being precise about what the client bought, though. The parametric layer was a complement to a traditional indemnity placement, not a replacement, and it existed to provide immediate liquidity while the indemnity claim went through its normal process. That is the honest positioning for most of this category, and it argues better than pretending parametric replaces anything.

The same trick, other indices

The pattern travels well beyond physical events.

  • Munich Re’s aiSure prices premium off how a model measures up in testing and settles on performance data rather than loss adjustment, and Armilla’s AI liability policy responds when a model degrades from its underwritten baseline: parametric thinking applied to a risk with no physical event at all, which we go into further in our piece on AI agent insurance products.
  • Flight delay cover triggered on live flight data, with Blink Parametric powering products for Zurich and Klook, and for MAWDY in the MAPFRE group. Payment or lounge access arrives before the passenger has landed.
  • Renewable output shortfall cover indexed to wind speed or solar irradiance, protecting revenue when the resource underperforms rather than when equipment breaks.
  • Supply chain triggers built on shipping indices or named port closures, paying on the disruption itself instead of tracing consequential loss through a contract chain.

What links them is that the loss is real and the paperwork is disproportionate. Parametric works best where proving a loss costs more, relative to the loss, than measuring a proxy for it.

Basis risk, and the fork that decides who regulates you

Start with the problem that never gets solved. The index can move without the client losing money, or the client can lose money without the index moving. Every design decision in a parametric product is really a decision about which direction you would rather be wrong in, and denser data narrows the gap, as Safehub’s sensors do, without ever closing it.

A client who receives nothing after a bad day will not be comforted by an explanation of the trigger. Basis risk belongs in the sales conversation, not in the small print.

Then there is a fork in the contract itself.

A pure parametric cover that pays a set amount on a defined event regardless of any economic loss is frequently executed as a derivative. A hybrid cover, where the trigger fires and the client demonstrates an actual loss, is structured as an insurance contract. Which side of that line you land on determines your regulator, your capital treatment and often whether your capacity partner can write it at all. Decide before drafting the wording, not after.

And the market is smaller than the coverage suggests. Natural catastrophe covers account for roughly 70% of parametric premium in 2026, with agriculture a large share of the remainder. Cloud outage and AI performance are the interesting frontier, not the business. A board paper should model a growing niche rather than a category takeover. The catastrophe share, meanwhile, keeps being refilled: the piece on what the 2026 climate reports mean for insurance has the numbers.

Why there is no market total in this piece

Because the honest answer is that nobody has one.

Published market-size estimates for parametric vary by roughly a factor of six between reputable-looking sources for the same year. Same category, same twelve months, six times the number. Whichever figure ends up in your board pack deserves the same suspicion you would apply to a figure a vendor gave you, and usually for the same reason.

A claim that starts with a data feed

Parametric breaks traditional core systems in one specific place: the claim does not begin with a person.

A monitoring webhook arrives, gets evaluated against the policy threshold, and opens a claim with reserves and an approval route before anyone has spoken to the client. Running that as a single path through workflow automation and a claims module, with a human gate wherever the payment needs one, is the part most platforms were never built for.

Rating what you will get wrong first

The rating side is stranger still. Downtime hours, sensor coverage, provider concentration, model accuracy: you will get the first version wrong, so the rating engine needs editable tables with effective dating rather than a filing cycle, and the Product Builder has to let a business user reshape a trigger as evidence arrives.

The index itself belongs to somebody else, which makes this an integration problem before it is an underwriting one, and the quality of that feed is the quality of your product. AIG’s endorsement route generalises too: a trigger-based add-on embedded in a partner journey reaches a buyer already thinking about the risk. And when money moves without an adjuster, the audit trail is your only evidence of why it moved. Regulators and capacity partners both ask.

None of that is exotic technology. It is ordinary event-driven software, hard mainly for systems that assume a claim starts with a phone call, which is why Openkoda keeps products, rating and claims as configuration you own, on published flat pricing.

The shift underneath all of it is a shift in what limits the category. For thirty years parametric was bounded by what public agencies happened to measure. Now it is bounded by what anyone can measure well enough to be trusted, a much larger and faster-growing set that expands every time somebody installs a sensor network or starts monitoring a category of infrastructure.

So the advantage sits with product design rather than underwriting. It goes to whoever can wire up a new data source, write a trigger against it, test it, and change it three months later when the first real event shows them what they got wrong - a build-and-revise loop that is easier to judge by watching one run in a demo than by reading about it.

See Openkoda in your context

Book a live, personalized demo with our product team - tell us your use case and see the platform work with your data. No commitment.