Banks urged to treat transaction enrichment as core data infrastructure

Banks that add merchant names, logos and categories to transaction feeds can create large volumes of customer-facing errors if they assess integrations on coverage rather than accuracy, according to Martin Korbelar, CEE sales director at Tapix by Dateio. In a Finextra community post, Korbelar said a bank processing 10mn transactions a month would generate 50,000 incorrect customer experiences at a 0.5 per cent obvious misclassification rate.

Korbelar argued that many disappointing enrichment projects fail because banks treat the work as a visual improvement to the account feed rather than as a data layer used by multiple products. The initial implementation may make raw card descriptors easier to read, but later weaknesses can appear in push notifications, personal finance tools, merchant search and subscription detection, he said.

Purpose determines the architecture

Transaction enrichment converts unstructured payment descriptors into more usable information, such as merchant identity, category, logo or recurring-payment signals. Korbelar said banks first need to decide which systems will rely on those fields, because the answer determines latency needs, storage design and update frequency.

He distinguished between use cases with different operating demands. A cleaner transaction feed may tolerate older data. Push notifications require enrichment fast enough to appear while the transaction is still relevant to the customer. Budgeting and categorisation features need enriched data both quickly and persistently. Analytics can often use batch processing, where consistency during reprocessing may matter more than speed.

If those choices are postponed, Korbelar said banks often have to redesign the integration after customers have already encountered inaccurate or incomplete results.

Accuracy over coverage

Korbelar said vendors often promote enrichment coverage above 95 per cent, but he argued that error rates are more closely tied to customer experience. A blank field may be noticed less than a confidently wrong merchant name or spending category, which can prompt disputes or complaints, he wrote.

He said buyers should define accuracy with precision, because merchant matching and categorisation are separate problems. A provider may perform well on one and poorly on the other. Banks should also examine whether categories remain consistent for the same merchant family, whether performance holds on foreign transactions, and whether corrections flow back into the service after errors are identified.

Korbelar recommended testing vendors against six to twelve months of the bank’s own historical transactions, including difficult cases such as overseas spending, poor point-of-sale strings, recurring payments and payment-gateway artefacts. He said banks should measure how many transactions fall into “Other”, the obvious misclassification rate, brand grouping consistency and whether repeated processing of the same dataset produces stable results.

Data flow and storage choices

The integration design then depends on when enrichment occurs and what the bank stores, according to Korbelar. Enrichment can run during authorisation, after settlement or in batches. Authorisation-time processing supports real-time features but creates tighter latency requirements. Post-settlement and batch approaches reduce operational pressure but limit real-time customer uses.

Korbelar said enrichment should not block core transaction processing. If enrichment fails, the raw transaction should be stored and revisited later, while downstream systems should continue to function with partial data.

He also argued that raw financial transactions should remain immutable, with enrichment treated as an interpretive layer. Rather than attaching enriched fields only to each transaction, he said a more durable model stores shop and merchant objects separately, allowing transactions to reference stable identifiers. That structure supports search, merchant grouping, subscription logic and analytics, according to Korbelar.

Enriched data also needs maintenance, he said, because brands, logos, terminal mappings and models change. Banks can refresh records on a schedule or update only objects flagged by change events. Korbelar said teams must also decide whether historical transactions should be updated when enrichment improves or preserved as the customer saw them at the time.

This story draws on original reporting from Finextra Research.