Updating the Record the Moment It Changes

Opening Scene

Most of the registry’s reconciliation work happens on a steady rhythm — a weekly review where a clerk works through the week’s accumulated filings, matching and merging in a batch. That rhythm works fine for most corrections; a citizen’s file being fully accurate by next Tuesday instead of this afternoon rarely changes anything important. But when a citizen reports their identity has been fraudulently used to open accounts at three different offices this very morning, the registry can’t wait for Tuesday. A dedicated fast-lane process kicks in immediately, reconciling and flagging the affected files within the hour, because in this specific case, the delay itself is the risk.

Master data management faces the same real tradeoff, and the right answer depends entirely on the specific case.

In Plain English

Batch MDM reconciliation processes matching, merging, and propagation on a scheduled cadence — nightly, hourly — accumulating changes and resolving them together in a single pass. Real-time MDM matches and reconciles a change the moment it occurs, keeping golden records and their downstream consumers continuously current with minimal lag. Batch processing is simpler to build, easier to reason about, and computationally more efficient per record, since it can take advantage of processing many changes together at once. Real-time processing costs more in architectural complexity and computational overhead, but eliminates the staleness window that batch processing always carries between reconciliation cycles — a window that matters enormously for some use cases and barely at all for others.

The Old Way

Before real-time MDM was broadly practical, most organizations operated almost entirely on batch cycles, learning where that staleness window genuinely hurt:

Batch’s staleness window is invisible until it isn’t — most of the time, a customer record being a few hours or a day stale causes no visible problem at all, which is exactly why batch became the default; the cost only becomes visible in the specific, less common cases where timing genuinely matters, like fraud detection or a customer who just updated a critical preference and expects it respected immediately.
Fraud and risk use cases were usually where organizations first felt the need for something faster than batch — a compromised account or a suspicious pattern spanning multiple systems needs a reconciled view within minutes, not by the next scheduled batch run, which is why real-time reconciliation historically got carved out first for exactly these high-stakes, time-sensitive cases.
Full real-time reconciliation across every master data domain was, for a long time, prohibitively complex — building genuinely real-time matching and propagation across a whole organization’s master data was a significant architectural undertaking, so most organizations settled for a hybrid: real-time for a narrow set of high-stakes use cases, and batch for everything else.

The core lesson from this era still holds even as real-time approaches become more practical: match the reconciliation cadence to the actual cost of staleness for that specific use case, rather than defaulting to one approach for everything.

What’s Changing (and Why AI Is the Reason)

AI-based matching models, especially those using pre-computed embeddings and approximate nearest-neighbor search covered in Article 13, make real-time matching computationally practical for a much wider range of use cases than it used to be, since a new record can be matched against the existing golden record set in near real time rather than requiring a batch-oriented full comparison pass.
AI-assisted use-case prioritization can help identify which specific master data domains and fields genuinely benefit from real-time reconciliation versus which are well served by batch, based on measurable downstream impact of staleness, rather than defaulting to an expensive blanket real-time architecture everywhere or an overly conservative blanket batch approach everywhere.
AI agents operating continuously, rather than on a human’s schedule, raise the practical stakes of staleness in new ways — an agent processing a customer request at 2 a.m. has no “wait until tomorrow’s batch run” fallback the way a human employee implicitly did, making real-time reconciliation more valuable specifically wherever AI agents are expected to act autonomously and continuously on master data.

The Metaphor, Fully Extended

Registry Element	Master Data Management Concept
The registry’s weekly reconciliation review, working through the week’s accumulated filings together	Batch MDM reconciliation, processing changes on a scheduled cadence
The fast-lane fraud process reconciling an affected file within the hour	Real-time MDM, reconciling a change the moment it occurs
The invisible cost of a citizen’s file being a day stale, unnoticed almost all of the time	Batch’s staleness window, usually harmless but occasionally costly depending on the use case
A hybrid registry running weekly batches for most cases and a fast lane reserved for fraud	A hybrid MDM architecture, real-time for high-stakes domains and batch for everything else
A registry assistant identifying which specific offices’ cases actually justify the fast lane	AI-assisted use-case prioritization, matching reconciliation cadence to measured staleness impact

For Beginners: What to Actually Do

Practice asking, for any master data use case, what the real cost of a stale value would actually be — a concrete answer to that question is what should drive the batch-versus-real-time decision, not a general preference for “faster is better.”
Get comfortable with the idea that batch processing is a reasonable, often correct default, not a legacy approach to be automatically replaced.
Notice which use cases in your organization already run on something faster than the standard batch cycle — fraud and security use cases are the classic examples — and consider what makes those cases different.
Understand that real-time MDM carries genuine architectural cost, so treat “should this be real-time?” as a real tradeoff question, not a question with an obvious universal answer.

For Practitioners and Leaders: The Deeper Layer

Build a hybrid MDM architecture deliberately, reserving real-time reconciliation for domains and use cases where measured staleness cost genuinely justifies the added complexity, and using batch everywhere else.
Use AI-assisted, embedding-based matching to make real-time reconciliation more practical for a wider set of use cases than was previously feasible, while still weighing the real computational and architectural cost involved.
Reassess your batch-versus-real-time boundaries as AI agents increasingly act autonomously on master data, since an agent operating outside human working hours removes the implicit staleness tolerance a human-in-the-loop process used to provide.
Quantify staleness cost explicitly per use case — in dollars, risk, or customer experience terms — rather than relying on intuition, to make the real-time investment decision defensible and revisitable over time.

Quick Recap

Batch MDM reconciles changes on a scheduled cadence; real-time MDM reconciles changes the moment they occur, trading architectural simplicity for reduced staleness.
Most use cases tolerate batch’s staleness window fine; fraud, security, and other time-sensitive cases have historically been where real-time reconciliation was first justified.
AI-based embedding matching makes real-time reconciliation practical for a wider range of use cases, and AI-assisted prioritization can help target where it’s genuinely worth the cost.
Autonomous AI agents operating continuously raise the practical stakes of staleness, since they lack the implicit tolerance a human-scheduled process used to provide.

Where This Fits in the Series

Article 17 covered feeding trustworthy data into AI features; this article covered how quickly that data actually needs to become trustworthy. Article 19 closes the AI-focused arc by addressing when full MDM is genuinely overkill.