Merge

Solution · Finance

Agentic AI Master Data Management for Finance & KYC with Merge: From Fragmented Market Data to Clean Golden Records

How identity-based resolution, agentic AI matching, and graph traversal turn fragmented financial data into a unified master data platform for compliance, trading, and risk management.

Dashboard showing entity resolution analytics with creates and merges

The Multi-Source Finance Data Problem

Every financial institution deals with the same entity fragmentation nightmare. The same company appears across SEC filings as "JPMorgan Chase & Co.", Bloomberg terminals show "JPMorgan Chase", Reuters feeds transmit "JP Morgan", and trading platforms reference ticker symbol "JPM". They are all the same entity, but your compliance database does not know that.

Multiply this across thousands of counterparties, fund managers, beneficial owners, and regulatory filings, and you are staring at a KYC (Know Your Customer) crisis. Regulators demand a single view of each entity. Risk teams need to trace exposure through fund holdings. Compliance officers must connect people to companies to filings without gaps.

Traditional approaches fall apart:

  • Manual reconciliation does not scale when you process thousands of filings per quarter
  • Exact-match deduplication misses "Goldman Sachs" vs "Goldman Sachs Group Inc"
  • Simple string similarity cannot distinguish "Meta" the social media company from a hypothetical "Meta Capital" hedge fund
  • Rigid ETL pipelines break every time a new data vendor uses a different name format

This is the problem Merge solves. In this post, we walk through building a complete finance and KYC master data graph that:

  • Ingests company records from Bloomberg, Reuters, SEC, and NASDAQ with different naming conventions
  • Automatically merges records that share a verified market identifier (stock ticker)
  • Uses agentic AI to evaluate uncertain matches and route ambiguous cases for human review
  • Creates a traversable relationship graph connecting people, companies, funds, and filings
  • Handles typo-tolerant search for real-time entity lookups

By the end, you will see how multiple source records with conflicting names become clean golden entities connected by a rich relationship graph, with full lineage back to every original source.

Schema Design: The Foundation of Financial Entity Resolution

Before ingesting any data, we define what our entities look like and how to resolve duplicates. The critical concept is the identity attribute — a field marked with identity: true that triggers deterministic auto-merge when values match exactly.

In financial markets, the stock ticker is the definitive identifier. When Bloomberg says "JPMorgan Chase" with ticker JPM and Reuters says "JP Morgan" with ticker JPM, there is no ambiguity. Same ticker, same company, period.

Entity Schemas

We define four entity types. The Company schema includes the identity attribute:

# Create the Company schema with stock_ticker as identity key
curl -X POST https://merge-ai.app/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" }
    ]
  }'

The stock_ticker field with identity: true tells Merge: "If two Company records share the same ticker value, they are definitively the same entity. Merge them automatically, no questions asked."

# Person schema — no identity key, relies on AI matching
curl -X POST https://merge-ai.app/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 — tracks investment vehicles
curl -X POST https://merge-ai.app/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 — regulatory documents
curl -X POST https://merge-ai.app/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" }
    ]
  }'

Schema list showing Company with identity:true on stock_ticker

Why Stock Ticker as Identity

In capital markets, the stock ticker is the universal language. Every data vendor, every exchange, every regulator references the same ticker symbols. When three different sources all say "JPM", there is zero ambiguity about which entity they mean.

This makes ticker the perfect identity key:

Property Why It Works
Universal Every data vendor uses the same ticker symbols
Stable Tickers rarely change (and changes are well-documented)
Unambiguous One ticker maps to exactly one listed entity
Machine-readable No formatting variations, no abbreviation issues
Verifiable Can be validated against exchange reference data

The identity configuration tells Merge to treat matching tickers as absolute proof of entity equivalence:

{
  "name": "stock_ticker",
  "type": "string",
  "identity": true,
  "weight": 1,
  "resolution_role": "deterministic",
  "matching_strategy": "exact"
}

For entities without a universal identifier (People, Funds, Filings), Merge falls back to its agentic AI matching layer, which evaluates name similarity, shared attributes, and contextual signals to determine whether records represent the same real-world entity.

Relationships: Connecting Financial Entities

Individual entities are useful, but the real power of a master data graph comes from relationships. In finance, the connections between people, companies, funds, and filings tell the compliance story:

  • Who sits on which board? (Person → Company)
  • Who manages which fund? (Person → Fund)
  • Where does a fund invest? (Fund → Company)
  • Which filings belong to which company? (Filing → Company)
