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

Ask a property insurer where a given risk is located and you'll usually get a postcode. Ask where it actually is — the specific building, its elevation, its distance from the coast or the river — and you'll often get a shrug. Most insurers geocode exposure to the postcode centroid: a single point that represents an area which might span kilometres. For everyday admin, fine. For catastrophe modelling, flood rating, and accumulation management, it's a quiet, systematic error that costs real money.

The centroid problem

A postcode centroid places every risk in that postcode at the same point — the geographic middle. But hazards don't respect postcode boundaries, and they're often sharply local. Flood risk can change completely across a single street depending on which side of a contour you're on. Wildfire risk depends on the specific slope and vegetation. Storm surge depends on metres of elevation. Snap all those risks to one centroid and you've thrown away exactly the spatial precision the peril cares about.

The result 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're simultaneously overcharging safe customers (who leave) and undercharging dangerous ones (who stay). Adverse selection, manufactured by your own geocoding.

Where it bites hardest

  • Catastrophe models. A cat model is only as precise as the exposure you feed it. Centroid-level geocoding means your modelled PML and accumulation are built on coordinates that can be off by kilometres. The model looks sophisticated; its inputs are blurry.
  • Flood. The peril most sensitive to precise location is the one where centroid error does the most damage. Metres matter, and you've given the model a point that's accurate to a neighbourhood.
  • Accumulation management. "How much exposure do we have within 1km of this coastline?" is unanswerable if your exposure is snapped to centroids. You can't manage an accumulation you can't locate.
  • Reinsurance. Imprecise exposure flows straight into your submission, and the reinsurer's model inherits the blur — usually pricing in an uncertainty load that you pay for.

Why insurers haven't fixed it

Partly history: legacy systems captured postcodes because that's what fit the form and the era. Partly inertia: address-level geocoding was once expensive and slow. Neither excuse holds in 2026 — precise geocoding is cheap, fast, and available almost everywhere. The barrier now is that nobody owns the problem. It sits between underwriting, actuarial, and IT, and improving it doesn't show up as a line item anyone is accountable for, so it doesn't happen.

What good looks like

  1. Geocode to the structure, not the postcode. Rooftop or address-level coordinates, captured at the point of quote and stored with a confidence score.
  2. Keep the precision metadata. A geocode that resolved to a rooftop and one that fell back to a postcode are not the same fact — record which is which, so the model can treat them differently.
  3. Re-geocode the back book. The in-force portfolio is where the accumulated error lives. A one-off enrichment pass against modern geocoding often reveals exposure you didn't know you had.
  4. Feed precise coordinates into cat and pricing models. The model was always capable of using them; it was starved of them.

This is a data-quality problem, not a modelling one — which is precisely why it's fixable without touching your actuaries' work. Getting exposure data right at the address level, with the lineage and confidence to prove it, is the kind of foundational data work we do with insurers at IntelliBooks.

Your cat model isn't wrong. It's just answering a precise question with imprecise coordinates — and quietly mispricing every risk near an edge.

Comments

Post a Comment

Popular posts from this blog

Why Your Insurance Data Warehouse Didn't Fix Anything

You built the data warehouse. It took eighteen months and cost more than planned. Policy data, claims data, billing — it's all in there. The project was declared a success and everyone moved on. And yet: underwriting still can't see the whole customer. The AI initiative is still stalled. Someone still asks for a report and waits three weeks. Nobody says it out loud, but the question hangs there — what exactly did we buy? You're not alone, and it isn't because you built it badly. It's because a warehouse solves a problem you didn't have. The problem a warehouse solves Warehouses solve location . Before: your data was in eight systems. After: it's in one place. That's genuinely valuable — you can run a query across policy and claims without begging two teams for extracts. But notice what that fixes: it fixes where the data is . It doesn't touch what the data means , whether it's trustworthy, or whether the records refer to who you think t...
Read more

Straight-Through Processing: From 10% to 90%

Straight-through processing is the number every insurance executive quotes and almost nobody achieves. The industry benchmark has moved from 10–15% to 70–90% at the carriers who've cracked it. That's not a marginal efficiency gain — it's a different cost structure. So why is your STP rate still stuck in the teens? Because STP gets treated as a workflow project. It isn't. It's a data problem wearing a workflow costume. What STP actually requires Straight-through means a quote, policy, or claim goes from submission to completion with zero human touches . For that to happen, every decision point in the chain has to be answerable automatically. Every single one. A chain of nine automated steps and one manual check isn't 90% straight-through — it's 0%. One human touch and the whole thing is a manual process with extra steps. That's the bar. And it means the constraint isn't the workflow engine — it's whether the data needed at each decisio...
Read more

Embedded Insurance: Why the API Is the Easy Part

Embedded insurance is the idea that coverage should be offered at the moment of need, inside someone else's product — travel insurance at checkout, device protection when you buy the phone, cover for the rental car in the booking flow. It's one of the fastest-growing distribution models in the industry, and every insurer has a strategy slide about it. Most of those strategies underestimate the same thing, and it isn't the partnerships or the product. It's the data plumbing. Everyone assumes the API is the hard part. The API is the easy part. What embedded insurance really demands The promise of embedded is speed and invisibility: a customer buys a flight and, in the same breath, is offered exactly the right travel cover at exactly the right price, and accepts with one tap. No forms, no friction. Deliver that and you've won. But "exactly the right cover at exactly the right price in one tap" makes brutal demands on your back end: You must price i...
Read more