Telematics and IoT: The Data Insurers Collect and Never Use

Ask a motor insurer with a telematics programme how much data they're collecting. You'll get an impressive number — billions of GPS points, accelerometer readings, trip records, harsh-braking events.

Then ask what decisions that data actually changes. The answer is usually: a discount at renewal, and a dashboard nobody opens.

That's a remarkable gap. You built the collection infrastructure — the hard, expensive part — and then used maybe 5% of what it produces.

The pattern is everywhere in insurance IoT

It's not just motor:

  • Telematics collects continuous driving behaviour, and is used to apply one annual discount tier.
  • Connected home sensors detect leaks and are used to... send the customer an app notification.
  • Commercial IoT monitors equipment continuously, and feeds a quarterly risk-engineering report.
  • Wearables in health and life gather daily activity, and drive a points-and-vouchers scheme.

In each case the data is high-frequency and behavioural. In each case it's used for something low-frequency and cosmetic.

Why it happens (it's not laziness)

Three structural reasons, all fixable:

1. It lands somewhere separate. Telematics almost always arrives via a vendor platform with its own store and its own dashboard. It never joins your policy and claims data. So nobody can ask "do harsh-braking scores predict claims for our book?" — the two datasets live in different worlds and there's no key between them.

2. Volume scared everyone into aggregation. Raw telematics is enormous, so the pragmatic move was to summarise it — a monthly score, a discount tier. But the summary throws away the signal. "Score 82" tells you almost nothing; "brakes hard at the same junction every evening" tells you a lot. Aggregation preserved storage costs and destroyed the value.

3. Nobody defined the decision. The programme was launched for marketing reasons — competitors had one. The business case was acquisition, not underwriting. So no decision was ever wired to the data, and data with no decision attached is a cost centre.

What this data could actually decide

Claims validation. This is the highest-value use and almost nobody does it. A claim says the accident happened at 8pm on the Pune bypass. Your telematics knows where the vehicle actually was. That's not fraud detection by inference — that's ground truth, and it's already in your possession. Similarly, a "flood damage" property claim against connected-sensor history showing a dry basement.

FNOL automation. Crash detection means the first notice can be automatic — you know there was an impact, its severity and location, before the customer calls. That collapses claim cycle time at the front end where the delay actually is.

Real underwriting signal, not a discount. Mileage, time-of-day, road types, and behaviour are far more predictive than the proxies you price on today (age, postcode, vehicle). Most insurers use telematics to reward the drivers they've already identified as good, rather than to find the ones their traditional model mis-classified. The second is worth vastly more.

Prevention. A leak sensor firing should trigger an intervention, not a notification. A prevented claim is worth more than a fast one, and it's the only lever that improves both loss ratio and customer sentiment at the same time.

Renewal and retention. Behaviour change is the earliest signal that a customer's risk — or their engagement — is shifting. It's sitting unread.

What has to change

Join it to your book. The single highest-value action: get telematics/IoT out of the vendor silo and into your lakehouse, keyed to policy and customer. Until that join exists, none of the above is possible. This is unglamorous plumbing and it unlocks everything.

Keep enough resolution. Not raw forever — but don't collapse to one number either. Keep trip-level and event-level. Storage is cheap; the signal you deleted is gone permanently.

Make it real-time where the decision is real-time. Crash detection and claims validation need the data now. Underwriting recalibration doesn't. Split by decay rate, as always.

Wire one decision first. Don't build a platform. Pick claims validation — take last year's suspicious motor claims, join telematics, see how many contradict the reported circumstances. That's a business case you can compute in a fortnight from data you already own.

The privacy line — say it plainly

This data is intimate. It knows where someone sleeps, when they leave, whether they were near the place they claim. Using it to validate a claim is defensible; using it in ways the customer never understood they consented to is not — and increasingly not legal.

Get consent explicit and specific, keep it PII-governed and access-controlled, and be able to explain exactly what you used and why. Under the NAIC bulletin and EU AI Act, "we had the data so we used it" isn't a position.

The point

Most insurers don't have a telematics data problem. They have a telematics decision problem. The collection works. The pipes just end in a dashboard instead of a decision.

You already paid for the hard part. It's sitting there, joined to nothing, deciding almost nothing.

We connect telematics and IoT feeds into governed lakehouses where they actually reach decisions. More at IntelliBooks.

Comments

Popular posts from this blog

Snowflake or Databricks for Insurers? An Honest Comparison

What 200+ Cloud Migrations Taught Us About Insurance Data

From Mainframe to Lakehouse: How to Modernize a 30-Year-Old Policy System Without Downtime