# Person is a board_member of Company
curl -X POST https://merge-ai.app/v1/relationships \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "board_member",
    "from_type": "Person",
    "to_type": "Company"
  }'

# Person manages Fund
curl -X POST https://merge-ai.app/v1/relationships \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "manages",
    "from_type": "Person",
    "to_type": "Fund"
  }'

# Fund invested_in Company
curl -X POST https://merge-ai.app/v1/relationships \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "invested_in",
    "from_type": "Fund",
    "to_type": "Company"
  }'

# Filing filed_by Company
curl -X POST https://merge-ai.app/v1/relationships \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "filed_by",
    "from_type": "Filing",
    "to_type": "Company"
  }'

These four relationship types create a multi-hop traversable graph:

Person ──board_member──> Company <──invested_in── Fund
  │                        ↑                       ↑
  └───manages───> Fund ────┘                       │
                                                   │
Filing ──filed_by──> Company <──invested_in── Fund

A single 3-hop query from Warren Buffett reveals: Berkshire Hathaway (board), Berkshire Hathaway Fund (manages), Apple and JPMorgan (invested), Tim Cook and Jamie Dimon (their boards), Vanguard (also invested in Apple), and regulatory filings. The entire financial constellation from one starting node.

Loading Data: Ingesting Multi-Source Financial Records

Now the real work begins. We load records from multiple authoritative sources, each representing how different data providers format the same information.

Companies with Stock Tickers

# Bloomberg terminal feed
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Company",
    "source_system": "bloomberg",
    "attributes": {
      "name": "JPMorgan Chase",
      "stock_ticker": "JPM",
      "industry": "Banking",
      "headquarters": "New York"
    }
  }'

curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Company",
    "source_system": "bloomberg",
    "attributes": {
      "name": "Goldman Sachs",
      "stock_ticker": "GS",
      "industry": "Investment Banking",
      "headquarters": "New York"
    }
  }'

curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Company",
    "source_system": "nasdaq",
    "attributes": {
      "name": "Apple Inc",
      "stock_ticker": "AAPL",
      "industry": "Technology",
      "headquarters": "Cupertino"
    }
  }'

curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Company",
    "source_system": "nasdaq",
    "attributes": {
      "name": "Microsoft Corporation",
      "stock_ticker": "MSFT",
      "industry": "Technology",
      "headquarters": "Redmond"
    }
  }'

curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Company",
    "source_system": "nasdaq",
    "attributes": {
      "name": "Tesla Inc",
      "stock_ticker": "TSLA",
      "industry": "Automotive",
      "headquarters": "Austin"
    }
  }'

curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Company",
    "source_system": "sec",
    "attributes": {
      "name": "Berkshire Hathaway",
      "stock_ticker": "BRK",
      "industry": "Conglomerate",
      "headquarters": "Omaha"
    }
  }'

People with Board Relationships

Once companies are indexed, we ingest people with board_member relationships pointing to the company entity IDs:

# Jamie Dimon — CEO of JPMorgan
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Person",
    "source_system": "sec",
    "attributes": {
      "full_name": "Jamie Dimon",
      "title": "CEO",
      "nationality": "American"
    },
    "relationships": [
      { "relationship_type": "board_member", "to_entity_id": "<jpmorgan_entity_id>" }
    ]
  }'

# Warren Buffett — CEO & Chairman of Berkshire Hathaway
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Person",
    "source_system": "sec",
    "attributes": {
      "full_name": "Warren Buffett",
      "title": "CEO & Chairman",
      "nationality": "American"
    },
    "relationships": [
      { "relationship_type": "board_member", "to_entity_id": "<berkshire_entity_id>" }
    ]
  }'

# Tim Cook — CEO of Apple
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Person",
    "source_system": "sec",
    "attributes": {
      "full_name": "Tim Cook",
      "title": "CEO",
      "nationality": "American"
    },
    "relationships": [
      { "relationship_type": "board_member", "to_entity_id": "<apple_entity_id>" }
    ]
  }'

# Elon Musk — CEO of Tesla
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Person",
    "source_system": "sec",
    "attributes": {
      "full_name": "Elon Musk",
      "title": "CEO",
      "nationality": "American"
    },
    "relationships": [
      { "relationship_type": "board_member", "to_entity_id": "<tesla_entity_id>" }
    ]
  }'

