The Insurance Data Quality Score: How to Measure What You've Never Measured

Ask an insurance executive about their data quality and you'll get an adjective. "It's messy." "It's not great." "Better than it was." Ask for a number and the room goes quiet.

That's the whole problem in miniature. Data quality is the single biggest determinant of whether AI, automation, and analytics work — and almost nobody measures it. You cannot manage an adjective.

Why "we did a data quality audit" isn't measurement

Most insurers have done an audit at some point. A consultant profiled the data, produced a deck, and identified issues. Useful once, useless thereafter — because quality decays continuously and an audit is a photograph of something moving.

New products launch with new fields nobody populates. A source system changes. A team stops entering something because a workaround made it optional. Six months after the audit, the picture has drifted and nobody knows by how much.

What you need isn't a report. It's a score, per field, tracked over time, with thresholds that trigger action.

The four dimensions worth scoring

Don't over-engineer this. Four dimensions cover most of what matters:

1. Completeness. What percentage of records have this field populated? The simplest metric and often the most damaging when ignored — a field that's 30% blank quietly breaks every rule and model that depends on it.

2. Validity. Of the populated values, what percentage are actually valid? A construction type of "XX", a year built of 1066, a premium of zero. Populated is not the same as correct, and a plausible-looking wrong value is worse than a blank one.

3. Consistency. Does the same real-world thing have the same representation everywhere? "Frame" vs "FR" vs "Wood Frame" is three risk classes where there's one. Consistency failures are what make cross-system joins produce nonsense.

4. Freshness. How old is this value? A replacement cost from 2019 is technically complete, valid, and consistent — and wrong. Every field should have an implicit or explicit expiry.

Make it per-field, not per-table

This is the design decision that determines whether the score is useful. A table-level score ("claims data is 82% quality") tells you nothing actionable. A field-level score tells you exactly what to fix:

  • property.roof_age — completeness 68%, validity 94%, freshness 2.1 yrs avg
  • customer.email — completeness 91%, validity 88%, consistency 99%
  • claim.cause_code — completeness 99%, validity 71%, consistency 62%

Now the third row jumps out: the field is always populated but the values disagree across systems. That's a specific, fixable problem you would never have seen in an aggregate.

Weight by consequence, not by volume

Not all fields matter equally. A 40% blank rate on a field nobody uses is noise. A 5% blank rate on a field that drives pricing is an emergency.

So weight each field by what depends on it:

  • Critical: feeds pricing, eligibility, or a regulated decision.
  • Important: feeds an operational decision or a customer-facing process.
  • Informational: reporting only.

Your headline score should be dominated by the critical tier. A dashboard that reports 85% overall while a pricing-critical field sits at 60% is actively misleading.

Then set thresholds and act on them

A score nobody acts on is a vanity metric. Wire it to decisions:

  1. Gate model deployment. If a critical input field falls below threshold, that model doesn't ship — or ships with the limitation documented. Make it a gate, not a warning.
  2. Alert on decay. A field that drops five points in a month indicates something upstream broke. That's the early warning you currently don't get.
  3. Feed the roadmap. Your lowest-scoring critical fields are your data-engineering backlog, ranked by consequence. This is a much better prioritisation input than opinion.
  4. Publish it. Data owners behave differently when their domain's score is visible to peers. Not as a punishment — as accountability that was previously impossible because nothing was measured.

Start with twenty fields, not two thousand

The instinct is to score everything. Don't — you'll spend six months building a framework and lose the audience.

Pick the twenty fields that feed your most important decisions, score those four dimensions, track weekly, and put it on one page. You'll learn more in a fortnight than the audit told you, and you'll have something concrete to act on.

The measurement itself changes behaviour. Teams that have never seen a number are usually surprised by it — and surprise is the beginning of doing something.

The point

Every stalled AI project, every disappointing automation rate, every report nobody trusts traces back to data quality nobody quantified. "It's messy" has been the answer for a decade because there was never a number to argue with.

Give the organisation a score, per field, weighted by consequence, tracked over time — and data quality stops being a vague complaint and becomes an engineering problem with a backlog. That's a much better problem to have.

We build the pipelines, quality frameworks, and governed platforms that make data measurable and trustworthy. More at IntelliBooks.

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