At a glance
Holvi serves entrepreneurs and small businesses, and many of its customers do their own bookkeeping. Banking and bookkeeping sit in the same account, so a transaction line in Holvi feeds straight into the customer's books. So every line has to name the merchant behind the payment.
Card networks do deliver a merchant name, but often as the official business name or a shortened descriptor rather than the name the customer would recognise. A fuel stop at an St1 station in Nurmijärvi reaches a banking app as this line:
1673 ST1 NURMIJ Nurmij?rvi
Of that line only the chain name is directly readable. The ä in Nurmijärvi did not survive the network's character set and arrives as a question mark, and the 1673 in front is a terminal reference.
Across card issuing, transactions a cardholder can't place generate support contacts and disputes against payments they actually made. That same line then has to be categorised and matched to a receipt before the customer can close the month.
"Our customers are entrepreneurs, not accountants. If a card payment arrives as a string of letters and numbers, someone still has to work out what it was before it can go into the books."
Janna Lindholm, Payment Expert at Holvi
What Holvi needed was specific. A customer looking at a card payment had to know who they paid, what kind of business it was and where, without opening a receipt or searching for the merchant. A cleaned up merchant name on its own would not get them there.
That is a judgement you can only make by looking at the output. So before committing, Holvi sent Triple a sample of its own card transactions and had enrichment run across the full set, on the merchants its customers pay every day. Triple was selected on that output.
Holvi sends each raw transaction to one Triple endpoint. For the St1 payment above, this comes back:
Fields that do not apply to a transaction come back empty. This payment went straight to the merchant, so there is no aggregator to resolve. A payment arriving as PAYPAL *EASYPARK comes back with EasyPark as the merchant and PayPal as the processor, and the customer sees both.
Holvi decides which fields to show and how. Merchants arrive in card data in shapes like these:
Payment processing is untouched and there is no migration. Holvi signed in November 2025 and the API integration was complete by the middle of January. The work after that sat in Holvi's own front end, where the team decided how an enriched transaction should be presented.
The large majority of Holvi's live card transactions now resolve to a recognised merchant, measured on full production volume.
Merchant name, category and location turn a transaction list into something a business owner can work from directly: spending that sorts itself, subscriptions that surface before they are forgotten, and a month end that starts from a list that already makes sense.
"Our customers run their business finances in Holvi. Cards, payments, bookkeeping, all in one place. Clean transaction data, powered by Triple, makes that useful in practice: they can see what they spent and where, without having to piece it together themselves. Many of them do their own books, so that means real time saved every month."
Janna Lindholm, Payment Expert at Holvi
Triple is the enrichment layer underneath a bank's own product. We take the raw descriptor the network delivers and return the merchant behind it, with the category, the location, and flags such as recurring subscriptions and the processor sitting behind an aggregated payment.
Issuing banks, fintechs and issuer processors across Europe run it on card transactions and bank transfers through one API.
Test us on your own transactions, the way Holvi did! → Contact sales