Funds with Investment Relationships

Funds connect people to companies through investment chains:

# Berkshire Hathaway Fund — managed by Buffett, invested in Apple + JPMorgan
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Fund",
    "source_system": "sec",
    "attributes": {
      "name": "Berkshire Hathaway Fund",
      "fund_type": "Conglomerate",
      "aum": "$785B",
      "strategy": "Value Investing"
    },
    "relationships": [
      { "relationship_type": "invested_in", "to_entity_id": "<apple_entity_id>" },
      { "relationship_type": "invested_in", "to_entity_id": "<jpmorgan_entity_id>" }
    ]
  }'

# Vanguard Total Market Fund — invested in Apple, Microsoft, Tesla
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Fund",
    "source_system": "sec",
    "attributes": {
      "name": "Vanguard Total Market Fund",
      "fund_type": "Index Fund",
      "aum": "$1.3T",
      "strategy": "Passive Index"
    },
    "relationships": [
      { "relationship_type": "invested_in", "to_entity_id": "<apple_entity_id>" },
      { "relationship_type": "invested_in", "to_entity_id": "<microsoft_entity_id>" },
      { "relationship_type": "invested_in", "to_entity_id": "<tesla_entity_id>" }
    ]
  }'

Then we connect Buffett as fund manager:

# Buffett manages Berkshire Fund (re-ingest with manages relationship)
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Person",
    "source_system": "bloomberg",
    "attributes": {
      "full_name": "Warren Buffett",
      "title": "CEO & Chairman",
      "nationality": "American"
    },
    "relationships": [
      { "relationship_type": "manages", "to_entity_id": "<berkshire_fund_entity_id>" }
    ]
  }'

Regulatory Filings

# Apple 10-K filing
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Filing",
    "source_system": "sec",
    "attributes": {
      "title": "Annual Report 10-K 2024",
      "filing_type": "10-K",
      "filing_date": "2024-10-30",
      "jurisdiction": "United States"
    },
    "relationships": [
      { "relationship_type": "filed_by", "to_entity_id": "<apple_entity_id>" }
    ]
  }'

# JPMorgan Annual Report
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Filing",
    "source_system": "sec",
    "attributes": {
      "title": "Annual Report 2024",
      "filing_type": "Annual",
      "filing_date": "2024-02-15",
      "jurisdiction": "United States"
    },
    "relationships": [
      { "relationship_type": "filed_by", "to_entity_id": "<jpmorgan_entity_id>" }
    ]
  }'

Entity list showing all ingested records across multiple types

Identity-Based Auto-Merge: The JPMorgan Case Study

Here is where Merge's resolution engine demonstrates its value for financial data. After ingesting "JPMorgan Chase" from Bloomberg with ticker JPM, we simulate what happens when the same entity arrives from Reuters and SEC filings under different names.

Ingesting Duplicate Records from Different Sources

# Reuters feed — calls it "JP Morgan" (no "Chase", no "& Co.")
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Company",
    "source_system": "reuters",
    "attributes": {
      "name": "JP Morgan",
      "stock_ticker": "JPM",
      "industry": "Banking",
      "headquarters": "New York"
    }
  }'

# SEC filing — uses the full legal name
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Company",
    "source_system": "sec",
    "attributes": {
      "name": "JPMorgan Chase & Co.",
      "stock_ticker": "JPM",
      "industry": "Financial Services",
      "headquarters": "New York, NY"
    }
  }'

What Merge Resolved Automatically

Both records carry stock_ticker: "JPM". Because the Company schema marks stock_ticker with identity: true, Merge immediately recognized these as the same entity and merged them. No AI evaluation needed. No human review required. No delay.

The golden entity now contains three source records, each preserving its original data for full audit lineage:

# Check JPMorgan's source records after identity merge
curl https://merge-ai.app/v1/entities/ent_60ca71a0-4359-4d59-8ee6-e9b10337e931/sources \
  -H "X-API-Key: $API_KEY"

Response showing 3 merged sources from different vendors:

