Master Data Management & Reconciliation: Interview-Ready Framework for Conflicting Sources
The biggest misconception about Master Data Management is that it is a database clean-up project. It is not. It is the discipline that decides whose version of the customer, product, vendor or account becomes the business truth when every system says something different.
- Master data is the core entity data a business repeatedly uses - customer, product, vendor, employee, location, asset.
- MDM creates a trusted “golden record” by standardising, matching, merging and governing records from multiple systems.
- Conflicts happen because systems optimise for different purposes - CRM for sales, ERP for billing, app analytics for behaviour, support tools for service history.
- The key decision is not “which source is correct?” but “which source is authoritative for this field, at this time, under this business rule?”
- Good reconciliation follows a loop: ingest, profile, match, apply survivorship rules, create exceptions, fix root causes.
- Track quality using completeness, duplicate rate, match precision, match recall, exception rate and resolution SLA.
- Interview-safe answer: define MDM, show the conflict, name the golden-record process, mention governance, then quantify data quality.
Think of MDM as the control tower for business entities. Operational systems keep generating records, but MDM decides identity, hierarchy, ownership and the approved version that downstream teams can trust.
Core Explanation: How MDM Reconciles Conflicting Sources
Master Data Management solves a deceptively hard problem: the same real-world entity appears differently across systems. One customer may be “Amit Sharma” in the CRM, “A. Sharma” in billing, a phone number in the app database, and a masked email in support logs.
The heart of MDM is entity resolution - deciding whether two records refer to the same real-world entity. Once the match is made, survivorship rules decide which field value survives into the golden record.
The most important interview word here is survivorship. It means the business rule that decides the surviving value when sources conflict. Example: for a customer’s legal name, KYC may win; for current delivery address, the latest app-confirmed address may win; for credit limit, the risk system may win.
Definitions You Should Be Able to Say Clearly
- Master data: DAMA-DMBOK describes master data as data about business entities that provides context for business transactions.
- MDM: Gartner calls MDM a technology-enabled discipline where business and IT ensure uniformity, accuracy, stewardship, semantic consistency and accountability of shared master data.
- Golden record: The approved best-version record for an entity, created from governed matching, merging and survivorship rules.
- Data reconciliation: Comparing records across sources, identifying differences, resolving conflicts and documenting exceptions.
Types of Conflicts You Must Recognise
Most candidates say “there are duplicates.” Strong candidates classify the conflict, because each type needs a different fix.
How to Decide the Truth When Sources Disagree
The winning source changes by field. A bank’s KYC system may be authoritative for legal identity, the core banking system for account balance, the CRM for relationship manager, and the mobile app for latest communication preference.
Key Metrics to Track Data Reconciliation Quality
If you claim the MDM process is working, prove it with measures. Use these in analytics, operations, consulting and product interviews.
Mini Worked Example: Match Precision and Recall
Suppose an MDM matching run flags 120 customer-record pairs as duplicates. On review, 96 are genuine duplicates and 24 are false matches. The audit sample also reveals 24 genuine duplicate pairs that the algorithm missed.
The business implication matters. In a brokerage or bank, a false merge may expose sensitive data to the wrong person, so precision may be prioritised. In marketing deduplication, missed duplicates may waste campaign spend, so recall may deserve more attention.
Case Study: Zerodha and the Discipline of Reconciling Trading Truth
Zerodha shows why reconciliation is a trust issue: a broker must align customer, order, trade, funds and holdings data across exchanges, banks, depositories and internal systems.
Situation: In Indian broking, the customer does not experience “systems.” They see one app screen. Behind that screen, however, different truths arrive from different places: orders and trades from exchanges, holdings from depositories such as CDSL or NSDL, funds movement through banking rails, customer identity from KYC records, and internal ledgers for platform-level accounting.
The move: A broker like Zerodha must reconcile these sources using strong identifiers - client ID, order ID, trade ID, ISIN, settlement date and bank reference - and maintain clear ownership for each data domain. Holdings should not be casually overwritten by an app event; trade status should not be inferred only from a front-end notification; funds availability must align with ledger and regulatory rules.
Outcome and lesson: The primary driver of trust is disciplined reconciliation across independent systems. Supporting drivers include strong unique IDs, audit trails, exception queues, regulatory reporting discipline and clear customer communication when settlement or posting delays occur. The “so what” is simple: in financial products, MDM is not a back-office luxury - it protects customer trust and regulatory correctness.
This is also a clean Indian example for interviews: India’s capital-market ecosystem is multi-party by design, with SEBI-regulated intermediaries, exchanges, clearing corporations, depositories and banks. That structure makes reconciliation essential, not optional.
How AI Changes Master Data Management & Reconciling Conflicting Sources
AI does not remove the need for governance. It changes how quickly teams can detect, match and explain conflicts.
- AI-assisted entity resolution: Modern matching can use embeddings and similarity models to detect that “ABC Pvt Ltd,” “A.B.C. Private Limited” and a GST-linked vendor record may refer to the same entity. The model suggests candidates; business rules and stewards still decide high-risk merges.
- Anomaly detection in reconciliation: ML models can flag unusual mismatch patterns - for example, a sudden spike in failed product-code mappings after a catalogue upload or unexpected payment-status mismatches after an API change.
- Metadata and lineage copilots: LLM tools can help analysts understand field definitions, trace where a dashboard metric came from, and summarise why two sources disagree. The risk is hallucination, so lineage and access controls must be verified against governed metadata.
Use NotebookLM or ChatGPT to practise like this: load a company annual report, data architecture notes if available, and this lesson; ask, “List five master-data conflicts this business may face, the likely authoritative source for each field, and the reconciliation metric I should track.” Then manually verify every company-specific claim.
Interview Relevance
“Suppose customer data differs across CRM, billing and app analytics. How would you create a single trusted customer view?”
Use the phrase “field-level system of record.” It signals maturity because you are not blindly trusting one system for every attribute.
Common Mistake
The mistake is saying, “We will take the latest value.” Latest is not always correct - a fresh app entry may be less reliable than an older verified KYC record. The fix: define survivorship by field using authority, recency, completeness, consent and risk.
What to Revise Next
Once you understand how to create a trusted record, revise how to protect it. The natural next topics are access, masking and privacy-by-design, especially because master data often contains sensitive personal and financial fields.