Real-time data enrichment and batch enrichment produce the same output: a clean merchant name, logo, category and location attached to a raw transaction. What differs is when that output exists, and that timing decides which features a bank or fintech can ship, how readable its statements are, and how far its analytics can be trusted.
This guide covers the trade-offs between the two models, the reference architecture most teams end up with, and how enriched records stay correct after they have been written.
What transaction enrichment really changes
Enrichment is often treated as a cosmetic upgrade: replacing “B2B PRIME*OK8ST8II5” with a clean merchant name in the app feed. That framing undersells it, and it leads to poor decisions about where enrichment should run.
Enrichment does three jobs, and each one has its own timing requirement.
Merchant resolution: A raw description is matched to a specific shop (a physical location or online storefront) and that shop to a merchant brand. Resolution is what lets a bank know that three differently formatted strings are the same coffee chain, which is the foundation for everything else.
Statement clarity: Customers recognise brands. When the feed, notifications and statements show a name and logo the customer knows, fewer transactions look suspicious, and fewer turn into support calls or disputes and chargebacks.
Downstream analytics: Spending insights, subscription detection, credit and affordability models, and BI dashboards all connect by merchant and category. If resolution is inconsistent, every connection can be wrong.
Want to know more? Learn about data quality in digital banking.
So the first question is not “should we enrich?” but “which consumers need structured data, and how soon?”
Real-time vs batch: latency, cost and accuracy trade-offs
The choice comes down to three variables. Neither model wins on all of them.
Latency: Real-time enrichment returns structured data in milliseconds, inside the transaction processing path. Batch enrichment leaves a gap, the batch window, between the moment a transaction happens and the moment it becomes readable. With a nightly job, a payment made at 14:32 stays a raw string until the next morning.
Cost: Batch is cheaper to operate. It adds no synchronous dependency to the payment path, needs no high-availability guarantees, and can run when compute is idle. Real-time enrichment means owning a call that must be fast and available whenever transactions flow, with timeouts and fallbacks designed around it.
Accuracy: This is the trade-off most teams overlook. At authorisation, some input fields can be missing or incomplete, since they often arrive later with settlement. Batch jobs see the fuller record. Real-time enrichment closes that gap by re-requesting enrichment at settlement and by re-enriching records when the underlying merchant data changes (covered below), so it does not have to trade accuracy for speed.
When batch enrichment is the right choice
Batch fits wherever nobody is waiting on the result:
- Analytics and BI dashboards, where overnight latency is acceptable and consistency matters more than speed.
- Regulatory and compliance reporting, which runs on a fixed schedule.
- Historical backfill, when a bank launches enrichment and needs years of past transactions structured, or migrates customers from another system.
- Monthly statements, which are generated in batch anyway, provided the batch window closes before statement generation.
When real-time enrichment is required
Real-time is a requirement for any feature that acts on a transaction as it happens:
- Push notifications that fire seconds after a payment must carry a clean merchant name. A raw description in a notification lowers trust and generates support volume.
- Transaction search built on raw strings misses results. A customer searching for a merchant won’t find transactions indexed under an acquirer description.
- PFM and budgeting need correct categories at the point of spend, otherwise budgets update retroactively and inconsistently.
- Subscription detection depends on structured merchant data. A batch window is a blind spot during which recurring charges can be missed.
- Fraud and dispute review needs merchant location, category and brand immediately to cut investigation time and false positives.
Reference architecture: the four stages pipeline
Most banks that run enrichment at scale use a hybrid model. Real-time enrichment sits in the ingestion path for all customer-facing data, and batch handles backfill and bulk reprocessing. The pipeline has four stages.
1. Ingestion: The transaction arrives from the card processor, A2A rail or open banking connection. For card payments, the most useful inputs are the description, merchant ID, terminal ID, MCC, city and country. The more complete the input, the more reliable the resolution.
2. Enrichment: The transaction is sent to the enrichment service, ideally at authorisation, exactly once. The service resolves it to a shop and returns an identifier. If settlement later supplies fields that were missing at authorisation, the transaction can be re-requested to refine the result. Batch endpoints handle the same resolution for large historical volumes.
3. Persistence: Store the enrichment reference alongside each transaction, and keep shop and merchant details (name, logo, category, location) in separate tables. Shop and merchant data is shared across millions of transactions, so details only need fetching when an identifier appears for the first time. This normalised model is also what makes updates cheap: one corrected merchant record fixes every transaction that points to it. Logos should be stored and served from your own infrastructure rather than hot-linked.
4. UI and decisioning: The feed, notifications, search index, PFM layer, fraud tooling and analytics warehouse all read from the same enriched records. No consumer needs its own compensating logic for raw strings, and analytics consumes data that is already enriched instead of depending on a batch job to create it.
The most consequential error here isn’t picking the wrong model. It’s placing enrichment in the wrong position. Many banks find enrichment running after the notification layer and after the search indexer: the data gets cleaned, but too late for the features that need it.
Keeping enriched data current: updates and event-driven re-enrichment
Enrichment is not write-once. Merchants rebrand, logos change, shops move, and new merchants appear that weren’t resolvable when their first transaction arrived. Any architecture needs a mechanism to push those changes into stored records. There are two common approaches.
Cache expiry: Stored shop and merchant data is given a time-to-live. Once it expires, the next transaction at that shop triggers a fresh lookup. It’s simple, but data can stay stale for the full expiry period, and rarely visited shops refresh equally rarely.
Event-driven re-enrichment: The enrichment provider notifies the bank when specific shop or merchant records change, usually through an invalidations feed. The bank re-fetches only the affected records, and because transactions reference shared shop and merchant tables, every linked transaction is corrected at once. The same mechanism handles unresolved transactions: the bank stores the reference, and when the provider resolves that merchant later, it arrives with the invalidations as a signal to re-request.
Event-driven re-enrichment is how a real-time architecture catches up to the batch accuracy. The first pass is fast, corrections follow as soon as better data exists, without reprocessing the whole history.
What to evaluate in a real-time or batch enrichment provider
If you’re comparing providers that support both processing modes, these are the questions that separate them:
- Latency and availability under production load, measured on your own traffic, since enrichment sits in a synchronous path.
- Batch support for historical backfill and bulk reprocessing, through the same resolution logic as the real-time API.
- Update mechanism. Does the provider push shop and merchant-level changes, or rely only on cache expiry on your side?
- Unresolved transactions. What happens when a merchant can’t be identified on the first call, and how does the later resolution reach you?
- Resolution depth. Is the result tied to a specific shop and location, or only to a brand name?
- Input flexibility across card, A2A, QR and open banking data.
Learn how to select the right data enrichment provider for your business.
How Tapix fits
Tapix is built for the hybrid model. Its API runs in real time at ingestion, returning clean merchant names, logos, categories and location data with a 6ms API response time. Batch endpoints cover historical data and bulk volumes, and the Invalidations API pushes shop and merchant-level changes so stored records stay current without reprocessing. Integration details are documented on the developer portal.
The decision between real-time and batch enrichment is ultimately a decision about product ambition. Batch answers the question “what happened?”. Real-time, kept current through re-enrichment, lets the bank act while it’s still happening.