{
  "sources": [
    {
      "source_system": "bloomberg",
      "raw": "{\"name\":\"JPMorgan Chase\",\"stock_ticker\":\"JPM\",\"industry\":\"Banking\",\"headquarters\":\"New York\"}"
    },
    {
      "source_system": "reuters",
      "raw": "{\"name\":\"JP Morgan\",\"stock_ticker\":\"JPM\",\"industry\":\"Banking\",\"headquarters\":\"New York\"}"
    },
    {
      "source_system": "sec",
      "raw": "{\"name\":\"JPMorgan Chase & Co.\",\"stock_ticker\":\"JPM\",\"industry\":\"Financial Services\",\"headquarters\":\"New York, NY\"}"
    }
  ]
}

JPMorgan entity detail showing merged sources from bloomberg, reuters, and sec

The Resolution Flow for JPMorgan

Here is how each record was processed:

Source Company Name Ticker Resolution Path
bloomberg JPMorgan Chase JPM Created new entity
reuters JP Morgan JPM Identity match on ticker → auto-merged
sec JPMorgan Chase & Co. JPM Identity match on ticker → auto-merged

Three records from three authoritative sources. Three completely different name formats. One golden entity. Zero manual intervention.

The key insight: the name differences ("JPMorgan Chase" vs "JP Morgan" vs "JPMorgan Chase & Co.") are completely irrelevant when the identity key matches. The ticker JPM is the source of truth. This is why choosing the right identity attribute matters so much in schema design.

Why This Matters for KYC

In a KYC workflow, you need to answer: "Is this the same legal entity we already have on file?" When a new counterparty application arrives referencing "JP Morgan" and your system already has "JPMorgan Chase & Co.", the identity merge gives you an instant, deterministic answer. No waiting for manual review. No risk of creating a duplicate customer record. No compliance gaps.

Agentic AI Matching: When Identity Is Not Enough

Not every record arrives with a clean stock ticker. Private companies have no ticker. People have no universal financial identifier. Fund names vary between databases. For these cases, Merge's agentic AI evaluator steps in, computing similarity signals across multiple dimensions.

Test Cases for AI Matching

We ingest four records without identity keys to test the AI layer:

# Test 1: "Goldman Sachs Group Inc" — should match existing "Goldman Sachs"
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Company",
    "source_system": "reuters",
    "attributes": {
      "name": "Goldman Sachs Group Inc",
      "industry": "Investment Banking",
      "headquarters": "New York"
    }
  }'

# Test 2: "E. Musk" — abbreviated name, should match "Elon Musk"
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Person",
    "source_system": "news-wire",
    "attributes": {
      "full_name": "E. Musk",
      "title": "CEO",
      "nationality": "American"
    }
  }'

# Test 3: "Meta" — new company, no existing match
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Company",
    "source_system": "nasdaq",
    "attributes": {
      "name": "Meta",
      "industry": "Technology",
      "headquarters": "Menlo Park"
    }
  }'

# Test 4: "Meta Platforms" — should match "Meta" above
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Company",
    "source_system": "reuters",
    "attributes": {
      "name": "Meta Platforms",
      "industry": "Social Media",
      "headquarters": "Menlo Park"
    }
  }'

What the AI Decided

After processing, the agentic AI produced these outcomes:

Goldman Sachs Group Inc → Auto-merged (high confidence)

The AI evaluated "Goldman Sachs Group Inc" against existing entities and found "Goldman Sachs" with matching industry and headquarters. The name similarity was high enough (it is literally the same name with "Group Inc" appended) that the system auto-merged with high confidence. No human review needed.

{
  "entity_id": "ent_2c961383-10e2-4c1b-abd2-ef6696b404dd",
  "name": "Goldman Sachs Group Inc",
  "source_count": 2,
  "confidence_score": 0.95
}

Goldman Sachs entity showing 2 sources after AI auto-merge

E. Musk → Auto-merged (high confidence)

The AI matched "E. Musk" with "Elon Musk" based on:

  • Name pattern: "E." is a common first-initial abbreviation of "Elon"
  • Same title: both "CEO"
  • Same nationality: both "American"
  • Same entity type: both Person
  • No conflicting attributes

The combination of signals pushed confidence above the auto-merge threshold.

Meta + Meta Platforms → Auto-merged (high confidence)

These two records arrived within seconds of each other. The AI recognized:

  • "Meta" is a substring of "Meta Platforms"
  • Same headquarters: Menlo Park
  • Compatible industries: Technology / Social Media
  • No conflicting attributes

