Every insurer running a rules-based MDM platform has had some version of the same conversation. A data steward pulls up two records that are obviously the same policyholder — same address, same phone number, one middle initial apart — and asks why the system didn't merge them. The honest answer is usually: because the rule that would have caught this was written for a different source system three years ago, and nobody updated it when the new billing platform went live.
That isn't a bug. It's the design. Rules-based matching assumes the shape of your data is stable enough to write rules against. In insurance, it rarely is.
The shape problem
A typical mid-size carrier resolves customer and party data across a policy admin system, a billing platform, a claims system, an agency management system, and at least one acquired book of business still running on legacy infrastructure. Each source formats names, addresses, and identifiers slightly differently. Each changes independently — a system upgrade here, a new agency integration there — and every change is a small chance for a hand-written matching rule to silently stop working.
Static rules degrade quietly. Nobody gets an alert when a rule stops catching matches it used to catch; the symptom is duplicate records accumulating in the background until someone notices the count is off during an audit.
Why machine-learned resolution doesn't have the same problem
Machine-learned entity resolution doesn't ask "does this record match a pattern I was told to look for." It asks "how similar is this record to that one, across every signal available — name, address, phone, policy number fragments, even typing patterns in free-text fields — weighted by how reliable each signal has been historically." When a source system changes its address format, a similarity model degrades gracefully instead of failing outright, because it was never relying on that one field matching exactly in the first place.
This matters more in insurance than almost any other domain, because the cost of a missed match isn't abstract. A duplicate customer record means a policyholder gets billed twice, an agent can't see a client's full book, or a claims adjuster is missing loss history that should have informed a decision.
What the resolution pipeline actually looks like
Underneath the concept, the mechanics are consistent whether the platform is rules-based or ML-based — records get ingested, compared, scored, and survived into a golden record. What changes is what happens inside the "compare and score" step, and how much manual maintenance that step demands going forward.
What good survivorship logic still requires
Machine-learned matching doesn't remove the need for judgment about which source wins when two records conflict — it changes where that judgment gets applied. Instead of a data steward writing "billing system always wins for address," survivorship becomes a configurable, field-level policy: most recently updated wins for contact fields, system-of-record wins for policy identifiers, highest-confidence source wins for anything else. That policy is visible and auditable, which matters as much to a compliance review as it does to data quality.
The question isn't whether your MDM platform can merge two obviously identical records. It's whether it catches the ones that are identical but don't look like it on paper.
What this means in practice
None of this is an argument that machine learning replaces governance. Survivorship rules, audit trails, and the ability for a data steward to override a decision and see why it was made are still non-negotiable in a regulated industry. What changes is the maintenance burden: instead of a team of analysts periodically rewriting match rules to keep pace with source-system drift, the model absorbs most of that drift automatically, and the team's time goes into reviewing edge cases the model flags as low-confidence — which is a much smaller, much more useful list.
The carriers who feel the cost of this most acutely are usually the ones who've grown by acquisition — every acquired book of business is another source system with its own formatting conventions, and every one of those is another place a static rule quietly stops working. If that sounds familiar, it's usually a sign the matching layer needs to change before the next integration, not after.