Identity Resolution vs MDM

Identity resolution determines which records refer to the same entity. Master Data Management (MDM) governs the lifecycle of that entity data — who can change it, what quality standards it must meet, and how it flows across the organization. Identity resolution is a building block of MDM, not a replacement for it.

This guide explains the relationship between identity resolution and MDM, when you need each, and how modern data teams approach both.

Definitions

Identity Resolution

Identity resolution (also called entity resolution or record linkage) is the technical process of:

1. Matching records across data sources that refer to the same real-world entity
2. Linking those records into clusters
3. Producing a golden record — one canonical record per entity with the best values from each source

The output is a unified view: "These 5 records from 3 systems all describe the same customer."

Master Data Management

MDM is an organizational discipline that includes:

1. Data governance: Policies for who can create, update, and delete master data
2. Data quality: Rules for what constitutes valid, complete, and accurate data
3. Data stewardship: Human workflows for reviewing and approving changes
4. Data distribution: Mechanisms for syncing the golden record back to consuming systems
5. Identity resolution: Matching and linking records (one component of MDM)
6. Lifecycle management: Handling merges, splits, survivorship, and archival

MDM is broader. Identity resolution is one capability within it.

How They Relate

MDM (the discipline)
├── Data Governance (policies, ownership, access control)
├── Data Quality (validation, enrichment, standardization)
├── Identity Resolution ← matching, linking, golden records
├── Data Stewardship (review workflows, exception handling)
├── Data Distribution (sync golden records to consuming systems)
└── Lifecycle Management (merge, split, archive, audit)

You can do identity resolution without MDM — match records, produce golden records, and load them into a warehouse. Many data teams start here.

You cannot do MDM without identity resolution. If you don't know which records refer to the same entity, governance and stewardship are meaningless.

Feature Comparison

Capability	Identity Resolution	MDM
Record matching	Yes (core function)	Yes (delegated to IR engine)
Golden record creation	Yes	Yes
Data governance policies	No	Yes
Stewardship workflows	Limited (review queues)	Yes (full approval chains)
Data quality rules	Basic (normalization)	Comprehensive (validation, enrichment)
Hierarchy management	No	Yes (parent-child, org charts)
Data distribution/sync	No	Yes (publish to consuming systems)
Master data modeling	No (entity-specific)	Yes (customers, products, locations, etc.)
Reference data management	No	Yes
Audit trails	Yes (match decisions)	Yes (full data lineage)
Compliance (GDPR, CCPA)	Partial (find all records for a person)	Full (governance + erasure + consent)

When You Need Identity Resolution Only

Identity resolution without full MDM is the right choice when:

You're solving a specific matching problem

Scenario: Your marketing team has 3 email lists that need to be deduplicated before a campaign. You don't need governance policies or stewardship workflows — you need to match records and produce a clean list.

Solution: Run identity resolution, export the golden records, and use them for the campaign.

You're building a Customer 360 view

Scenario: Your data team wants to join CRM, billing, and support data in the warehouse to create a unified customer view for analytics.

Solution: Use identity resolution to match records across sources and produce golden records. Load them into your warehouse. Analytics teams query the golden records directly.

You're a startup or small team

Scenario: You have 3-5 data sources, a small data team, and no dedicated data governance function. Full MDM is overkill.

Solution: Identity resolution gives you 80% of the value with 20% of the complexity. You can add governance later as the organization matures.

You're embedding resolution in a product

Scenario: You're building a SaaS product that needs to match customer records on behalf of your users (e.g., a CRM, a data integration tool, a fraud detection system).

Solution: Embed an identity resolution engine. You don't need MDM — your product's application layer handles governance and workflows.

When You Need MDM

Full MDM becomes necessary when:

Multiple teams modify the same master data

Scenario: Sales creates customer records. Finance updates billing information. Support adds contact details. Operations manages shipping addresses. Without governance, conflicting updates overwrite each other.

MDM provides: Ownership rules (sales owns name and title, finance owns billing info), approval workflows (changes to billing address require finance approval), and conflict resolution policies.

Regulatory compliance requires full data lineage

Scenario: GDPR requires you to respond to data subject access requests within 30 days. You need to find every record for a person across all systems, provide a complete history of changes, and delete or anonymize on request.

MDM provides: Full audit trails, data lineage tracking, erasure workflows, and consent management.

You manage multiple master data domains

Scenario: Your organization needs to manage not just customer data, but also product data, vendor data, location data, and reference data (country codes, currency codes, industry codes).

MDM provides: A unified platform for modeling, governing, and distributing all master data domains.

Data quality is a strategic initiative

Scenario: Your CEO has declared "data quality" a company-wide priority. You need data quality dashboards, quality scorecards, remediation workflows, and executive reporting.

MDM provides: Data quality rules, profiling, scorecards, and remediation workflows as part of a governed platform.

The Modern Approach: Composable MDM

Traditional MDM platforms (Informatica MDM, IBM InfoSphere, SAP MDG) are monolithic — they handle everything from matching to governance to distribution in a single platform. They typically cost $500K-$2M+ in licensing, take 12-24 months to implement, and require dedicated MDM architects.

The modern approach is composable: assemble MDM capabilities from best-of-breed tools rather than buying a monolith.

