The case for making the MDM Application a synchronous or upstream step in data creation, rather than a downstream reconciliation layer, tends to rest on a few arguments.

---

Prevent duplicate creation instead of cleaning it up after. If a new counterparty or asset record is checked against the MDM Application before creation, you catch duplicates at the point of entry rather than merging them retroactively. Post-hoc match/merge always leaves some window where duplicates exist in downstream systems and reports, and any consumer that pulled data during that window has already inherited a fragmented view. Gating at creation closes that window entirely.

Golden ID exists from birth. If the MDM Application issues the master ID at creation time, every downstream system references the same identifier from day one. There’s no reconciliation step later where historical records need to be retrofitted with a golden ID once a match is found. This matters especially for financial or contractual data at the business, where an asset or counterparty ID may get baked into transactions, agreements, or reporting almost immediately.

Single source of truth is enforced structurally, not by convention. If creation is optional to route through the MDM Application, some source systems will inevitably skip it, and MDM becomes advisory rather than authoritative. Making the MDM Application part of creation removes that dependency on process compliance, but it also requires a clear decision up front on which data is then to be created and maintained in the MDM Application and which is to reside in the core systems. Identifying attributes such as legal entity name, registration or tax identifiers, and ownership hierarchy fall clearly within the MDM Application’s remit, since they define who the counterparty or asset is regardless of which system touches it. Transactional and system-specific attributes, such as account balances, trade positions, credit limits, or product terms, just as clearly belong in the core systems that originate and process them; forcing those into the MDM Application would relocate the reconciliation problem rather than remove it.

Data quality and enrichment happen before propagation, not after. Attributes like standardized naming, hierarchy placement, or ontology classification can be validated or enriched before the record ever reaches downstream consumers, rather than downstream systems consuming a “dirty” version that later gets corrected in place.

Fewer downstream corrections and re-syncs. Every time the MDM Application merges records after the fact, downstream systems that already consumed the pre-merge version need a correction event. If merge conflicts are resolved before creation, that correction traffic largely disappears.

Fewer fields get locked for editing once they are in use. Some attributes cannot be changed after the fact at all, regardless of how good the downstream correction process is. Unit of measure on a material is a common example: once transactions have been posted against it, many systems will not allow the field to be changed without a full re-creation of the record. For attributes like this, getting the data right at the point of creation is not just preferable but essential, since there is no reconciliation step downstream that can fix it later.

The tradeoff, which is the counterargument, is that this adds latency and an availability dependency to every write path that creates a master entity, and the MDM Application’s matching algorithms are generally tuned for eventual-consistency batch or near-real-time matching rather than hard synchronous gating. Whether the trade-off is worth it usually comes down to how frequently the business creates genuinely new master entities (which is probably low-volume, given asset and counterparty creation isn’t a high-throughput transactional process) versus how costly downstream duplicate/reconciliation cleanup has been in practice.

There is also a vendor lock-in dimension to the trade-off. Once the MDM Application sits synchronously in the creation path, its API, matching logic, and identifier scheme stop being a replaceable downstream layer and become load-bearing infrastructure that every upstream system depends on just to create a record. Integrations, workflows, and even the golden ID format get built around that specific vendor’s behaviour. Migrating to a different MDM product later means re-architecting the creation path itself, not swapping out a downstream sync job, which carries a materially higher switching cost than keeping the MDM Application optional and downstream.

There is also a false-positive cost to weigh against the false-negative cost the arguments above focus on. Synchronous matching does not just catch duplicates, it can also wrongly flag a genuinely new counterparty or asset as a match against an existing record and block its creation outright. A bad merge in a downstream reconciliation layer can usually be reversed once discovered; a blocked creation at the point of entry stops the business process cold until someone resolves the match manually.

Making creation depend on the MDM Application also raises a design question that the latency point only partly covers, namely what happens when the MDM Application is unavailable. Without a fallback path, an outage halts creation of new master entities across every source system that gates through it. A synchronous design needs an explicit answer, whether that is a queued asynchronous fallback, a manual override, or an accepted period of blocked creation, rather than leaving it as an implicit assumption.

There is also an integration cost to the synchronous approach that a downstream reconciliation layer does not carry. Every source system that creates counterparty or asset records needs its own synchronous integration point to the MDM Application, rather than feeding it asynchronously after the fact. Each of those integration points is a new potential failure surface, and building and maintaining them across every source system is a materially larger effort than maintaining a single downstream feed.

Beyond the technical tradeoffs, gating creation through the MDM Application is also an organisational change. Source systems currently create counterparty and asset records under their own authority, and making the MDM Application a mandatory step shifts that authority to a central function. That shift can meet resistance independent of whether the technical case is sound, and is worth planning for as a change management effort rather than treating it as a side effect of the technical rollout.

Finally, the choice does not have to be a strict binary between synchronous gating and downstream reconciliation. A hybrid approach, such as a real-time duplicate check that flags likely matches for human review while still allowing creation to proceed asynchronously, can capture some of the duplicate-prevention benefit without taking on the full availability dependency of a hard synchronous gate. Whether that middle ground is worth the added process complexity comes down to the same volume and cost tradeoffs already at play.