Result: merged into a single entity with 2 sources.

Reviews page showing resolution decisions

When the AI Routes to Human Review

In our test run, the AI handled all cases with high confidence. But consider what would happen with a more ambiguous record:

# Hypothetical: "J. Dimon" from an obscure data source
curl -X POST https://merge-ai.app/v1/entities \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "Person",
    "source_system": "trade-journal",
    "attributes": {
      "full_name": "J. Dimon",
      "title": "Executive",
      "nationality": "American"
    }
  }'

The AI would evaluate:

  • Name similarity: "J. Dimon" vs "Jamie Dimon" — moderate match (initial + surname)
  • Title concordance: "Executive" vs "CEO" — compatible but not exact
  • Nationality: match
  • Confidence: likely in the 60-80% range

This falls in the review zone. The system would create a pending review for a human analyst to confirm or reject, rather than risking a false merge on an important compliance record.

The Three-Tier Resolution Strategy

┌─────────────────────────────────────────────────────────────┐
│  Tier 1: Deterministic (Identity Match)                     │
│  stock_ticker exact match → instant auto-merge              │
│  Speed: <1ms | Confidence: 100%                            │
├─────────────────────────────────────────────────────────────┤
│  Tier 2: Agentic AI High-Confidence                         │
│  Multi-signal evaluation → auto-merge                       │
│  Speed: ~50ms | Confidence: >85%                           │
├─────────────────────────────────────────────────────────────┤
│  Tier 3: Agentic AI Review Required                         │
│  Uncertain match → human review queue                       │
│  Speed: human-dependent | Confidence: 50-85%               │
└─────────────────────────────────────────────────────────────┘

For financial entities, this tiered approach means:

  • Listed companies with tickers: always Tier 1 (instant, deterministic)
  • Private companies with similar names: usually Tier 2 (AI handles naming variants)
  • Abbreviated names or sparse records: Tier 3 (human review for compliance safety)

Force Merge: Manual Override for Known Duplicates

Sometimes you discover duplicates that the automated system has not caught — perhaps because they lack shared identifiers and the name similarity falls below the auto-merge threshold. Merge provides a force-merge API for these cases.

In our dataset, the AI successfully merged "Meta" and "Meta Platforms" automatically. But consider a real-world scenario where a compliance officer identifies two entity records that the system kept separate:

# Force merge: absorb entity B into entity A
curl -X POST https://merge-ai.app/v1/entities/{entity_A_id}/merge/{entity_B_id} \
  -H "X-API-Key: $API_KEY"

{
  "from": "ent_entity_B_id",
  "merged_into": "ent_entity_A_id",
  "status": "queued"
}

The merge is queued and processed asynchronously. After completion:

  • The surviving entity absorbs all source records from the merged entity
  • All relationships from both entities are preserved on the survivor
  • The old entity ID redirects to the new one (no broken references)
  • Full audit trail is maintained for compliance

Force merge is the safety valve for cases where human expertise exceeds what automation can determine. In a regulated environment, this is essential: compliance officers must have the ability to override automated decisions when they possess knowledge the system does not.

Relationship Traversal: Mapping the Financial Network

With entities resolved and relationships established, we can traverse the master data graph. This is where entity resolution transforms from a data quality exercise into a strategic compliance and risk tool.

Buffett's Financial Network (3 Hops)

curl "https://merge-ai.app/v1/entities/ent_041999df/graph?hops=3" \
  -H "X-API-Key: $API_KEY"

Starting from Warren Buffett and traversing outward three relationship edges:

Hop 1 — Direct connections:

  • Berkshire Hathaway (board_member)
  • Berkshire Hathaway Fund (manages)

Hop 2 — One step removed:

  • Apple Inc (Berkshire Fund → invested_in)
  • JPMorgan Chase & Co. (Berkshire Fund → invested_in)

Hop 3 — Two steps removed:

  • Tim Cook (Apple → board_member)
  • Jamie Dimon (JPMorgan → board_member)
  • Vanguard Total Market Fund (also invested_in Apple)
  • Annual Report 2024 (filed_by JPMorgan)
  • Annual Report 10-K 2024 (filed_by Apple)

The full graph: 9 nodes, 13 edges — a comprehensive view of Buffett's financial network through just three relationship hops.

Buffett 3-hop graph visualization showing connections to Apple, JPMorgan, and executives

