Solution · Finance

KYC and Due Diligence: Building a Corporate Knowledge Graph with Merge

In financial services, knowing your customer means more than checking a box. It means tracing ownership chains across jurisdictions, linking fund managers to portfolio companies, connecting SEC filings to the right legal entities, and doing it all with confidence that "JPMorgan Chase," "JP Morgan," and "JPMorgan Chase & Co." resolve to the same golden record.

This post walks through building a corporate knowledge graph for KYC and due diligence workflows using Merge — from schema design to entity resolution to graph traversal.

Dashboard overview showing entity counts and merge activity

The Problem: Fragmented Corporate Data

Financial institutions ingest corporate data from dozens of sources — CRM systems, vendor feeds, SEC EDGAR filings, news aggregators, internal board records. Each source uses its own naming conventions:

Source	Name Used	Ticker
CRM	JPMorgan Chase	JPM
Vendor Feed	JP Morgan	JPM
SEC Filing	JPMorgan Chase & Co.	JPM
News Feed	Meta	META
Internal DB	Meta Platforms	META
SEC Filing	Alphabet Inc	GOOGL
CRM	Google	GOOGL

Without entity resolution, your compliance team sees seven separate companies instead of three. That means duplicated due diligence, missed risk connections, and incomplete beneficial ownership graphs.

Step 1: Define Entity Schemas

A KYC knowledge graph needs four core entity types: companies, people, funds, and regulatory filings. Each schema defines which attributes drive matching.

# Create the Company schema — stock_ticker is the deterministic identity key
curl -X POST https://merge-mdm.com/v1/schemas \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Company",
    "attributes": [
      {"name": "name", "type": "string", "required": true},
      {"name": "stock_ticker", "type": "string", "identity": true},
      {"name": "industry", "type": "string"},
      {"name": "headquarters", "type": "string"},
      {"name": "incorporation_country", "type": "string"}
    ]
  }'

The identity: true flag on stock_ticker tells Merge that two records sharing the same ticker represent the same real-world entity — a deterministic match that bypasses fuzzy scoring entirely.

# Person schema — fuzzy name matching for executives and board members
curl -X POST https://merge-mdm.com/v1/schemas \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Person",
    "attributes": [
      {"name": "full_name", "type": "string", "required": true},
      {"name": "title", "type": "string"},
      {"name": "nationality", "type": "string"}
    ]
  }'

# Fund schema
curl -X POST https://merge-mdm.com/v1/schemas \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Fund",
    "attributes": [
      {"name": "name", "type": "string", "required": true},
      {"name": "fund_type", "type": "string"},
      {"name": "aum", "type": "string"},
      {"name": "strategy", "type": "string"}
    ]
  }'

# Filing schema — links regulatory documents to entities
curl -X POST https://merge-mdm.com/v1/schemas \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Filing",
    "attributes": [
      {"name": "title", "type": "string", "required": true},
      {"name": "filing_type", "type": "string"},
      {"name": "filing_date", "type": "string"},
      {"name": "jurisdiction", "type": "string"}
    ]
  }'

Schemas configured in Merge

Step 2: Define Relationship Types

Relationships form the edges of the knowledge graph. For financial services KYC, the critical connections are:

# Board membership — links executives to companies
curl -X POST https://merge-mdm.com/v1/relationships \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"relationship_type": "board_member", "from_entity_type": "Person", "to_entity_type": "Company"}'

# Fund management
curl -X POST https://merge-mdm.com/v1/relationships \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"relationship_type": "manages", "from_entity_type": "Person", "to_entity_type": "Fund"}'

# Investment holdings
curl -X POST https://merge-mdm.com/v1/relationships \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"relationship_type": "invested_in", "from_entity_type": "Fund", "to_entity_type": "Company"}'

# Regulatory filings
curl -X POST https://merge-mdm.com/v1/relationships \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"relationship_type": "filed_by", "from_entity_type": "Filing", "to_entity_type": "Company"}'

# Corporate structure
curl -X POST https://merge-mdm.com/v1/relationships \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"relationship_type": "subsidiary_of", "from_entity_type": "Company", "to_entity_type": "Company"}'

Step 3: Ingest Records from Multiple Sources

In production, records flow in from batch uploads, webhooks, and direct API integrations. Here we simulate multi-source ingestion:

# Batch ingest companies from the primary CRM
curl -X POST https://merge-mdm.com/v1/entities/batch \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Company",
    "records": [
      {"name": "JPMorgan Chase", "stock_ticker": "JPM", "industry": "Banking", "headquarters": "New York, NY", "incorporation_country": "US"},
      {"name": "Goldman Sachs", "stock_ticker": "GS", "industry": "Investment Banking", "headquarters": "New York, NY", "incorporation_country": "US"},
      {"name": "Apple", "stock_ticker": "AAPL", "industry": "Technology", "headquarters": "Cupertino, CA", "incorporation_country": "US"},
      {"name": "Microsoft", "stock_ticker": "MSFT", "industry": "Technology", "headquarters": "Redmond, WA", "incorporation_country": "US"},
      {"name": "Berkshire Hathaway", "stock_ticker": "BRK.A", "industry": "Conglomerate", "headquarters": "Omaha, NE", "incorporation_country": "US"},
      {"name": "Tesla", "stock_ticker": "TSLA", "industry": "Automotive", "headquarters": "Austin, TX", "incorporation_country": "US"},
      {"name": "Alphabet", "stock_ticker": "GOOGL", "industry": "Technology", "headquarters": "Mountain View, CA", "incorporation_country": "US"},
      {"name": "Meta Platforms", "stock_ticker": "META", "industry": "Technology", "headquarters": "Menlo Park, CA", "incorporation_country": "US"},
      {"name": "Amazon", "stock_ticker": "AMZN", "industry": "Technology", "headquarters": "Seattle, WA", "incorporation_country": "US"},
      {"name": "Bank of America", "stock_ticker": "BAC", "industry": "Banking", "headquarters": "Charlotte, NC", "incorporation_country": "US"}
    ]
  }'

# Ingest executives with board relationships
curl -X POST https://merge-mdm.com/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Person",
    "attributes": {"full_name": "Jamie Dimon", "title": "Chairman & CEO", "nationality": "US"},
    "relationships": [{"relationship_type": "board_member", "to_entity_id": "ent_7506d03d-..."}],
    "source_system": "board_records"
  }'

Entities list showing ingested records

Step 4: Entity Resolution in Action

Here is where Merge earns its keep. We ingested variant records from different source systems — vendor feeds, SEC filings, news aggregators — and Merge resolved them automatically.

Resolution Results

Test Case	Records Ingested	Resolution	Confidence
"JPMorgan Chase" + "JP Morgan" + "JPMorgan Chase & Co."	3 sources	Auto-merged → single entity	1.0 (identity match on JPM)
"Goldman Sachs" + "Goldman Sachs Group Inc"	2 sources	Auto-merged	1.0 (identity match on GS)
"Meta Platforms" + "Meta"	2 sources	Auto-merged	1.0 (identity match on META)
"Alphabet" + "Alphabet Inc" + "Google"	3 sources	Auto-merged	1.0 (identity match on GOOGL)
"Warren Buffett" (exact duplicate)	3 sources	Auto-merged	0.95
"Elon Musk" + "E. Musk"	2 sources	Auto-merged	0.9 (fuzzy + supporting attrs)

How It Works

Merge uses a multi-signal matching pipeline:

Deterministic matching — Identity attributes (like stock_ticker) provide absolute linkage. Same ticker = same entity, regardless of name variations.
Fuzzy name similarity — For entities without identity keys, Merge computes name similarity using multiple algorithms (Jaro-Winkler, token overlap, initial-last patterns).
Attribute overlap boost — Matching supporting attributes (industry, headquarters, nationality) increase confidence scores.
Confidence thresholds — Scores above 0.9 auto-merge. Scores between 0.7-0.9 go to human review. Below 0.7 creates a new entity.

JPMorgan entity detail showing 3 merged sources

Examining the Merged Entity

# View the golden record
curl https://merge-mdm.com/v1/entities/ent_7506d03d-16d6-41c9-a719-6d82b41def1c \
  -H "X-API-Key: $API_KEY"

Response:

{
  "entity_id": "ent_7506d03d-16d6-41c9-a719-6d82b41def1c",
  "name": "JPMorgan Chase & Co.",
  "entity_type": "Company",
  "source_count": 3,
  "confidence_score": 1.0,
  "attributes": {
    "name": "JPMorgan Chase & Co.",
    "stock_ticker": "JPM",
    "industry": "Financial Services",
    "headquarters": "New York, NY",
    "incorporation_country": "US"
  }
}

# View all source records that resolved into this entity
curl https://merge-mdm.com/v1/entities/ent_7506d03d-16d6-41c9-a719-6d82b41def1c/sources \
  -H "X-API-Key: $API_KEY"

Response:

{
  "sources": [
    {"source_system": "api", "raw": {"name": "JPMorgan Chase", "stock_ticker": "JPM", "industry": "Banking"}},
    {"source_system": "vendor_feed", "raw": {"name": "JP Morgan", "stock_ticker": "JPM", "industry": "Banking"}},
    {"source_system": "sec_filings", "raw": {"name": "JPMorgan Chase & Co.", "stock_ticker": "JPM", "industry": "Financial Services"}}
  ]
}

Step 5: Human-in-the-Loop Review

Not every match is clear-cut. Merge's review queue surfaces ambiguous cases for human decision-making — critical for compliance workflows where false merges carry regulatory risk.

Review queue showing pending merge decisions

In our dataset, Merge flagged two Filing records for review:

"Apple Annual Report FY2024" vs "JPMorgan Chase 10-K Annual Report 2024" (both 10-K filings with SEC jurisdiction — high attribute overlap but different companies)
"Goldman Sachs 10-Q Quarterly Report Q3 2024" vs the same JPMorgan filing

The system correctly identified these as potential matches (shared filing_type and jurisdiction boosted the score to 0.72) but held them for review rather than auto-merging. A compliance analyst rejects both — these are distinct filings from different issuers.

