Case study / Flood risk modeling

A flood model that admits
when it's unsure.

Most catastrophe models hand a reinsurer one number and expect them to trust it. I built ReInsureSight to hand back a number and a confidence interval — because in flood risk, the difference between those two things is the difference between insuring a region and abandoning it.

RoleSolo build
StackLightGBM, Google Earth Engine, MAPIE
Scope1,202 NatCat events, 131 countries
LinksGitHub repo →
ReInsureSight pipeline: NatCat events to calibrated loss interval 1,202 NatCat events, 131 countries Geospatial features Google Earth Engine LightGBM loss prediction MAPIE conformal prediction 87.1% coverage
ReInsureSight pipeline — from raw event data to a calibrated loss interval

The itch

Reinsurance runs on catastrophe models — software that estimates how much a flood, cyclone, or earthquake is going to cost an insurer before it happens, so premiums can be priced correctly. The problem I kept running into while researching this space is that most flood models output a single loss number and stop there. No error bars, no confidence, nothing. Just a number, presented with the same confidence whether it's backed by decades of dense claims data or by almost nothing at all.

That's fine in a market like the US or Western Europe, where flood claims data is thick and models have been calibrated for decades. It's not fine in the places I actually cared about: the 131 countries in this dataset where flood losses happen just as often, but the data to model them is thin, patchy, or simply doesn't exist in a usable form. A model that's confidently wrong in a low-data region is worse than no model — it tells an insurer to write a policy they shouldn't, or walk away from one they safely could.

What already existed

The commercial catastrophe models used across the reinsurance industry are proprietary black boxes — you license them, you don't get to see inside them, and you definitely don't get an honest answer about where they're extrapolating beyond their training data. On the academic side, flood models are usually hydrological: they're excellent at simulating water depth and extent, but most of them stop before the step that actually matters to an insurer — translating a flood event into a financial loss number. And almost none of them, commercial or academic, quantify their own uncertainty in a way you could actually act on.

A model that's confidently wrong in a data-poor region is worse than no model at all. It just moves the mistake earlier.

How I actually built it

I started from 1,202 real NatCat flood events spread across 131 countries and pulled the geospatial and hydrological features behind each one from Google Earth Engine — elevation, land cover, proximity to water bodies, historical precipitation, the kind of signal that actually explains why one flood destroys a village and another barely floods a field.

For the model itself, I went with LightGBM over a deep learning approach on purpose. With a dataset in the low thousands and heavily engineered tabular geospatial features, gradient-boosted trees consistently beat neural nets on both accuracy and training time — there just isn't enough data for a deep model to earn its complexity here. LightGBM's leaf-wise growth also made it fast enough that I could iterate on feature engineering in minutes instead of hours, which mattered because most of the real work was in the features, not the model architecture.

The part that actually matters: honesty about uncertainty

The single decision I'm most proud of in this project is wrapping the point predictions in MAPIE conformal prediction instead of shipping raw LightGBM outputs. Conformal prediction doesn't just give you a number — it gives you a calibrated interval with a statistical guarantee on how often the true value falls inside it, regardless of whether the underlying model is well-specified. That's the difference between "the loss will be $4.2M" and "the loss will be $4.2M, and I'm 87% confident it falls between $3.1M and $5.6M." One of those is something an actuary can actually price risk against.

The numbers

  • 1,202 NatCat flood events used across 131 countries
  • 87.1% empirical coverage from MAPIE conformal prediction on held-out test data — meaning the calibrated intervals are honest, not just decorative
  • Built to surface major uninsured flood exposure regions — the gaps in the global protection map that plain point-estimate models tend to hide

Why it matters

The global "protection gap" — the difference between economic losses from disasters and the share that's actually insured — is largest in exactly the countries that can least afford to absorb the loss themselves. A model that only works confidently in data-rich markets quietly reinforces that gap. ReInsureSight was my attempt to build something that's useful specifically where the data is thin, by being upfront about exactly how thin, instead of pretending otherwise.

FAQ

What is ReInsureSight?

ReInsureSight is a geospatial flood loss estimation engine built by Aishrica Dhiman for the reinsurance market. It combines LightGBM with Google Earth Engine data to estimate financial losses from flood events across 1,202 real NatCat events in 131 countries, wrapped in calibrated uncertainty intervals instead of a single unqualified number.

Why use LightGBM instead of a deep learning model?

With a dataset in the low thousands and heavily engineered tabular geospatial features, gradient-boosted trees like LightGBM consistently beat deep neural networks on both accuracy and training speed — there simply isn't enough data for a deep model to earn its extra complexity. The speed also made it practical to iterate quickly on feature engineering.

What is MAPIE conformal prediction and why does it matter here?

MAPIE is a Python library that wraps a model's point predictions in statistically calibrated intervals. Instead of "the loss will be $4.2M," it produces "$4.2M, with 87.1% empirical coverage that the true value falls in this range" — a number an actuary can actually price risk against, especially in low-data regions where a single point estimate is more likely to be wrong.

Is ReInsureSight open source?

Yes. The full code is public on GitHub at github.com/aishricadhiman/ReInsureSight.