Tapix CEO says banks should test payment enrichment on their own data

Banks and fintechs risk poor vendor choices if they assess payment data enrichment providers through sales claims rather than tests on their own transactions, according to Ivan Dovica, CEO of Tapix by Dateio. In a Finextra Community opinion post, Dovica said raw payment records often need cleaning, categorisation and merchant resolution before they can support dispute handling, credit assessment or customer-facing finance tools.

Dovica argued that procurement teams should begin by defining the business purpose of enrichment. He cited several different objectives: cutting support contacts over disputed transactions, improving categorisation used in affordability models, and powering personal finance features for customers.

Those use cases require different outputs, he said. A provider that performs well on merchant names and logos for consumer interfaces may not be the strongest fit for a credit-risk process that requires consistent categories across a large transaction base.

Proof of concept as the central test

Dovica said the most useful evaluation step is a proof of concept using a representative sample of the institution’s own raw transaction data. He said published accuracy figures reflect a vendor’s broader client base, rather than a bank’s markets, customer base or mix of local merchants.

The mechanism is straightforward: enrichment providers take transaction identifiers and attempt to convert unclear acquirer strings into usable merchant information, categories and related data fields. Dovica said buyers should review how a provider treats payments routed through gateways, small regional merchants and category assignments at the level of detail required by the institution.

He warned that confident but incorrect enrichment can create downstream problems if it is repeated across large volumes of records. In his view, the proof of concept should measure record-level accuracy rather than the number of enrichment fields a vendor can list.

Coverage, security and integration

Dovica separated coverage from accuracy. Vendors may offer merchant names, logos, locations, websites, categories, gateway indicators, subscription flags and sustainability signals, he said, but buyers should ask what share of their transactions is populated for each field and how reliable each field is.

He also said API-based enrichment raises data-sharing questions because transaction data leaves the bank or fintech and is processed by a third party. Dovica described GDPR compliance as a baseline expectation and said an information-security certification such as ISO 27001 is a reasonable requirement for providers handling the data at scale.

According to Dovica, institutions should establish what information is retained, for how long, where it is processed and the minimum data set needed to perform enrichment. He said a well-designed provider should not require sensitive personal information if payment identifiers are sufficient for the task.

Integration is part of the product, Dovica said. He argued that providers should support real-time enrichment at or near the transaction moment as well as batch processing for later analytics, since institutions may need both paths.

Cost and market experience

Dovica said buyers should assess price against the value of the enriched data and the total cost of obtaining and maintaining it. He also said in-house enrichment can appear cheaper until the ongoing work of maintaining merchant knowledge bases is included.

Market experience matters, he added, because merchant data varies by region and segment. Dovica cautioned that a provider strong in one market may perform poorly elsewhere if it has not seen enough comparable transactions, and said enrichment quality tends to reward specialist focus.

Finextra identified the post as external content by Dovica, published without editing and reflecting the author’s views.

This story draws on original reporting from Finextra Research.