Graph Structure: Buffett's Network

Warren Buffett
├── board_member → Berkshire Hathaway
├── manages → Berkshire Hathaway Fund
│   ├── invested_in → Apple Inc
│   │   ├── board_member → Tim Cook
│   │   ├── invested_in ← Vanguard Total Market Fund
│   │   └── filed_by ← Annual Report 10-K 2024
│   └── invested_in → JPMorgan Chase & Co.
│       ├── board_member → Jamie Dimon
│       ├── invested_in ← Berkshire Hathaway Fund (circular)
│       └── filed_by ← Annual Report 2024

JPMorgan's Network (3 Hops)

curl "https://merge-ai.app/v1/entities/ent_60ca71a0/graph?hops=3" \
  -H "X-API-Key: $API_KEY"

From JPMorgan Chase & Co., 3 hops reveals 9 nodes and 15 edges:

  • Jamie Dimon (board_member)
  • Berkshire Hathaway Fund (invested_in JPMorgan)
  • Warren Buffett (manages Berkshire Fund)
  • Berkshire Hathaway (Buffett board_member)
  • Apple Inc (Berkshire Fund also invested_in)
  • Tim Cook (Apple board_member)
  • Vanguard Total Market Fund (invested_in Apple)
  • Annual Report 2024 (filed_by JPMorgan)

JPMorgan 3-hop graph showing connections to funds, executives, and filings

Why Multi-Hop Matters for Compliance

These graph traversals answer critical regulatory questions:

Question Graph Query
"What is Buffett's indirect exposure to JPMorgan?" Buffett → manages → Berkshire Fund → invested_in → JPMorgan
"Which executives share a common investor?" Tim Cook ← Apple ← Berkshire Fund → JPMorgan → Jamie Dimon
"What filings relate to entities in Buffett's network?" Buffett → Fund → Company → Filing
"Which funds have overlapping holdings?" Berkshire Fund → Apple ← Vanguard

In traditional KYC systems, answering these questions requires joining across multiple databases, each with different schemas, IDs, and name formats. With Merge, it is a single API call with ?hops=3.

Search: Typo Tolerance and Entity Lookup

Financial analysts do not always type entity names perfectly. Merge's search handles the messiness of real-world queries — misspellings, partial names, abbreviated forms — while always returning the clean, resolved golden entity.

Clean Search: "JPMorgan"

curl "https://merge-ai.app/v1/entities/search?q=JPMorgan" \
  -H "X-API-Key: $API_KEY"

{
  "results": [
    {
      "entity_id": "ent_60ca71a0-4359-4d59-8ee6-e9b10337e931",
      "score": 1,
      "source": {
        "entity_type": "Company",
        "name": "JPMorgan Chase & Co.",
        "source_count": 6,
        "attributes": {
          "name": "JPMorgan Chase & Co.",
          "stock_ticker": "JPM",
          "industry": "Financial Services",
          "headquarters": "New York, NY"
        }
      },
      "match_signals": ["lexical"]
    }
  ]
}

Note: even though we searched "JPMorgan" (the Bloomberg format), we get back the resolved golden entity with all 6 source records unified. The original names ("JP Morgan", "JPMorgan Chase", "JPMorgan Chase & Co.") are all searchable, all pointing to the same entity.

Search results for "JPMorgan" showing the unified golden entity

Typo Handling: "Gooldman Sachs"

What happens when an analyst types "Gooldman Sachs" (double-o typo)?

curl "https://merge-ai.app/v1/entities/search?q=Gooldman%20Sachs" \
  -H "X-API-Key: $API_KEY"

{
  "results": [
    {
      "entity_id": "ent_2c961383-10e2-4c1b-abd2-ef6696b404dd",
      "score": 1,
      "source": {
        "entity_type": "Company",
        "name": "Goldman Sachs Group Inc",
        "source_count": 4,
        "attributes": {
          "name": "Goldman Sachs Group Inc",
          "stock_ticker": "GS",
          "industry": "Investment Banking",
          "headquarters": "New York"
        }
      },
      "match_signals": ["lexical"]
    }
  ]
}

Merge's search engine uses edit-distance algorithms and phonetic matching to correctly return Goldman Sachs despite the transposition error. This is critical for building compliance search interfaces where analysts query counterparty names under time pressure.

Search results for "Gooldman Sachs" (typo) correctly finding Goldman Sachs

