Geocoding to the Postcode Centroid Is Silently Costing You (A Data Problem)

If you build risk or pricing models on property data, here's a quiet bug worth checking: how are your locations geocoded? At a lot of insurers, every risk is snapped to the postcode centroid — one point representing an area that can span kilometres. For admin, fine. For anything spatially sensitive — flood, wildfire, storm surge, accumulation — it's a systematic error that costs real money.

The centroid problem

A centroid places every risk in that postcode at the same point: the geographic middle. But hazards are sharply local. Flood risk flips across a single street depending on which side of a contour you're on. Snap all risks to one point and you've thrown away exactly the spatial precision the peril cares about.

Crucially, this isn't random noise that averages out. It's structured error: risks near a river but on high ground get overrated; risks in the same postcode but in the floodplain get underrated. You overcharge safe customers (who leave) and undercharge dangerous ones (who stay). Adverse selection, manufactured by your own geocoding.

Where it bites

• Cat models. A cat model is only as precise as the exposure you feed it. Centroid coordinates → modelled PML and accumulation built on points that can be off by kilometres.
• Flood. The peril most sensitive to precise location, handed a point accurate to a neighbourhood.
• Accumulation. "How much exposure within 1km of this coastline?" is unanswerable if exposure is snapped to centroids.

Keep the precision metadata (the part people skip)

Don't just geocode more precisely — record how precise each result is. A geocode that resolved to a rooftop and one that fell back to a postcode are not the same fact, and your model should be able to tell them apart.

{
  "risk_id": "P-88213",
  "lat": 51.5079,
  "lon": -0.0877,
  "geocode_precision": "rooftop",   // rooftop | street | postcode_centroid
  "confidence": 0.98
}

What good looks like

1. Geocode to the structure, captured at quote time with a confidence score.
2. Store the precision level so downstream models can weight or exclude low-confidence points.
3. Re-geocode the back book — the in-force portfolio is where the accumulated error lives; a one-off enrichment pass often reveals exposure you didn't know you had.
4. Feed precise coordinates into cat and pricing models — they were always capable of using them; they were starved of them.

This is a data-quality problem, not a modelling one — which is exactly why it's fixable without touching the actuaries' work.

Full write-up:

Geocoding Is Quietly Costing You: Exposure at the Address, Not the Postcode →

From IntelliBooks' series on the data foundation under insurance AI.

How does your pipeline track geocode confidence — or does low-confidence silently get treated the same as rooftop?

Comments

[Roman Kotenko]

Answering your closing question directly: we store it, and the payoff was not better coordinates - it was that every downstream analysis can split on the flag.

We match structures from a federal infrastructure inventory to road geometry. The inventory's published coordinates are imprecise enough that matching by coordinate alone will confidently attach a record to the neighbouring structure, so we keep how each record was matched beside the match itself - name-confirmed versus coordinate-only. The first time that earned its keep was not a precision improvement. We were comparing the official measurement against an independently mapped one and found a pile of disagreements; splitting on the match flag showed the disagreement was concentrated in the coordinate-only subset. Without the flag we would have published a data conflict that was really our own matching artefact. Your version of that is an accumulation report that is actually a geocoding report, and it is unfalsifiable if precision is not stored.

The dimension I would add to your rooftop | street | postcode_centroid ladder: precision and recency are different axes and you need both. A rooftop geocode from 2019 and a rooftop geocode from this morning are the same precision and not the same fact. In our domain that is not theoretical - a physically measured bridge clearance only ever decreases as the road under it is resurfaced, so when a precise old figure disagrees with a coarser new one, the coarser new one is often the one to trust. If the record carries only a precision level, a model has no way to reach that conclusion. Store the observation date next to the precision and let the model weigh them.

Your point that the error is structured rather than noisy is the one I would lead with if you write the follow-up. Actuaries have a strong prior that measurement error averages out, and geographic error does the opposite: it correlates with exactly the terrain the peril cares about, so aggregation concentrates it instead of cancelling it.

(Disclosure: I work on road511/napspan - road and traffic data for North America and Europe. The inventory above is around 662,000 live bridge-clearance records on our North American side, and the match-confidence flag is a field we shipped after being burned by not having it.)

[Valentin Monteiro]

Storing the level is the right move, but confidence scores aren't comparable across providers, so the moment you re-geocode the back book with a different geocoder than the one used at quote time, a 0.9 threshold means two different things inside the same column. Same for the categorical level: rooftop from a 2019 reference dataset and rooftop from today's aren't the same fact, and nothing in that record distinguishes them. Provider and reference-data version alongside precision would fix both. Do you normalise confidence to a common scale, or gate on the level and ignore the score?