Master Data Management in Insurance: Why the Golden Record Stays Tarnished

Every insurer has a slide with a "golden record" on it — the single, authoritative version of a customer, or a policy, or a broker, that every system agrees on. Almost no insurer actually has one. Master data management is the discipline meant to produce it, and in insurance it fails so reliably that the golden record has become a running joke: perpetually funded, perpetually tarnished. It's worth understanding why, because the reasons aren't about tooling.

What master data management actually is

MDM is the practice of creating and maintaining one trusted version of the entities your business runs on — customers, products, brokers, suppliers, locations. Not a report, not a warehouse table: a governed, authoritative record that other systems defer to. When the claims system, the billing system, and the CRM all point at the same customer master, you have MDM. When they each keep their own version and "reconcile" occasionally, you don't.

People confuse this with a data warehouse or a customer-360 dashboard. Those are views — read-only assemblies built after the fact. MDM is upstream of that: it's the governed source the views should be built from. You can have a customer-360 screen sitting on top of no master data at all, which is exactly why so many of them are subtly wrong.

Why insurance breaks it specifically

  • Acquisition sprawl. Insurers grow by acquisition, and each acquired book brings its own systems and its own customer records. The same person now exists five times, and no acquisition ever fully finished merging.
  • Products predate customers. Legacy insurance systems were built around policies, not people. There often is no customer entity at the core — just policies that happen to share a name and address. Retrofitting a customer master onto a policy-centric estate is genuinely hard.
  • The broker channel. If brokers own the relationship, the insurer's customer data is second-hand and incomplete to begin with — you're mastering a shadow.
  • No clear owner. MDM is cross-functional by nature, which means it belongs to everyone and therefore no one. It stalls in governance, not technology.

The failure pattern

The classic MDM program buys a platform, spends a year building match-and-merge rules, produces a golden record — and then it decays, because nothing was fixed at the source. The systems that created the duplicate, inconsistent records keep creating them. The golden record is a snapshot that's already drifting the day it's minted. Six months later it's another tarnished master, and the next reorg proposes a fresh MDM initiative.

What makes it stick

The insurers who succeed treat MDM as an operating commitment, not a project:

  1. Master at the source, or as close as possible. Resolve and de-duplicate as records are created or updated, so the estate stops manufacturing new mess faster than you can clean it.
  2. Entity resolution as a service. One capability that answers "is this the same customer?" — used by onboarding, claims, fraud, and marketing alike, rather than each team resolving identities their own way.
  3. Ownership with teeth. A named owner for each master domain, with authority over definitions and the mandate to reject changes that break them.
  4. Measured decay. Track duplicate rates and match confidence over time. A golden record you don't monitor is a golden record that's already tarnishing.

Notice that none of the hard parts are the matching algorithm — they're source integration, governance, and sustained ownership. That's the pattern across all of insurance's data problems: the value isn't a clever model, it's the unglamorous foundation underneath it. Building that foundation — entity resolution, source-level mastering, lineage, governance that holds — is the work we do with insurers at IntelliBooks.

A golden record isn't something you build once. It's something you maintain, or it quietly turns back into lead.

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