> For the complete documentation index, see [llms.txt](https://docs.zingg.ai/zingg/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zingg.ai/zingg/entity-resolution.md).
# Entity Resolution
What entity resolution is, why the problem is hard to solve at scale, and how Zingg handles each part of it systematically.
Entity resolution is the process of identifying that multiple records across different systems represent the same real-world entity.
It answers one question: Given fragmented, inconsistent data spread across sales,\
marketing, support, and operations systems, whose records actually belong to the same\
customer, supplier, patient, or product?
This question is harder than it looks. The records do not share a common key. The same person appears as "Jon Smith" in your CRM, "Jonathan Smith" in your billing system, and "J. Smith" with a different address in your support platform. No field is wrong. No field is complete. And your downstream systems like decisioning, analytics, compliance, and AI agents are making decisions on all three records as if they were three different people.
### Why this problem exists
Fragmented entity data is a structural consequence of how enterprise software is built. Each application owns its own records and its own identity model. There is no cross-system agreement on how to represent a person, a company, or a location.
Four forces drive the fragmentation:
* **Systems are built independently:** CRMs, billing platforms, ERP systems, and support tools each have their own customer or entity schema. A customer acquired through a marketing campaign enters the CRM. The same customer's invoice enters the billing system. Their support ticket enters a helpdesk. No system knows about the others. Each creates its own record.
* **Data entry is inconsistent:** Name abbreviations, spelling variations, transposed date formats, address shorthand—these are not data quality failures. They are the natural output of humans entering data under time pressure across different interfaces. "IBM" and "International Business Machines" are the same company. "Dr. A. Sharma" and "Anita Sharma" may be the same person. No rule-based system can enumerate all the ways real data varies.
* **Records change over time:** People move. Companies merge. Names change after marriage or acquisition. A customer record that was accurate two years ago now has a different address, a different email, and a different phone number—and it still needs to resolve to the same entity in your identity graph.
* **Scale makes manual resolution impossible:** At a few thousand records, you can resolve entities manually or with simple rules. With one million records, naive comparison necessitates evaluating 500 billion record pairs before making a single match decision. At ten million records, the number is 50 trillion.
No rules engine can scale to this. No team can review it manually. The problem requires a system that learns and one that reduces the comparison space before it starts.
### Where teams use entity resolution
Entity resolution is not a customer data problem. It is an entity data problem. Any time a real-world object, a person, organisation, location, product, or asset appears under different representations across systems, entity resolution is the mechanism that unifies it.
Customer 360
Modern enterprises run on specialised applications, CRM, e-commerce, support,\
loyalty, and finance. Each system holds a partial view of the customer.
The goal of Customer 360 is not to delete duplicate records. It is to bring all interactions and data points for a customer together so you can understand the complete journey, enable accurate segmentation, and power downstream AI agents with a unified view.
Entity resolution is the step that makes such a scenario possible. Without it, every downstream model, campaign, and agent is working from a fragmented picture.
Master Data Management (MDM)
MDM is the discipline of creating and maintaining a single authoritative record, a golden record for each core business entity: customer, supplier, product, location, and employee.
Entity resolution is the part of every MDM system that finds out which records from different source systems are for the same entity before the golden record is created.
Zingg Community is a DIY MDM. You build the golden record layer on top of Zingg's match output in your data store of choice.
Zingg Enterprise is a warehouse-native MDM that uses `Zingg ID`s, has incremental updates, and supports survivorship, providing the complete identity infrastructure stack without needing a separate MDM platform.
Composable CDPs
A composable CDP is a customer data platform built from modular components on your existing data stack, rather than a monolithic vendor platform.
Entity resolution is the identity layer in a composable CDP architecture. Zingg resolves customer identities across all source systems and produces a persistent Zingg ID that becomes the customer identifier for the rest of the stack segmentation, activation,\
personalization, and AI agents.
Because Zingg runs inside your warehouse, it fits natively into Databricks, Fabric, or Snowflake-based composable architectures without a separate data movement layer.
Knowledge Bases and Graph RAG
Large language models and retrieval-augmented generation (RAG) pipelines retrieve knowledge from structured data sources. When those sources contain fragmented, inconsistent entity representations, the retrieval layer returns incomplete or conflicting\
context, and the LLM gives wrong or incomplete answers.
Entity resolution is the pre-processing step that unifies entity representations before they reach the knowledge base or vector store. Zingg clusters all records representing the same entity and assigns a single `Zingg ID`. The retrieval layer then finds all of them\
together, and the LLM reasons over a complete, entity-aware view.
This process is the Identity RAG pattern entity resolution as infrastructure for AI accuracy.
{% hint style="success" icon="right-long" %}
**Read more**: [Enhancing LLM applications with Zingg and LangChain](/zingg/recipes-and-integration/identity-rag-with-zingg-and-langchain.md)
{% endhint %}
Fraud Detection
Fraudulent actors create multiple accounts or profiles with small variations in identity fields to evade detection—different email formats, transposed date of birth, and slight name variations.
Entity resolution identifies when records that look different actually belong to the same entity, surfacing hidden connections that threshold-based or rule-based systems miss.
Zingg's probabilistic matching is calibrated to detect these deliberate variations without generating false positives on legitimate name differences.
KYC and AML
Know Your Customer and Anti-Money Laundering workflows require matching incoming data against existing records, sanctions lists, and watchlists, often across inconsistent name formats, transliterations, and missing fields.
Entity resolution handles these variations systematically, reducing false positives and ensuring compliance teams review the right cases rather than being overwhelmed by noise.
Zingg Enterprise's deterministic matching adds a hard-rule layer for trusted identifiers alongside probabilistic matching, which is exactly the combination KYC and AML workflows require: fuzzy matching for variations, exact matching for confirmed identifiers.
### Frequently Asked Questions
Is entity resolution the same as deduplication?
No, and this distinction matters. Deduplication removes exact or near-exact duplicate records within a single system. It is a special case of entity resolution where the\
Variations are minimal, and the scope is limited to a single dataset.
Entity resolution goes further. It identifies records that represent the same real-world entity even when they look significantly different, with variations in spelling, missing fields, different formats and across completely separate systems.
"John Smith" in the CRM, "J. Smith" in the billing tool, and "Jonathan Smith" in the support platform may be the same person. Deduplication would not catch this. Entity\
resolution does.
Zingg's commercial use cases, Customer 360, fraud, KYC, AML, MDM all require full entity resolution. This is why Zingg is positioned around entity resolution and identity\
resolution, not data deduplication.
Can I do entity resolution with a graph database alone?
Not if your data has fuzzy variation. Graph databases like Neo4j are excellent at representing and querying relationships between resolved entities. But they rely on trusted, high-quality identifiers like passport IDs, tax numbers, and exact match keys to define edges between records. When your data has typos, abbreviations, missing fields, or format variations, you cannot define those edges reliably without fuzzy matching first.
Zingg and graph databases work best together. Zingg does entity resolution, which means it finds out which records are for the same entity using ML-based probabilistic and deterministic matching. The graph database is used for downstream relationship analysis and inference in AML, KYC, Knowledge Graph, and Customer 360 scenarios.
{% hint style="success" icon="right-long" %}
**Read more**: [Connect graph databases](/zingg/connect-your-data/connect-graph-databases-neo4j.md)
{% endhint %}
{% hint style="success" icon="right-long" %}
Ready to see entity resolution in action?
* [Run Zingg on your local machine](/zingg/running-zingg/quick-start-docker.md) - full workflow in 30 minutes
{% endhint %}
{% hint style="warning" icon="right-long" %}
Need entity resolution at production scale with persistent identity and incremental\
processing?
* [Talk to us about Enterprise](https://www.zingg.ai/company/contact/contact)
* [Community vs Enterprise](/zingg/community-and-enterprise-editions/community-vs-enterprise.md)
{% endhint %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.zingg.ai/zingg/entity-resolution.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.