Master Data, Reference Data, and the Single Business Truth

The truth is a decision, not a discovery

Every large organization has the same argument in a different form. Sales and finance report different customer counts. The supplier in procurement is not quite the supplier in accounts payable. A branch code means one thing in the core system and another in the data warehouse. Someone proposes a master data management (MDM) program to create "a single version of the truth".

Many of those programs disappoint, and the reason is rarely the technology. Matching algorithms and data hubs are mature. What is usually missing is a set of decisions: which system is authoritative for which attribute, who may change it, and what happens when two sources disagree. Without those decisions, an MDM hub becomes one more copy of the data, with its own inconsistencies.

The cost of getting this wrong is not abstract. In July 2024 the Federal Reserve fined Citigroup $60.6 million, alongside an OCC penalty of about $75 million, for insufficient progress in remediating problems with its data quality management under a 2020 enforcement action. Data quality is wider than master data, but the lesson carries: regulators now treat the inability to produce consistent, controlled core data as a safety-and-soundness issue.

Reference data failures can be even more expensive. NASA lost the Mars Climate Orbiter in September 1999 because ground software used English units while the spacecraft's software expected metric. A unit of measure is the simplest kind of reference data there is. Nobody had made one shared, enforced decision about it.

This article argues three things. First, master data and reference data are different problems and should be managed differently. Second, the right MDM hub style follows from where each record is authored, and can differ by domain. Third, the golden record is built one attribute at a time through survivorship rules that business owners, not engineers, must approve.

Master data and reference data are different problems

The two terms are often used together, and Saudi Arabia's NDMO standards treat them as one domain. But they behave differently.

Some reference data comes from outside the organization, and the best practice is not to reinvent it. The Legal Entity Identifier, for example, is a 20-character code defined by ISO 17442 and administered by the Global Legal Entity Identifier Foundation. It answers "who is who" and "who owns whom" for legal entities. A financial institution that links counterparties to their LEI gets a shared external key for part of its customer master.

NDMO's standards make the same distinction formally. Specification RMD.1.3 requires entities to categorize reference data as internal, where the entity is the single source of truth across government, or external, owned by another entity or by a standards body such as ISO. RMD.1.4 applies the same split to master data objects. That categorization exists so that national standardization can happen: one entity owns a list, and everyone else consumes it.

Four hub styles, one question

MDM hub architecture is usually described in four implementation styles. NDMO specification RMD.2.2 requires entities to choose among them explicitly, and its definitions are clear:

• Registry hub. Master records stay in their source systems. The hub holds an index of key identifiers and links matched records. Nothing is changed at source.
• Repository hub (often called consolidation). Records are copied from sources, matched and consolidated in the hub, in one direction only. The golden record serves reporting and analytics; sources keep authoring.
• Coexistence hub. Two-way synchronization is added, so sources and hub hold the same golden record. Records can be created and changed in sources, and corrections flow back.
• Centralized hub (sometimes called transaction style). Records are created and changed only in the hub, which becomes the exclusive provider to every consuming application.

For reference data, NDMO goes further and requires the centralized style: the hub is the single provider, and changes happen only there.

The styles are not a maturity ladder to climb. They answer one question: where is the record authored today, and can you change that? A customer record created in a CRM, an e-commerce platform and a branch system, each serving a real business process, cannot easily be moved into a central hub. A product record that already passes through a single approval workflow can.

Three rules of thumb follow:

1. Start registry or repository when the first goal is reporting, analytics or AI on consistent entities. Both are low-risk because nothing changes in operational systems.
2. Move to coexistence only for attributes where corrections must flow back to operations, and only once survivorship rules are stable. Bi-directional synchronization multiplies the cost of every wrong rule.
3. Use centralized authoring for reference data always, and for master domains with a natural single creation process, such as products, chart of accounts or organizational units.

Different domains in the same organization will land on different styles, and that is correct.

The golden record is built attribute by attribute

A golden record is the best available version of an entity, assembled from all the sources that hold part of it. Building one takes three steps: match records that refer to the same entity, merge them into one cluster, and apply survivorship rules to decide which value of each attribute wins.

Survivorship is where business judgment enters. A worked example makes it concrete.

Four patterns cover most survivorship rules:

• Source trust. For each attribute, rank sources by reliability. The ID verification system wins on legal name; billing wins on billing address.
• Recency. The most recently updated value wins, for attributes that genuinely change, such as mobile number.
• Completeness and validity. A value that passes format and reference checks beats one that does not.
• Never automate. Some conflicts, such as two different dates of birth, should go to a steward rather than be resolved by a rule.

The rules belong to the business owners of each attribute. Engineers implement them; they should not invent them. NDMO's RMD.2.1 requires match-and-merge rules to be documented as requirements for exactly this reason, and SDAIA's National Data Index looks for survivorship rules embedded in data transformation and applications at maturity Level 3.

Stewardship is the product; the hub is the tool

Golden records decay unless someone maintains them. Duplicates arrive daily, sources change formats, and match rules produce borderline cases that need a human decision.

