The Duplication Trap | Part 2 of 3 | When your systems use different names for the same entity, resolving the duplicates looks like the ultimate fix. That's the trap: the records line up, but everything connected to them stays invisible. Three posts on why that happens, what it costs, and how to decide with the full picture.
TL;DR
An entity resolution problem happens when different systems describe the same customer, supplier, or product in ways that don’t line up, and nobody can confirm they’re the same. The cost lands in three places: team time, business decisions, and AI. A fourth cost survives even after the records are matched: not knowing which systems, reports, and processes depend on that entity.
In this Article
A compliance analyst opens the next screening alert of the morning. A customer name came close to a match on a sanctions list. They check. The customer is “J. Smith” in onboarding, “Jack Smith” in payments, and a numeric ID in the CRM. It’s the same person, recorded three ways, and the alert is a false alarm. They close it and open the next one.
Nobody will ever see that time in a budget.
That’s what makes an entity resolution problem so expensive. It’s rarely a line item. It gets split across teams, each paying a small share:
- The analyst clears alerts.
- The data engineer reconciles a report that won’t add up.
- The AI team tries to understand why a pilot keeps giving answers that don’t match reality.
For any enterprise entity resolution effort, that dispersion is the real trap. A cost nobody owns is a cost nobody measures. An entity resolution platform can take care of the matching. But the bill starts long before the match, and part of it survives the match. Here’s where it shows up.
Why doesn’t the entity resolution problem show up on any budget?
Because it doesn’t live in one place. An entity resolution problem exists whenever systems can’t agree that two records describe the same real-world entity. Each system works fine on its own terms. The cost appears in the gaps between them.
That’s also why entity resolution and duplication get confused so often. Duplicate records are the part you can count. What you can’t count is everything built on top of them: the report that treats one customer as three, the control that misses a connection, the model trained on three versions of one supplier.
Look closely and the cost settles into three buckets.
Cost 1: Time. What does entity resolution at scale really consume?
The most visible cost of the entity resolution problem is manual work. Every mismatch that no rule catches ends up with a person:
- Someone builds a mapping table between the CRM and billing.
- Someone rewrites an integration because a customer ID changed format upstream.
- Someone spends a week reconciling two reports that should agree and don’t.
At small volumes, that’s friction. Entity resolution at scale turns it into a structural workload. A 1% mismatch rate across 20 million customer records means 200,000 records someone may eventually need to review. Then an acquisition brings in new systems, each with its own IDs, its own naming rules and its own definition of “customer.”
The cost grows fastest in the oldest parts of your stack. When the logic that creates or transforms an entity lives in black box legacy systems nobody can read anymore, tracing where a record comes from becomes an investigation of its own.
Most of that effort never gets logged as entity resolution. It gets logged as delays.
Cost 2: Decisions. What happens when entity resolution fails in AML?
Among entity resolution use cases, banking shows the decision cost most clearly, because entity resolution AML workflows run on it every day. Sanctions and KYC screening compare customer names against watchlists. When the identity behind those names is fragmented, screening fails in two directions:
- Noise. A peer-reviewed study on sanctions screening reports false positive rates above 90% and notes that, in real banking environments, screening often relies heavily on name matching because other identifiers are missing or incomplete. Every false alert is an analyst decision that didn’t need to happen.
- Missed exposure. The same study treats false negatives as the more serious risk, since they let sanctioned parties go undetected. When one client is split across three records, no single record may look risky. The full exposure only becomes visible once the pieces are connected.
The same pattern shows up outside finance:
- A procurement team can’t total its spend with a supplier recorded under four names.
- A credit team sets a limit on one account without seeing the other two.
In each case, the entity resolution problem turns into a decision made on half the picture.
McKinsey’s analysis of AI in KYC and AML lands on a related point: AI can transform these workflows, but only when the foundations for an at-scale rollout are already in place.
Which brings up the third cost.
Cost 3: AI. How does poor entity resolution break graph analysis workflows?
Graph analysis is how many teams look for patterns in business data:
- Fraud rings.
- Money-laundering networks.
- Corporate ownership chains.
Every node in that graph is supposed to represent one real entity. Poor entity resolution breaks that assumption in two ways:
- Split nodes. One entity becomes three nodes. Its connections scatter, and a network that should look like one tight cluster looks like three unrelated records.
- False merges. Two different entities become one node. The graph now shows links that don’t exist, and risk lands on an entity that never earned it.
Graph algorithms trust the nodes they’re given. Centrality, community detection, and path analysis all run on top of whatever identity layer sits underneath. If that layer is wrong, the math stays precise and the answer is still wrong.
That’s how the entity resolution problem reaches AI. Models and agents inherit the same split and merged entities, and they reason from those errors without flagging them. Gartner predicts that organizations will abandon 60% of AI projects unsupported by AI-ready data, and one of its recommendations is to evolve metadata from passive to active. An AI initiative built on entities that don’t line up rarely fails loudly. It stalls.
Across sectors, the entity resolution use cases change, but the shape of the cost stays the same.
| Sector | Where identity splits | Cost that shows up |
|---|---|---|
| Banking | Customers across onboarding, payments, and screening. | Alert queues and hidden exposure. |
| Insurance | Policyholders across policy and claims systems. | Fraud patterns scattered across claims. |
| Media | Rights holders across catalog, contracts, and finance. | Slow royalty reconciliation. |
| Procurement | Suppliers across purchasing and accounts payable. | Spend nobody can total. |
These entity resolution use cases share one more trait. Even when the matching works, a cost remains.
The cost that stays after the match
Say the matching works. Every record describing that customer now points to one confirmed entity. Then someone wants to change the customer ID format, retire an old CRM, or connect the entity to an AI agent. Three questions come back immediately:
- Which applications, tables, and pipelines use this entity today?
- Which reports and processes depend on it, directly or several steps away?
- What breaks if its definition changes tomorrow?
Matching answers none of them. The records are matched, and the structure around the entity is still invisible. This is the fourth cost of the entity resolution problem, and the easiest to miss, because it only appears when something needs to change.
Without that structure, teams fall back on the IT scream test: make the change, wait, and see who complains. It’s the hidden cost of unreadable systems, paid again every time a resolved entity moves.
Why is enterprise entity resolution never finished?
Because the systems never stop changing. New applications go live. Pipelines get rebuilt. An acquisition adds a CRM nobody planned for. A match confirmed in January can drift by June. That’s why mature enterprise entity resolution programs treat matching as an ongoing process, and why treating the entity resolution problem as a one-time project brings the costs back.
Continuous entity resolution keeps identities aligned as new records keep arriving.
The structure around each entity drifts too, and usually faster. A dependency map drawn by hand starts aging the day it’s finished. If identity needs continuous entity resolution, the context around it needs the same thing: a view of the systems that updates as the systems do.
What changes when the structure around every entity is visible
So where does the fourth cost of the entity resolution problem go? Not into a better matching algorithm, and not into another manual inventory that ages within a quarter. It shrinks when the structure around each entity can be read directly from the systems that run it.
That’s the job of a context layer for enterprise IT.
Velorum builds it as a knowledge graph of the technology ecosystem, extracted from:
- Source code.
- Databases.
- APIs.
- Cloud infrastructure.
- BI tools.
The graph maps applications, tables, pipelines, and the dependencies between them.
It’s deterministic: every relationship traces back to real structure, and none is inferred by an LLM. It stays current as systems change. It reads structure and metadata only, never business data, and it runs inside your own infrastructure.
That scope defines the division of labor. An entity resolution platform decides that two customer records describe the same person. Velorum doesn’t match records or read customer data. It shows where the “Customer” entity lives across the CRM, the ERP, and the reporting layer, and what depends on it. It also shows the layers upstream and downstream of that entity, so teams know whether they’re working on the right one before they act. The two work independently, and Velorum builds its graph with or without an entity resolution platform in place.
For the entity resolution problem, that means the three open questions finally get answers from The Velorum Suite:
- Knowledge Documentation shows where the entity lives and how it’s used across the ecosystem.
- Impact System Mapper reveals what breaks before a change to that entity goes live, and which layer the change belongs in.
- Navis answers plain-language questions about the entity’s surroundings in seconds.
Matching tells you which records are the same customer. The context layer tells you what that customer touches, before the next change finds out the hard way.
Final Summary
The entity resolution problem charges in three currencies: analyst time, decisions made on split identities, and AI that inherits the confusion. Matching records lowers that bill. It doesn’t show where a resolved entity lives or what depends on it, so a fourth cost returns with every change. A context layer of the IT ecosystem closes that gap by reading structure, never business data.
Further Questions
Can Velorum reduce false positives in AML screening?
Not directly. Screening matches names and records, business data Velorum never reads. Velorum maps the structure around it: which systems feed screening, where customer entities live, and which pipelines transform them. In high-risk sectors, that shows how scattered your customer and employee data is, sensitive fields included, without exposing the values. Teams can trace where a split identity originates before fixing it.
What does the context layer of the IT ecosystem reveal about an entity that's already resolved?
Its full footprint: every application, table, pipeline, and report that uses it. Velorum builds that context layer deterministically from code, schemas, configurations, and metadata, so each relationship traces back to a real source. Teams can then change an ID format, retire a legacy system, or feed the entity to an AI agent knowing the blast radius in advance, instead of discovering it in production.
How can AI agents get the context a resolved entity record leaves out?
A resolved record confirms which records belong together, not what surrounds them, and that gap is where the entity resolution problem follows AI into production. Velorum exposes its knowledge graph to agents through MCP, so dependencies and connected systems are available upfront. Agents spend less effort exploring and rediscovering structure, and their answers stay traceable to how the systems are actually built.
