What problem does it solve?
After a major flood, hurricane or wildfire, an insurer's first question is simple and hard to answer fast: which of our policyholders were actually in the affected area, and how badly. Ground surveys and adjuster visits take days to weeks, and the customers who need help most, people whose homes are flooded or burned, can be the hardest to reach through a normal contact centre queue. Traditional catastrophe modelling looks at the portfolio before an event, for pricing and reinsurance; it was not built to say, soon after landfall, which specific addresses are affected today.
Satellite radar flood data covering an affected region is already sold to insurers. Turning that data into a ranked list matched to a specific policy portfolio, so claims and contact centre teams can act on it, is the part this use case addresses.
How does it work?
- Watch for a trigger event. A named storm, a flood warning or a wildfire perimeter update starts the process, either automatically from a data provider's feed or through a manual confirmation.
- Pull the hazard footprint. The system retrieves the satellite radar or optical data for the affected area, such as a flood extent and depth map or a wildfire perimeter, from a licensed geospatial data provider.
- Match it to the portfolio. Every policy's geocoded address is checked against the hazard footprint, so the system can say which policies fall inside the affected area and, where the data supports it, how severely.
- Rank and route. Affected policies are ranked by likely severity and value at risk and pushed into the claims and customer contact systems as a prioritized list, not a separate map nobody opens during a crisis.
- People act on it. Claims teams prioritize adjuster visits and reserve reviews, and contact centres proactively reach out to the highest priority customers first, instead of waiting for everyone affected to call in.
- Audience
- Back office
- Autonomy
- Assist
- Adoption
- Emerging
- Channels
- API and system to system, Internal tools
What is it worth?
Benchmarks are computed from the public deployments below: one data point per organization per KPI, with who made each claim.
No public deployment has disclosed a measurable outcome yet.
Value drivers: Speed and cycle time, Customer experience, Lower cost to serve, Risk and loss reduction.
Indicative value
A property insurer with 300,000 policies in a flood or hurricane exposed region
USD 150,000 to USD 3 million
Claims assessment cost impact (avoided cost plus the value of faster handling) per major catastrophe event per major catastrophe event
How this is calculated
Formula: policiesInPath * assessmentCostPerPolicy * shareAvoidedOrAccelerated. The low scenario uses every low input, the high scenario every high input.
| Input | Low | High | Basis |
|---|---|---|---|
| Policies typically in the path of a major regional catastrophe policiesInPath, policies per major event | 15,000 | 50,000 | Editorial assumption, replace with your own catastrophe exposure data for the region. |
| Cost of a manual desk or field assessment avoided or accelerated per affected policy assessmentCostPerPolicy, USD per policy | 50 | 150 | Editorial assumption for a manual site visit or desk review avoided or sped up. Replace with your own claims handling cost. |
| Share of affected policies where satellite data avoids or meaningfully speeds up a manual visit shareAvoidedOrAccelerated, fraction of affected policies | 0.2 | 0.4 | Editorial assumption, replace with your own. Not every affected policy needs a site visit in the first place, so this is well under all affected policies. |
What it leaves out: Blends a real cost avoided (no desk or field assessment needed at all) with the value of an assessment that only happens faster, which is not itself a cash saving. It leaves out the cost of the satellite or geospatial data subscription and integration work, and any effect on loss reserves, reinsurance recoveries or customer retention.
Who already uses it?
2 public deployments, strongest evidence first. Grades: A regulator or audit, B the organization itself, C vendor case study, D anonymous or estimate.
Sompo Japan Insurance
Japan · Insurance · 2026
Sompo Japan Insurance signed a contract with ICEYE to use its Flood Insights satellite radar product as part of the insurer's Hikeshi DNA 2030 Project, which aims to enhance regional resilience; strengthening its response before, during and after natural disasters is one of the project's pillars. Yasuhiro Tsukahara, CEO of ICEYE Japan, said that rapid, accurate intelligence on the extent and severity of flooding can help enable a faster, more efficient claims response after a major flood event. ICEYE's own Flood Insights product page states that the product "combines ICEYE's radar satellite imagery with an abundance of third-party data, algorithms, and machine learning" to quantify flood extent, which is the AI component of this deployment. The announcement discloses no volume, cost or speed figures for the deployment itself.
No outcome disclosed.
Suncorp Group
Australia · Insurance · 2022
During the 2022 Australian floods, Suncorp combined ICEYE's satellite radar flood data with Arturo's property data. ICEYE's case study describes this as the technology that enabled Suncorp to assess flood impacts accurately, prioritize resources, and support customers faster by at least a week. The case study landing page itself does not use the words AI, machine learning or algorithm; ICEYE's separate Flood Insights product page states that its satellite flood products combine third party data, algorithms and machine learning to quantify flood extent, but does not name this Suncorp deployment specifically. No numeric breakdown of the underlying calculation is given beyond the "at least a week" figure.
No outcome disclosed.
How do you implement it?
A model agnostic playbook: what to prepare, the order to build in, and what goes wrong.
Data you need
- Geocoded policy and property addresses (real coordinates, not just a postcode) across the exposed portfolio
- A licensed satellite or geospatial data feed for the peril that matters most (flood extent, wildfire perimeter, wind swath)
- A defined trigger, such as a named storm or a flood warning, that starts the assessment process
- Historical claims data per hazard zone to check the exposure output against
Systems to integrate
- Policy administration system for the geocoded portfolio
- Claims management system to receive the prioritized, affected policy list
- A satellite or geospatial data provider API for the relevant peril
- Customer contact channels for proactive outreach to affected policyholders
- A catastrophe or exposure management platform for portfolio level aggregation
Complexity: High
The hard part is matching the imagery to a reliably geocoded policy portfolio and getting a ranked, trustworthy list into claims and contact centre systems soon after an event, while ground access is still limited.
- 1
Geocode the portfolio before anything else
A satellite hazard map is only as useful as the coordinates it is matched against. Turning postal addresses into reliable geocoordinates for the whole book is usually the longest step, and it pays off before the next event, not just this one.
- 2
Start with one peril and one data feed
Pick the peril that hits the book hardest, flood, wildfire or wind, and license one geospatial data provider for it rather than trying to cover every peril at once.
- 3
Define the trigger and the workflow
Agree what starts the assessment (a named storm, a flood warning, a wildfire perimeter update), what runs automatically, and what a person must confirm before it reaches claims or customers.
- 4
Deliver a ranked list, not a map
Push the prioritized, affected policy list into the systems claims and contact centre teams already use. A standalone GIS viewer gets ignored during a live event.
- 5
Test it on a past event before the next one
Replay the satellite data and the portfolio from a real past catastrophe and compare the system's affected policy list against what the claims data later showed, before relying on it live.
Guardrails
- Every flagged policy carries the data source, its resolution and its timestamp, so a claims handler can judge how much to trust it
- A minimum resolution and confidence threshold before a property is marked affected; below it, the policy goes to manual review
- A human confirms before any automated customer contact or reserve change based on the exposure data alone
- Third party geospatial data providers are checked for licence terms and update frequency before being relied on live
KPIs to instrument
- Time from the trigger event to a prioritized list of affected policies
- Share of affected policies correctly identified against later claims data
- Customer contact time for policies in the affected area, before and after
- False positive rate, policies flagged as affected that had no resulting claim
Human in the loop
Claims and exposure teams decide what to do with the prioritized list: who gets called first, what reserve to hold, when to send an adjuster. The AI ranks and flags policies; it does not settle a claim, change a reserve or contact a customer on its own.
Common failure modes
- Resolution too coarse for the portfolio
- Satellite flood or wildfire data has a real resolution limit, and a policy at the edge of a flagged area may not actually be affected. Treat the output as a priority list for human follow up, not a verdict on any individual policy.
- Geocoding gaps hide exposure
- Policies with only a postcode or a PO box cannot be matched against the hazard footprint and silently fall out of the list. Track and report the share of the portfolio that could not be geocoded.
- Built for one event, unused for the next
- A one off integration rushed together for a single storm does not survive to the next event if nobody owns the data feed contract and the workflow. Assign an owner and renew the data licence before the next season it needs to cover.
What are the risks and rules?
EU AI Act
Minimal risk
Not listed in Annex III: the system aggregates satellite and portfolio data to prioritize claims response and inform exposure management, and does not decide an individual's cover, price or claim outcome. It would need reassessment if the same output were used to automatically decline or reduce a specific claim without human review.
Rules that apply
Guidance
- Opinion on Artificial Intelligence governance and risk management (European Insurance and Occupational Pensions Authority, Europe). Sets out how existing insurance sector legislation on governance, risk management and data quality applies to AI systems across the insurance value chain that are not high risk under the AI Act. It does not name catastrophe or exposure analytics specifically.
Controls to put in place
- AI inventory entry for the exposure model with an accountable owner
- Documented resolution and confidence thresholds per peril, reviewed after each major event
- Audit trail linking every flagged or prioritized policy to the data source and timestamp used
- Post event validation comparing flagged policies against the claims that were actually reported
Frequently asked questions
- Can AI tell an insurer which policies a flood or hurricane affected before ground surveys are possible?
- Yes, within real limits on resolution and confidence. ICEYE says its Flood Insights product combines satellite radar imagery with algorithms and machine learning to quantify flood extent, and Sompo Japan Insurance signed a contract in September 2026 to use it for its own claims response. Suncorp's earlier case study with Arturo and ICEYE reports that combining satellite flood data with property data supported customers at least a week faster during Australia's 2022 floods. Treat the output as a priority list for human follow up, not a verdict on any individual claim.
- Is this the same as catastrophe modelling for pricing and capital?
- No. Traditional catastrophe models estimate probable losses across a portfolio before an event, for pricing and reinsurance. This use case is about knowing, soon after a real event, which specific policies are actually in the affected area, so claims and contact centre teams can act on the highest priority cases first.
- What data does an insurer need before starting?
- A portfolio geocoded to real coordinates, not just a postcode, and a licensed satellite or geospatial data feed for the peril that matters most to the book. Without accurate geocoding, the satellite data has nothing reliable to match against.
- Is this high risk under the EU AI Act?
- Usually not. It is not listed in Annex III because it prioritizes response and informs exposure management rather than deciding an individual's cover, price or claim outcome. It would need a fresh risk assessment if the same output were used to automatically decline or reduce a specific claim without a person reviewing it.
How to cite this page
Blits.ai AI Use Case Library, "AI for catastrophe and exposure assessment in insurance", last verified 30 September 2026, https://www.blits.ai/ai-use-cases/catastrophe-exposure-assessment. Licensed under CC BY 4.0. Method: how we verify use cases.
Changelog
- 30 September 2026: Published after review by an automated review workflow (independent skeptic review).
- 30 September 2026: Review fix pass: added ICEYE's Flood Insights product page (states "algorithms, and machine learning") as evidence that ICEYE's satellite flood product line uses AI, since neither the Suncorp nor the Sompo source page used the words AI, machine learning or algorithm on their own. Reworded FAQ 1 to separate the AI method claim (sourced to ICEYE's product page and the Sompo contract) from Suncorp's outcome claim, which is not itself described as AI by its source. Dropped "AI" from the Suncorp evidence title. Replaced the Suncorp evidence's response-time-reduction metric (wrong unit, sourced to a gated teaser question) with the declarative outcome in the summary and no formal KPI, since no taxonomy KPI fits an unquantified claim of days saved. Rewrote metaDescription to attribute the outcome to ICEYE and stay within what the source says. Rewrote blitsAi.howToBuild to drop the human handover queue and policy count analytics claims, neither of which the feature inventory supports for a background workflow with no live conversation, and replaced them with the custom function write back, run history and audit trail the inventory does support. Removed three unsourced factual generalizations from problem and feasibility.complexityNote (call volumes spiking, imagery being easy to buy, imagery usually arriving as an unmatched map).
- 30 September 2026: Unpublished by an automated review workflow (independent skeptic review).
- 29 September 2026: First published