Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
What master data management is, how golden records are built through matching and survivorship, the four MDM styles, and the governance layer that keeps it trustworthy.
Updated on
Most companies hold the same customer, the same supplier and the same product in five or six systems at once, each with a slightly different spelling, a different identifier and a different idea of which fields matter. Master data management is the practice of turning that into one trusted record per entity that every system can agree on, and master data governance is the set of decisions and owners that keeps the practice honest.
This guide covers what master data is, how a golden record is actually assembled through matching and survivorship, the four ways an MDM programme can be built, why these projects fail more often than they succeed, and what financial regulators in Indonesia, Australia, Singapore and the United States expect from customer and counterparty identity data.
Master data management (MDM) is the practice of maintaining one trusted version of the core business entities that every system refers to. Those entities are the nouns of the business: the customer, the product, the supplier, the location, the account. MDM covers the rules, the processes and the technology that identify when two records describe the same real world thing, decide which values survive into the trusted record, and keep that record correct as the source systems keep changing.
Master data is worth separating from the other kinds of data in a warehouse. Transaction data records events, an order, a payment, a claim, and it is high volume and immutable once written. Reference data is the shared code lists, currency codes, country codes, product categories, which change rarely and are usually managed centrally. Master data sits between the two: low volume compared with transactions, but changing constantly, referenced by almost every transaction, and owned by nobody in particular unless somebody is made to own it.
The reason MDM keeps returning to the agenda is that the cost of getting it wrong is visible in operations rather than in a report. Duplicate supplier records mean duplicate payments. Duplicate customer records mean a marketing email sent three times to the same person, or a credit exposure calculated against half of a relationship. Inconsistent product records mean the warehouse and the website disagree about what is in stock. None of these read as data problems when they surface, which is why they are usually solved four times in four systems before anyone solves them once.
These two terms are used interchangeably in most writing on the subject, including on plenty of vendor sites, and the confusion causes real damage in projects. They describe different layers of the same programme.
Master data management is the practice and the machinery: ingestion from source systems, standardisation, matching, survivorship, publication of the trusted record, and ongoing maintenance. Master data governance is the policy and ownership layer wrapped around that machinery: who owns the customer domain, which source is authoritative for a tax identifier, what the survivorship policy says when the CRM and the billing system disagree, who approves a manual merge, and how an exception is escalated.
A programme with strong MDM machinery and weak master data governance produces golden records that nobody trusts, because no named person stands behind the rules that produced them. A programme with strong governance documents and no MDM machinery produces a policy binder and no records at all. The pairing below is the shortest way to keep them straight.
| Dimension | Master data management | Master data governance |
|---|---|---|
| What it is | The practice and the system that produce one trusted record per entity | The policy and ownership layer that decides the rules the practice follows |
| Main output | Golden records, plus the crosswalk linking each one to its source records | Named domain owners, stewardship roles, survivorship policy, approval and escalation paths |
| Question it answers | Which of these records is the customer, and what does the customer look like | Who decides, and by which rule, when two authoritative sources disagree |
| Typically owned by | Data platform, integration or data engineering | The data governance function, with named business owners per domain |
| Measured by | Duplicate rate, match precision and recall, time to publish a new record | Percentage of domains with a named owner, open steward queue age, exception closure time |
| Fails when | Matching is never tuned and no operational system consumes the golden record | No one is named, so every conflict escalates and none of them are settled |
Practically, this means the first artefact of a master data governance effort should be a list of domains with one named human accountable for each, well before any policy document exists, because every survivorship rule that follows is a decision that person has to make.
Almost every MDM programme starts with one domain and expands. The five below cover most starting points. What makes the list useful is not the names but what "one version of the truth" concretely means for each, because it is different every time.
| Entity | Typical source systems | What one version of the truth means here |
|---|---|---|
| Customer | CRM, billing, support desk, marketing platform, mobile app | The same person appearing as Robert Chen in the CRM, R. Chen in billing and Bob Chen in the support desk resolves to one customer identifier, so the balance and the complaint history belong to the same human being |
| Product | ERP, ecommerce catalogue, warehouse management, pricing | One product identifier with agreed attributes: unit of measure, dimensions, category hierarchy and lifecycle state, so the website and the warehouse cannot disagree about what is in stock |
| Supplier | Procurement, accounts payable, contract management | One supplier record per legal entity with one tax identifier and one set of payment terms, so the same vendor cannot be onboarded three times and paid three times |
| Location | ERP, logistics, facilities, regulatory reporting | One site identifier per physical place, with one normalised address, so logistics, financial reporting and regulatory returns all count the same branch once |
| Account or counterparty | Core banking, trading, risk, KYC systems | One counterparty identifier per legal entity and its group hierarchy, so aggregate exposure across products and desks can be calculated and defended |
Two entities are commonly added next and are worth naming: employee, where the same person exists in the human resources system, the identity provider and the payroll system, and asset, where a machine or a policy or a contract needs a stable identifier across its life. The chart of accounts is often called master data too, but it behaves like reference data and is usually better managed that way.
One decision governs all of them: what counts as the same thing. Two branches at the same street address, one retail and one corporate, may be one location or two depending on whether the reader is in logistics or in tax. That definition belongs to the domain owner, and writing it down before any matching rule is configured saves months.
This is where most articles on master data management stop, and it is the only part that is genuinely hard. A golden record is the assembled trusted view of one entity, built from every source record that describes it. Getting there takes two distinct steps that are often confused with each other: matching decides which records describe the same thing, and survivorship decides which values from those records end up in the trusted view.
Matching quality collapses if the inputs are not normalised first. Names are cased and stripped of titles, addresses are parsed into components and validated against a postal reference, phone numbers are converted to a single international format, company suffixes are harmonised so that Limited, Ltd and Ltd. are the same token, and obvious placeholder values such as a date of birth of 1 January 1900 are marked as missing rather than compared. Every hour spent here removes a false match later.
Comparing every record against every other record grows with the square of the population, so a two million record customer base implies two trillion comparisons. Blocking cuts that down by only comparing records that share a cheap key, for example the first three characters of the surname plus the postcode, or the soundex of the company name. Blocking is also where matches are silently lost: a record whose postcode was mistyped never enters the same block as its twin, so it can never be matched. Running several blocking passes with different keys and taking the union is the standard defence.
Deterministic matching applies readable rules to decide identity. Two records match if the national identity number is equal, or if the email address and the date of birth are both equal, or if the company registration number is equal. The rules are written by hand, reviewed by the domain owner and produce an answer that can be explained to an auditor in one sentence.
The weakness is coverage. Deterministic rules only fire when the identifiers they depend on are present and correct, and in most real customer data they are missing or mistyped often enough that a large share of true duplicates never trigger a rule. Deterministic matching is high precision and low recall, which is exactly right for the identifiers you trust and insufficient on its own.
Probabilistic matching scores similarity instead of asserting identity. Each attribute pair is compared with a similarity function, an edit distance for names, a component by component comparison for addresses, and each agreement or disagreement contributes weight to a total score. The classical statistical formulation of this is the Fellegi Sunter model, and every commercial matching engine is a variation on it.
Two properties matter in practice. First, agreement on a rare value is much stronger evidence than agreement on a common one: two records sharing an unusual surname are far more likely to be the same person than two records sharing a common one, and the weights should reflect that frequency. Second, the output is a score, not a verdict, so the programme has to choose where to cut it.
That is done with two thresholds rather than one. Above the upper threshold, records merge automatically. Below the lower threshold, they are treated as different. Between them sits the clerical review queue, where a data steward looks at the pair and decides. The width of that middle band is a staffing decision as much as a statistical one, and a queue nobody is resourced to work is the single most common reason a matching programme quietly stops improving.
Set the thresholds asymmetrically, because the two errors are not equally bad. A missed match leaves a duplicate, which is annoying and recoverable. A false match merges two different people into one record, which mixes their transactions, their consent choices and possibly their medical or financial history, and in regulated data that is an incident rather than a defect. Bias the automatic merge threshold towards precision and let the review queue absorb the doubt.
| Aspect | Deterministic matching | Probabilistic matching |
|---|---|---|
| How it decides | Hand written rules on exact or normalised values | Weighted similarity across many attributes, producing a score |
| Strength | High precision and easy to explain to an auditor | Finds duplicates that no rule would catch, including typos and partial records |
| Weakness | Low recall. Silent when the identifier is missing or mistyped | Needs tuning, training pairs and a review queue, and the reasoning is harder to summarise |
| Human effort | Concentrated up front, in writing and reviewing the rules | Ongoing, in working the clerical review queue and retuning the weights |
| Best used for | Strong identifiers: tax number, national identity number, registration number | Everything else, especially customer names, addresses and contact details |
| Typical mistake | Assuming the identifier is always populated, and never measuring recall | Setting one threshold instead of two and auto merging the uncertain band |
Once a cluster of records is agreed to describe the same entity, survivorship builds the golden record from it. The mistake that makes golden records untrustworthy is applying survivorship at record level, picking one source record as the winner and copying it wholesale. Real sources are good at different things. The billing system usually holds the best legal name and tax identifier, the support desk usually holds the most current mobile number, and the marketing platform usually holds the most recent consent state. Survivorship rules belong to fields, not to records.
| Survivorship rule | How it works | Where it goes wrong |
|---|---|---|
| Source priority | A ranked list of systems per field. The highest ranked populated value wins | A stale value in the top ranked system beats a fresh one below it. Pair it with a recency test |
| Most recent update | The value with the latest change timestamp wins | Timestamps often record when a batch ran rather than when a human changed the value |
| Most complete | The value from the record with the fewest empty fields wins | Rewards systems that populate defaults. A record full of placeholder values scores as complete |
| Most frequent | The value appearing in the most source records wins | Five systems fed by the same bad upstream extract vote as five independent witnesses |
| Longest value | The longest string wins, on the assumption it carries more detail | Picks up trailing notes, duplicated address lines and free text comments. Common and dangerous |
| Validated value | A value that passes an external check, such as postal or tax validation, wins | Only available for fields with an external reference, and adds a dependency to every run |
| Steward override | A human decision pins the value | Must be sticky. If the next batch overwrites the override, stewards stop trusting the tool and stop using it |
Two things have to survive alongside the values. The first is the crosswalk, the mapping from the golden record back to every contributing source record and its identifier. Without it no value can be explained, no source system can be updated, and the trusted record becomes an assertion rather than a traceable result. The second is an unmerge path. Merges will be wrong sometimes, and a hub that can only merge accumulates errors it cannot reverse. The first bad merge that cannot be undone is usually the moment a business stops trusting the programme.
Field level survivorship is also what makes column level lineage worth having underneath an MDM hub. When someone asks why the golden record shows a particular address, the answer has to name the source system, the record and the rule that selected it, and that answer comes from lineage rather than from the hub alone.
The four styles below are the industry standard way of describing how an MDM hub relates to the systems around it. Product features matter far less here than two structural questions: where master data is authored, and what, if anything, the hub writes back. Those two answers determine how much business process change the programme demands.
| Style | Where master data is authored | What the hub writes back | Suits | Main trade off |
|---|---|---|---|---|
| Registry | Nowhere. Sources keep authoring as they do today | Nothing. The hub stores keys and match results and serves a virtual view on request | A first programme, or an organisation that needs a customer 360 view quickly without touching operational systems | Read only. Duplicates stay in the source systems and the underlying data quality never improves |
| Consolidation | Sources continue to author. Copies are pulled into the hub | Nothing. The golden record serves reporting, analytics and regulatory returns | Analytics, risk aggregation and reporting use cases, where one trusted view downstream is the goal | Operational systems keep their duplicates, so the same customer still gets two letters |
| Coexistence | Sources author, the hub harmonises | The golden record is published back to the source systems, which accept it | Most large enterprises. It improves the sources without forcing everyone onto a new system of entry | The hardest integration work of the four. Every source needs an inbound path and conflict handling |
| Centralised | The hub. Master data is created and edited there | Everything. Sources subscribe and consume | Organisations that can mandate process change, and domains such as product where authoring is already centralised | The largest change to daily work, the longest programme, and the strongest resistance |
Two rules keep this choice sane. Start no higher than you need: a registry or consolidation hub that ships in one quarter teaches the organisation more about its own data than a centralised programme that ships in two years. And choose per domain rather than per company: product master data is often a good fit for a centralised style while customer data in the same business is better served by coexistence, and nothing requires them to match.
Master data governance is what makes the machinery defensible. It is a small set of artefacts, and a programme either has them or does not.
This layer is where master data governance meets general data governance, which sets the wider rules for ownership, access and classification across all data rather than only the master domains. The two should share the same owners and the same escalation path. Running master data governance as a separate structure with its own council is how organisations end up with two sets of rules that contradict each other.
Almost no competing article on master data management covers this, and for Decube customers in regulated markets it is the part that funds the programme. Financial supervisors do not usually publish rules about MDM by name. They publish expectations about customer and counterparty identification, exposure aggregation and reporting accuracy, and every one of those expectations is an entity resolution problem underneath.
| Regulator | Who it supervises | Why entity resolution matters | What the programme should be able to show |
|---|---|---|---|
| OJK, Indonesia | Banks, insurers and financial technology firms | Customer identification across products and channels sits underneath consumer protection and regulatory reporting | How duplicate customer records are found and resolved, and the quality of the identity data feeding returns |
| APRA, Australia | Banks, insurers and superannuation funds | Risk data has to be aggregated by counterparty and group, which is impossible if the same counterparty exists three times | Named accountability for the critical data elements, and evidence that the identity data behind aggregation is controlled |
| MAS, Singapore | Financial institutions | Fair and transparent treatment of customers depends on the institution knowing which decisions attach to which customer | Traceability from a customer affecting decision back to the customer record and the data behind it |
| NAIC, United States insurance | Insurers, supervised at state level | Policyholder and claimant identity across policies drives claims handling and the documentation expected for underwriting and claims models | Documented identity resolution and the data provenance behind models that use policyholder data |
The common thread is that none of these supervisors accept a description of the process as evidence. They ask what the process produced on a given date for a given entity, which is why the crosswalk, the exception log and the lineage underneath the golden record matter more than the policy document does.
Master data management does not stand alone, and the surrounding disciplines are often sold as alternatives to it when they are inputs to it.
| Discipline | The question it answers | How it relates to MDM |
|---|---|---|
| Data governance | Who owns this data, who may use it, and by which rules | Supplies the owners and the decision rights that master data governance applies to the master domains |
| Data quality | Are the values accurate, complete, consistent and current | Measures the inputs to matching and the output golden record. Poor completeness silently destroys match recall |
| Data catalog | What data exists, where it is and what it means | Makes the golden record findable and documents its meaning, so downstream teams consume the trusted record rather than rebuilding their own |
| Data lineage | Where did this value come from and what happened to it | Explains why the golden record holds a particular value, which is what an auditor asks for |
| Reference data management | What are the agreed code lists | Adjacent, not the same. Country and currency codes change rarely and need version control rather than matching |
If the master domains are still being defined, the practical order is to settle ownership first, measure quality second and match third. Match recall depends directly on completeness and consistency, so it is worth checking the six dimensions of data quality on the candidate source fields before any matching engine is configured. A data catalog matters at the other end, because a golden record that downstream teams cannot find is a golden record they will quietly rebuild.
These programmes have a poor completion record, and the reasons repeat. The list below is ordered roughly by how often each one is the actual cause rather than the stated one.
A useful first ninety days looks like this. Pick one domain and one consuming system, and write down the entity definition and the named owner before anything technical begins. Profile the candidate source fields and measure completeness, because that number predicts match recall better than any vendor benchmark. Then run matching on a sample, review the results by hand with the domain owner, and tune the thresholds together, which is also the fastest way to teach an organisation what its own data looks like.
Only after that does the style decision become concrete: a registry or consolidation hub if the immediate need is a trusted view for reporting, coexistence if the source systems have to improve, centralised only where the business is willing to change where people type. Selecting a platform comes last, and we cover that separately in our comparison of data governance tools.
Decube is not a master data management hub, and it is worth being direct about that. What Decube supplies is the layer underneath and around an MDM programme, which is where most of them run into trouble. Decube data governance covers ownership, classification, policy and the catalog surface that makes the trusted record findable, and the quality monitoring alongside it measures the completeness and consistency of the source fields that matching depends on.
The other half is evidence. Column level data lineage traces a value from the source system through every transformation to where it lands, which is the answer to the question a supervisor asks about a golden record and the question a business user asks when the number looks wrong. If you want to see how that looks against your own sources, you can request a demo.
Master data management is the practice of maintaining one trusted version of the core business entities that every system refers to, such as customer, product, supplier, location and account. It covers the rules, processes and technology that identify when two records describe the same real world thing, decide which values survive into the trusted record, and keep that record correct as the source systems change.
Master data management is the practice and the machinery: ingestion, standardisation, matching, survivorship and publication of the trusted record. Master data governance is the policy and ownership layer around it, deciding who owns each domain, which source is authoritative for each field, what the survivorship policy says when systems disagree, and who approves a manual merge. Governance sits inside an MDM programme rather than replacing it.
A golden record is the assembled trusted view of one entity, built from every source record that describes it. It is created in two steps: matching decides which records describe the same thing, and survivorship decides which value from those records wins for each individual field. A golden record should also keep a crosswalk back to every contributing source record, so any value can be explained or reversed.
Deterministic matching applies hand written rules to exact values, for example two records match when the national identity number is equal. It has high precision and is easy to explain, but it stays silent when the identifier is missing or mistyped. Probabilistic matching scores similarity across many attributes and produces a match score, which catches far more duplicates but needs two thresholds, an automatic merge band and a human review band, plus ongoing tuning.
Registry keeps data in the source systems and stores only keys and match results, serving a virtual view. Consolidation copies data into a hub and builds golden records for reporting without writing back. Coexistence does the same and publishes the golden record back to the sources. Centralised makes the hub the place where master data is authored. They differ in where data is authored and what is written back, which determines how much process change the programme requires.
Compliance obligations usually depend on knowing which customer or counterparty a record belongs to. Master data management supplies that identity resolution, and the crosswalk and exception log it produces are the evidence a supervisor asks for. Data governance supplies the owners and the decision rights that the master data rules apply, so the two work as one programme: governance decides the rules, master data management executes them and produces the record.
Data consistency management is the work of making the same fact agree across every system that holds it, so the customer address in billing matches the one in the support desk and the product weight in the warehouse matches the one on the website. For the core business entities this is exactly what master data management delivers, through matching, field level survivorship and publication of the trusted record back to the systems that need it.
Confidence comes from being able to answer three questions about any number: who owns it, what rules it was held to, and where the value came from. A unified framework supplies all three in one place, with a named owner per domain, published quality rules and lineage from source to report. For master data specifically it also settles which record is the customer, so two teams reporting on the same customer base produce the same total.
The two most common causes are organisational rather than technical. Ownership is never assigned to a named person per domain, so survivorship disputes escalate and never get settled, and the golden record is built without a consuming system, so it is correct and unused. After those come thresholds that are set once and never tuned, taking on every domain at once, and having no way to reverse a wrong merge.
Name one accountable owner per domain rather than a committee. Write the entity definition down before configuring any matching rule. Keep a source of record register saying which system is authoritative for each field. Version the survivorship policy, because changing a threshold changes thousands of records. Resource the review queue and measure its age. Log every manual override and every reversed merge, dated and attributed.
Master data management is a single source of truth problem before it is a matching problem, and the same holds for the definitions that sit above the records. This walkthrough opens on teams using the same term to mean different things, then moves through the glossaries, categories and terms hierarchy in Decube, the ownership fields that assign a data owner and a business owner to each term, the custom attributes that carry calculation logic and reporting cadence, and the linked assets tab showing which tables and columns a definition actually governs. Watch it to see what the ownership and definition layer described above looks like once it is configured rather than written down in a document.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Book a 30-min demo with us and see how lineage, quality, governance, and compliance come together in a single platform.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)