# Reject a false-positive match
curl -X POST https://merge-mdm.com/v1/reviews/ed4f9c0a-5fb5-4f79-9283-374b294ae5c4/reject \
  -H "X-API-Key: $API_KEY"

After rejection, Merge creates a new standalone entity for each filing and learns from the decision.

Reviews resolved — queue cleared

Step 6: Graph Traversal

With entities resolved and relationships established, you can traverse the knowledge graph to answer due diligence questions.

# Who sits on JPMorgan's board?
curl https://merge-mdm.com/v1/entities/ent_7506d03d-16d6-41c9-a719-6d82b41def1c/graph \
  -H "X-API-Key: $API_KEY"

{
  "entity_id": "ent_7506d03d-16d6-41c9-a719-6d82b41def1c",
  "hops": 1,
  "nodes": [
    {"entity_id": "ent_7506d03d-...", "name": "JPMorgan Chase & Co.", "source_count": 3},
    {"entity_id": "ent_693bc2e3-...", "name": "Jamie Dimon"}
  ],
  "edges": [
    {"from": "ent_7506d03d-...", "to": "ent_693bc2e3-...", "type": "board_member"}
  ]
}

Knowledge graph visualization

Search Across the Graph

# Fuzzy search across all entities
curl "https://merge-mdm.com/v1/entities/search?q=JPMorgan" \
  -H "X-API-Key: $API_KEY"

Searching for "JPMorgan" returns the resolved company entity (source_count: 3) and the associated fund — demonstrating that all name variants now point to the same golden record.

Step 7: Analytics and Monitoring

Track resolution quality across your pipeline:

curl https://merge-mdm.com/v1/analytics/summary \
  -H "X-API-Key: $API_KEY"

{
  "creates": 25,
  "merges": 11,
  "pending_reviews": 0,
  "feedback_accepted": 0,
  "feedback_total": 2
}

From 32+ ingested records, Merge produced 25 distinct entities with 11 automatic merges and 2 correctly-flagged reviews. Zero false merges.

Final dashboard with resolution metrics

Tips for Financial Services Entity Resolution

1. Use deterministic keys wherever possible. Stock tickers, LEI codes, CIK numbers, and ISIN codes provide absolute linkage that fuzzy matching cannot. Mark these as identity: true in your schema.

2. Separate entity types with overlapping names. "Berkshire Hathaway" (Company) and "Berkshire Hathaway Equity Portfolio" (Fund) are distinct entities. Schema-level entity typing prevents cross-type false merges.

3. Tune review thresholds for your risk tolerance. In AML/KYC workflows, false merges are worse than false splits. Set a high auto_merge threshold (0.9+) and route ambiguous cases to human review.

4. Tag source systems on every record. When you trace the provenance of a golden record back to "sec_filings" vs "vendor_feed" vs "crm," your compliance team can assess data quality and prioritize authoritative sources.

5. Use relationships to validate merges. If two "person" records share a board_member relationship to the same company, that's a strong signal they represent the same individual — even if fuzzy name similarity is moderate.

6. Leverage the review queue for audit trails. Every accept/reject decision is logged. This creates the defensible audit trail that regulators expect in KYC programs.

7. Ingest filings with specific titles. Generic filing names (e.g., "10-K Annual Report") across different companies can trigger false-positive reviews. Include the issuer name in the filing title to improve differentiation.

Architecture Summary

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  CRM System  │     │  SEC EDGAR   │     │ Vendor Feeds │
└──────┬───────┘     └──────┬───────┘     └──────┬───────┘
       │                     │                     │
       └─────────────────────┼─────────────────────┘
                             ▼
                   ┌─────────────────┐
                   │   Merge API     │
                   │  (merge-mdm.com) │
                   └────────┬────────┘
                            │
              ┌─────────────┼─────────────┐
              ▼             ▼             ▼
     ┌────────────┐  ┌───────────┐  ┌─────────┐
     │  Identity  │  │   Fuzzy   │  │  Graph  │
     │  Matching  │  │  Scoring  │  │  Engine │
     └─────┬──────┘  └─────┬─────┘  └────┬────┘
           │                │              │
           └────────────────┼──────────────┘
                            ▼
                   ┌─────────────────┐
                   │  Golden Records │
                   │  + Knowledge    │
                   │    Graph        │
                   └─────────────────┘

Conclusion

Entity resolution is the foundation of effective KYC and due diligence. Without it, compliance teams spend hours manually cross-referencing records that a deterministic ticker match could resolve in milliseconds.

Merge provides the building blocks — identity-based deterministic matching, fuzzy scoring with configurable thresholds, human-in-the-loop review queues, and graph traversal — to build a corporate knowledge graph that scales with your data.

The result: 3 source records for JPMorgan become 1 golden entity. "E. Musk" and "Elon Musk" resolve automatically. And when the system isn't sure, it asks a human rather than guessing.

That's entity resolution for financial services.

Built with Merge — AI-first entity resolution and knowledge graph platform.

Start free All solutions