That is why stewardship carries the program. NDMO requires business and IT data stewards for every reference and master data object (RMD.4.1, Priority 1), a lifecycle process from creation to archiving (RMD.4.2), service levels for change requests (RMD.5.1) and three minimum KPIs (RMD.5.2):

• the number of incorrect values in master data records;
• mean time to repair reference and master data quality issues;
• the volume of change requests.

Those three measures are a good starting set anywhere, not only in Saudi Arabia. They describe whether the data is right, how fast it is fixed, and how much demand stewards carry.

Stewardship also needs a queue. Match candidates below the automatic threshold, survivorship conflicts and reference data change requests should land in a workflow with owners and deadlines, not in a shared mailbox.

Why AI raises the stakes

AI systems make master data problems more visible, not less.

A language model asked about "our largest customer in Riyadh" needs to know which records are the same customer. An agent that updates a supplier's bank details needs to know which system is authoritative, or it will update the wrong one. A retrieval system that indexes contracts, emails and tickets returns better answers when each document is tagged with the same customer or product identifier.

In each case, the master data key is the join between structured data, documents and actions. Organizations that invest in golden records and centralized reference data give their AI systems a shared vocabulary. Those that do not are asking models to resolve entities by guesswork, at scale. Our guide to RAG, fine-tuning and custom models explains why retrieval quality, not model choice, usually limits enterprise AI answers.

The Saudi picture: the RMD domain and national reference data

NDMO's Reference and Master Data Management domain has 6 controls and 18 specifications. Eight are Priority 1 and ten are Priority 2.

The pattern is the same one our NDMO implementation guide describes across the standards: Priority 1 asks entities to plan, identify, categorize, set requirements, choose a hub style and assign stewards. Priority 2 asks them to build and run the hub, set it as the trusted source for every new system, measure it and keep change logs.

Two national elements are easy to miss.

First, the hub style is not left entirely open. For reference data, the standards require centralized management in the entity's hub.

Second, reference data is meant to be shared nationally. SDAIA's National Data Index lists a Reference Data Management Platform (RDP) among the national data platforms it uses to measure entities. At maturity Level 3, the NDI asks for evidence that the entity participates in or uses national reference datasets, including screenshots of datasets it has shared on and consumed through the National Reference Data Platform. The Operational Excellence component tracks reference entities published by each entity, the time taken to publish new ones, and the time taken to fix reported issues.

The practical consequence for Saudi entities: before building a local list of, for example, administrative regions or service categories, check whether a national reference dataset exists and consume it. Before publishing an internal list as authoritative, confirm your entity is the rightful owner under RMD.1.3.

Choosing a style by domain

Use this table to decide, one domain at a time.

What to do in the next 90 days

1. List your master data domains and reference lists, and categorize each as internal or external.
2. For each master domain, record where records are authored today. Let that, not vendor preference, drive the hub style.
3. Name an owner for every critical attribute of your top two domains, and have them approve survivorship rules in writing.
4. Centralize the ten reference lists that cause the most reconciliation work, and map legacy codes to them.
5. Stand up a stewardship queue with service levels for match reviews and change requests.
6. Start measuring incorrect values, mean time to repair and change request volume.
7. In Saudi Arabia, check the national reference data platform before creating or publishing any reference list.

Frequently asked questions

What is the difference between master data and reference data?

Reference data is the set of permitted values used to classify other data, such as country codes, currencies and status codes. Master data describes the core entities a business transacts with, such as customers, products and suppliers. Reference data is small and slow-changing; master data is large, constantly changing and usually held in several systems.

What are the four MDM implementation styles?

Registry, consolidation (which NDMO calls repository), coexistence and centralized. They differ in where master records are created and whether the hub sends corrected data back to source systems. The right style depends on where records are authored and can differ by domain.

What is survivorship in master data management?

Survivorship is the set of rules that decides which value of each attribute wins when matched records from different sources disagree. Common rules rank sources by trust, prefer the most recent or most complete value, or send the conflict to a data steward.

What does NDMO require for reference and master data?

The Reference and Master Data Management domain has 6 controls and 18 specifications, 8 of them Priority 1. Entities must plan, categorize their reference and master data, choose a hub architecture, assign stewards, implement the hub as a trusted source, and measure performance. Reference data must be centrally managed.

Sources and further reading

• Data Management and Personal Data Protection Standards, Version 1.5, NDMO, SDAIA. Section 9.8, Reference and Master Data Management domain.
• National Data Index, Version 1.1, SDAIA, November 2024. RMD maturity questions and Operational Excellence metrics.
• Federal Reserve Board announces fine against Citigroup, Federal Reserve, 10 July 2024.
• Mars Climate Orbiter, NASA.
• Introducing the Legal Entity Identifier, GLEIF.
• 4 common master data management implementation styles, Stibo Systems (vendor material), June 2026.
• DAMA-DMBOK2R, DAMA International, 2024. Reference and Master Data knowledge area.