MDM Capability	Traditional MDM	Composable Approach
Identity resolution	Built-in (often weak)	Kanoniv, Splink, Senzing
Data quality	Built-in	Great Expectations, Soda, dbt tests
Data governance	Built-in	Atlan, Alation, DataHub
Data catalog	Built-in	Atlan, DataHub, Amundsen
Stewardship workflows	Built-in	Custom (Retool, internal tools)
Data distribution	Built-in	Fivetran, Airbyte, dbt
Master data store	Hub database	Snowflake, BigQuery, Postgres

Advantages of Composable MDM

• Faster time to value: Start with identity resolution (weeks), add governance later (months)
• Lower cost: Free and low-cost components for many capabilities
• Flexibility: Swap components as needs change
• Modern stack: Warehouse-native, git-managed, CI/CD-friendly
• Team autonomy: Data engineers manage matching; data governance teams manage policies

Disadvantages of Composable MDM

• Integration burden: You're responsible for connecting the pieces
• No single vendor support: Multiple vendors to manage
• Potential gaps: Some niche capabilities (hierarchy management, reference data) may require custom development

Identity Resolution as the Foundation

Regardless of whether you adopt full MDM or a composable approach, identity resolution is the foundation. Here's why:

Without identity resolution, governance is incomplete

You can define ownership policies for customer data, but if you can't identify which records represent the same customer, your policies apply to fragments rather than complete entities.

Without identity resolution, data quality is partial

You can validate that email addresses are well-formed, but you can't determine that "[email protected]" and "[email protected]" belong to the same person. Deduplication is a data quality problem that only identity resolution can solve.

Without identity resolution, compliance is risky

GDPR's "right to be forgotten" requires deleting all records for a person. If you haven't resolved identities across systems, you can't know which records to delete.

The practical path

1. Start with identity resolution: Match records, produce golden records, load into your warehouse
2. Add data quality rules: Validate incoming data, flag quality issues
3. Add governance (if needed): Define ownership, approval workflows, audit trails
4. Add distribution (if needed): Sync golden records back to source systems

Most data teams get enormous value from step 1 alone. Steps 2-4 are added as the organization's data maturity grows.

Implementing Identity Resolution with Kanoniv

Kanoniv provides the identity resolution layer of a composable MDM stack:

# customer-spec.yaml
entity:
  name: customer
sources:
  - name: crm
    adapter: csv
    location: salesforce_contacts.csv
    primary_key: id
  - name: billing
    adapter: csv
    location: stripe_customers.csv
    primary_key: id
  - name: support
    adapter: csv
    location: zendesk_users.csv
    primary_key: id
rules:
  - name: email_exact
    type: exact
    field: email
    weight: 1.0
  - name: phone_name
    type: composite
    children:
      - type: exact
        field: phone
      - type: jaro_winkler
        field: name
        threshold: 0.88
  - name: name_address
    type: composite
    children:
      - type: jaro_winkler
        field: name
        threshold: 0.9
      - type: jaro_winkler
        field: address
        threshold: 0.85
survivorship:
  strategy: source_priority
  priority: [crm, billing, support]
decision:
  thresholds:
    match: 0.85
    review: 0.65

from kanoniv import Spec, Source, reconcile, validate

spec = Spec.from_file("customer-spec.yaml")
validate(spec).raise_on_error()

sources = [
    Source.from_csv("crm", "salesforce_contacts.csv"),
    Source.from_csv("billing", "stripe_customers.csv"),
    Source.from_csv("support", "zendesk_users.csv"),
]

result = reconcile(sources, spec)
print(f"Input records: {result.total_input_records}")
print(f"Golden records: {len(result.golden_records)}")
print(f"Merge rate: {result.merge_rate:.1%}")

# Export golden records to warehouse
golden_df = result.to_dataframe()
golden_df.to_csv("golden_customers.csv", index=False)

The spec is version-controlled, testable locally, and deployable to Kanoniv Cloud for production. It integrates with any downstream governance or distribution tool — the golden records are just data.

Frequently Asked Questions

Can identity resolution replace MDM?

For many data teams, yes — identity resolution with golden records solves the core problem (unified customer view) without the overhead of full MDM. If you don't have governance, stewardship, or multi-domain requirements, identity resolution is sufficient.

Is MDM still relevant in the modern data stack?

The capabilities of MDM are still relevant — matching, governance, quality, distribution. The platforms are being replaced by composable tools. Instead of a $1M Informatica license, teams use Kanoniv for matching, dbt for quality, Atlan for governance, and Snowflake as the master data store.

How do I know when I've outgrown identity resolution?

When you start needing: approval workflows for data changes, formal data ownership policies, cross-domain master data (customers + products + vendors), or regulatory-grade audit trails. These are signals that you need governance and stewardship capabilities beyond what identity resolution provides.

Can I use Kanoniv as part of an MDM implementation?

Yes. Kanoniv handles the identity resolution layer — matching, linking, golden records. It integrates with any governance, quality, or distribution tool via standard data formats (CSV, Pandas DataFrames, warehouse tables). Many teams use Kanoniv for matching and Snowflake as the golden record store.

What's the cost difference?

Traditional MDM platforms cost $500K-$2M+ in licensing alone, plus 12-24 months of implementation. Identity resolution with Kanoniv starts free (local SDK) and scales with usage. A composable MDM stack typically costs a fraction of a monolithic platform while providing equivalent or better capabilities for most use cases.