# Reference and master data: the customer and product golden record
A large bank once discovered that a single corporate client, a global manufacturer, existed in its systems 47 times. Different spellings, different subsidiaries, different trading desks, all treated as separate customers. When the risk team tried to answer a simple question, "What is our total exposure to this group?", the number was wrong by billions. Not because of fraud or bad math, but because the bank had no single, trusted version of who the customer was.
This is the problem master data managementmaster data managementMaster Data Management (MDM) is the discipline of creating and maintaining a single, consistent, trusted version of an organization's core business entities like customers, products, and suppliers.Voir la définition complète → solves.
These two terms get confused constantly, so let us pin them down.
Reference data is the shared vocabulary. It is the slow-changing lookup lists everyone agrees on: currency codes (USD, EUR), country codes (ISO 3166), product type codes, branch codes. Reference data is usually external or standardized.
Transactional data, by contrast, is the "verbs": a wire transfer, a trade, a loan drawdown. Every transaction points back to master data ("this payment, from this customer, in this currency").
If the master data is wrong, every transaction that references it inherits the error.
The golden record is the single, reconciled, authoritative version of a master data entity. One customer, one record, one truth, stitched together from many source systems.
Banks are messy because they grew by acquisition and by product silo. A retail customer might exist in:
Each system assigned its own customer ID. The golden record links them.
For retail customers, the anchor comes from KYC (Know Your Customer, the regulatory process of verifying identity to prevent money laundering). KYC captures a verified name, date of birth, address, and a government identifier (a Social Security Number in the US, a national ID or passport in Europe).
For corporate and institutional counterparties, the gold standard is the LEI (Legal Entity Identifier). This is a 20-character code that uniquely identifies a legal entity worldwide. It was created after the 2008 crisis precisely because regulators could not answer "who is exposed to Lehman Brothers?" quickly enough.
The LEI is free to look up. You can search any entity in the Global LEI Foundation (GLEIF) database.
The LEI does more than identify one entity. GLEIF records the parent-child relationships between entities: which subsidiary rolls up to which ultimate parent. This is the hierarchy that let the bank in our opening story finally aggregate exposure correctly.
Example structure:
Ultimate Parent (LEI: 5493...)
├── Regional Holding EU (LEI: 2138...)
│ ├── Trading Subsidiary FR (LEI: 9695...)
│ └── Lending Subsidiary DE (LEI: 8945...)
└── Regional Holding US (LEI: 5493...)
└── Broker-Dealer US (LEI: 2540...)When you extend credit to the Trading Subsidiary FR, your exposure to the Ultimate Parent must roll up through this tree. Get the hierarchy wrong and you breach concentration limits without knowing it.
The same discipline applies beyond customers.
The product catalog (or product master) defines every product the bank sells: each deposit account type, each loan, each derivative. A single mislabeled product code can misroute a transaction into the wrong general ledger account, corrupting regulatory reports.
The counterparty master is the institutional version of the customer master, used heavily in capital markets. It feeds credit risk, collateral management, and settlement. If two desks each maintain their own counterparty ID for the same bank, netting calculations (offsetting what you owe against what you are owed) break.
Building a golden record is a two-step data problem.
Step 1: Matching (entity resolution). Decide which records refer to the same real-world entity. This is rarely a clean join. "J. Smith, 12 Oak St" and "John Smith, 12 Oak Street" are probably the same person. Matching engines use deterministic rules (exact match on national ID) plus probabilistic scoring (fuzzy name, address, date of birth).
Step 2: Survivorship. When you merge matched records, which value wins? If the CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.Voir la définition complète → says the phone number is one thing and the mortgage system says another, survivorship rules pick the trusted source or the most recent verified value.
A simple worked matching example:
Record A: name="ACME CORP", LEI=null, country=US
Record B: name="Acme Corp Inc", LEI=5493001..., country=US
Record C: name="ACME CORPORATION", LEI=5493001..., country=US
Match score B vs C: LEI exact match -> score 1.00 -> MERGE
Match score A vs B: name fuzzy 0.82, country match 1.0
weighted score 0.71 -> REVIEW (below 0.85 auto-merge threshold)Records B and C merge automatically on the LEI. Record A goes to a human steward for review because it lacks the strong identifier.
Master data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.Voir la définition complète → is measured, not assumed. The core dimensions:
A simple worked completeness calculation:
Counterparties requiring an LEI: 50,000
Counterparties with a valid LEI: 47,300
LEI completeness = 47,300 / 50,000 = 94.6%If a regulator requires 100 percent LEI coverage for reportable derivatives, that 5.4 percent gap is a compliance finding.
🎬 [VIDEO: "What is Master Data ManagementMaster Data ManagementMaster Data Management (MDM) is the discipline of creating and maintaining a single, consistent, trusted version of an organization's core business entities like customers, products, and suppliers.Voir la définition complète → (MDMMDMMaster Data Management (MDM) is the discipline of creating and maintaining a single, consistent, trusted version of an organization's core business entities like customers, products, and suppliers.Voir la définition complète →)?" - youtube.com - a clear 6 minute conceptual overview of MDMMDMMaster Data Management (MDM) is the discipline of creating and maintaining a single, consistent, trusted version of an organization's core business entities like customers, products, and suppliers.Voir la définition complète → and golden records]
Metrics need owners. This is where data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Voir la définition complète → comes in.
A data stewarddata stewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Voir la définition complète → is the person accountable for the quality of a data domain (say, the customer master). A data owner is typically a senior business leader who signs off on definitions and access. Together they enforce the rules: what makes a valid record, which system is the authoritative source for each field, and who may create or merge records.
In Europe, master data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Voir la définition complète → intersects directly with the GDPR (General Data Protection Regulation), which grants individuals rights over their personal data. You cannot honor a "right to erasure" request if you do not know all 47 places a customer lives in your systems. The golden record is what makes GDPR compliance operationally possible.
In the US, the BCBS 239BCBS 239Principe du Basel Committee on Banking Supervision imposant aux grandes banques une traçabilité stricte des données de risque, ayant catalysé la création de nombreux postes de CDO dans le secteur bancaire. principles (issued by the Basel Committee on Banking Supervision, on risk data aggregation) push large banks to prove they can aggregate risk data accurately and quickly. That is impossible without clean master data.
Vérification des acquis
1. A bank finds that its total risk exposure to a corporate group is wrong by billions, even though no fraud or calculation errors occurred. What underlying data problem most likely caused this?
2. Which statement best captures the distinction between reference data and master data?
3. Why does an error in a bank's master data have especially far-reaching consequences?
4. Select ALL correct answers about the golden record.
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers that correctly classify data types in a bank.
Sélectionnez toutes les réponses correctes.
Return to the opening scene. Here is the chain of damage from a single duplicated customer ID:
1. Risk aggregation understates exposure. Two IDs for one client means limits look unbreached when they are breached.
2. Regulatory reports are wrong. Large-exposure reporting to regulators sums by counterparty. Duplicates fragment the total.
3. AML monitoring misses patterns. Anti Money Laundering surveillance looks at behavior per customer. Split a customer in two and suspicious patterns fall below alert thresholds.
4. Customer experience degrades. The client gets asked for KYC documents twice, receives duplicate mailings, and sees inconsistent balances.
5. Analytics lie. Every "number of customers" metric, every cross-sell model, every churn prediction is built on inflated, fragmented counts.
The insidious part: none of this throws an error. The systems run fine. The numbers are simply quietly wrong, and nobody notices until a regulator or a crisis forces the question.