Search Capabilities for Financial Workflows

Feature Example Query Use Case
Exact name q=JPMorgan Direct counterparty lookup
Typo tolerance q=Gooldman Sachs Analyst search with misspelling
Partial name q=Berk Autocomplete in search UI
Entity type filter q=Apple&entity_type=Company Distinguish Apple Inc from a person named Apple
Attribute search attribute=stock_ticker&value=AAPL Ticker-based lookup
Relationship filter has_relationship=board_member Find entities with board connections

The Final Picture: Clean Master Data for Finance

After all resolution processing, here is what our financial master data graph looks like:

Final dashboard showing completed entity resolution

Analytics Summary

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

{
  "creates": 14,
  "decisions": 34,
  "merges": 20,
  "reviews": 0,
  "reviews_accepted": 0,
  "pending_reviews": 0
}

What These Numbers Tell Us

  • 14 golden entities created — the deduplicated, resolved master records
  • 34 resolution decisions — each ingested record evaluated against the existing entity graph
  • 20 merges performed — duplicate records unified into golden entities
  • 0 pending reviews — all resolution work complete with high confidence

Golden Entity Inventory

Entity Type Sources Resolution Method Notes
JPMorgan Chase & Co. Company 6 Identity (ticker: JPM) Bloomberg + Reuters + SEC unified
Goldman Sachs Group Inc Company 4 Identity + AI Ticker GS + "Group Inc" variant matched
Apple Inc Company 2 Identity (ticker: AAPL) NASDAQ + SEC filings
Microsoft Corporation Company 2 Identity (ticker: MSFT) NASDAQ + fund holdings
Tesla Inc Company 2 Identity (ticker: TSLA) NASDAQ + fund holdings
Berkshire Hathaway Company 2 Identity (ticker: BRK) SEC + Bloomberg
Meta Platforms Company 4 AI auto-merge "Meta" + "Meta Platforms" unified
Warren Buffett Person 2 AI auto-merge SEC + Bloomberg sources
Jamie Dimon Person 2 AI auto-merge Multiple SEC references
Tim Cook Person 1 — Single source
Elon Musk Person 3 AI auto-merge SEC + "E. Musk" news wire
Berkshire Hathaway Fund Fund 1 — Single source
Vanguard Total Market Fund Fund 1 — Single source
Annual Report 2024 Filing 1 — JPMorgan filing

The Compliance Value

The reduction from multiple fragmented records to 14 clean golden entities means:

  • Single customer view: every counterparty has exactly one record, regardless of how many sources reference them
  • Full lineage: every golden entity traces back to its original source records for audit
  • Graph connectivity: relationships between people, companies, funds, and filings are traversable
  • Zero manual deduplication: identity keys and AI handled everything automatically
  • Confidence scoring: every merge decision is scored for risk assessment

Tips for Production Financial Data Pipelines

1. Design Identity Keys Around Market Standards

The biggest ROI in financial entity resolution comes from leveraging existing market identifiers:

Entity Type Recommended Identity Key Source
Listed company Stock ticker / ISIN Exchange reference data
Fund Fund ISIN / LEI Regulatory registrations
Person LEI-linked individual ID Not always available
Filing SEC accession number EDGAR system

Mark these as identity: true in your schema. Every record carrying a valid identity key is resolved instantly and deterministically.

2. Layer Your Resolution Strategy

Do not rely on a single approach:

  • Deterministic for records with trusted market identifiers (fastest, most reliable)
  • Agentic AI auto-merge for high-confidence matches without IDs (handles naming variants)
  • Human review for edge cases (catches errors the AI is not sure about)
  • Force merge for known duplicates discovered through manual research

3. Use Relationships for Compliance Validation

Graph structure helps validate merges and catch anomalies. If two "JPMorgan" records both have board_member → Jamie Dimon relationships, that is additional evidence they are the same entity. Conversely, if a merge would create conflicting relationships (same person as CEO of two competing firms), that signals a potential false match.

4. Monitor the Review Queue

A growing review queue in financial data often signals:

  • Low identity key coverage: too many records arriving without tickers or LEIs. Work with data vendors to enrich their feeds.
  • Name normalization issues: pre-process "Inc", "Corp", "Ltd", "& Co." suffixes before ingest
  • Threshold tuning: if false positives are rare, consider lowering the review threshold slightly

5. Build for Multi-Hop Compliance Queries

Design your relationship schema to enable the traversal patterns regulators require:

  • Ultimate beneficial ownership: Person → manages → Fund → invested_in → Company (2 hops)
  • Exposure analysis: Company → invested_in ← Fund → invested_in → Company (3 hops)
  • Related party transactions: Person → board_member → Company ← filed_by ← Filing (3 hops)
  • Conflict of interest: Person → board_member → Company ← invested_in ← Fund → manages → Person

6. Handle Source Priority for Golden Records

When multiple sources disagree on an attribute value (Bloomberg says "Banking", SEC says "Financial Services"), the golden entity needs a resolution strategy:

  • Official regulatory sources (SEC) typically have highest weight for legal names
  • Real-time market data (Bloomberg, Reuters) win for current operational attributes
  • Source recency matters: more recent filings override stale data
  • Source count adds confidence: three sources agreeing outweighs one dissenting

7. Plan for Regulatory Changes

Companies rename (Facebook → Meta), merge (acquiring entity absorbs acquired), or split (spin-offs create new entities). Your entity resolution system needs to handle these:

  • Rename: new name ingested with same ticker → identity auto-merge
  • M&A: force merge the acquired entity into the acquirer
  • Spin-off: split API to separate source records into a new entity
# Split a source record out of an entity (e.g., after a corporate spin-off)
curl -X POST https://merge-ai.app/v1/entities/{entity_id}/split \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "source_id": "src_spun_off_division" }'

8. Use Webhooks for Real-Time Compliance Alerts

Set up webhooks to push resolution events to downstream compliance systems:

curl -X POST https://merge-ai.app/v1/webhooks \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://your-compliance-system.com/hooks/entity-events",
    "events": ["entity.merged", "entity.created", "review.pending"]
  }'

This enables real-time alerts when:

  • A new entity is created that matches a watchlist name
  • A merge unifies previously separate records (potential hidden relationship)
  • A review is pending for a high-risk entity type

9. Leverage Semantic Search for Investigations

Beyond lexical matching, Merge supports semantic search for investigative queries:

curl "https://merge-ai.app/v1/entities/semantic?q=large%20bank%20new%20york" \
  -H "X-API-Key: $API_KEY"

This finds entities whose combined attributes match the conceptual query, even when no single field contains those exact words. Useful for compliance investigations where you know what you are looking for conceptually but not the exact entity name.

10. Export for Regulatory Reporting

When regulators request your full entity inventory:

curl https://merge-ai.app/v1/tenant/export \
  -H "X-API-Key: $API_KEY"

This exports all entities, relationships, source records, and resolution history in a format suitable for regulatory submission. Every merge decision is auditable, every source record is preserved, and every relationship is documented.

Conclusion

We started with financial entity records scattered across Bloomberg, Reuters, SEC filings, NASDAQ feeds, and news wires — each with its own naming conventions, formatting rules, and levels of completeness. Through Merge's three-tier resolution engine, we produced a clean master data graph with:

  • 14 golden entities — deduplicated, enriched, and confidence-scored
  • 4 relationship types — creating a traversable multi-hop compliance graph
  • 9 connected nodes visible from a single 3-hop query starting at any person or company
  • 20 automated merges — handled entirely by identity keys and agentic AI
  • Full audit lineage — every golden entity traces back to its original source records

The financial services domain exemplifies why entity resolution is not optional. Regulators demand single customer views. Risk teams need exposure analysis across complex ownership chains. Compliance officers must trace beneficial ownership through multiple entity layers. And all of this must work in real-time as new data arrives from dozens of sources simultaneously.

Merge handles all of this through a single API: schemas define your entity structure, identity keys handle deterministic matching, agentic AI resolves the ambiguous middle ground, and graph traversal connects everything into a queryable knowledge network. No ML models to train, no complex ETL pipelines to maintain, no manual deduplication backlogs.

The ticker symbol is just one example of an identity key. In your domain, it might be a LEI code, an ISIN, a CRD number, or a tax identification number. The pattern is the same: define your deterministic identifiers, let them handle the obvious cases instantly, and deploy agentic AI for everything else.

Ready to build your own financial master data graph? Sign up at merge-ai.app and start resolving entities in minutes.

Built with Merge — Entity resolution and master data graph platform for multi-source financial data.

Start free All solutions