A banking app that works perfectly at home can fall apart on the first foreign payment. The domestic feed works because the same merchants repeat week after week: the supermarket, the transport operator, the coffee place near the office. The moment a customer lands abroad and taps their card, that repetition disappears, and the app has to answer a harder question from a single transaction record. A borderless banking app is the answer.
This is a build guide for what the data has to carry, and what the app can show once it does.
The question the app has to answer abroad
Open the app after a first payment in a new country and the customer expects the same thing they get at home: a name they recognise, a category that makes sense, a place they can picture. The domestic feed earns its trust quietly, because the merchant set is small and familiar, and the app has seen each name hundreds of times.
Abroad, none of that history helps, but the problem is not that the record is empty. The clearing message already carries a merchant descriptor, a terminal ID, a card acceptor ID, a merchant city and country, and a merchant category code. The problem is that this raw material is not good enough to put on a screen. The descriptor is not the brand, the category code is very broad and often wrong, and the city is a data string rather than a place. So, the useful way to think about an app that travels well is not as a feature list but as a chain: one transaction record, resolved from noisy inputs into clean ones, and then everything those clean fields support.
Why the raw descriptor is not enough
The merchant category code looks like a solution and mostly isn't. The MCC is set by the acquirer when the merchant is onboarded and rarely revisited, so it drifts out of date as businesses change. Catch-all codes absorb whatever does not fit cleanly, which means a large share of transactions land in generic categories. And even when the MCC is right, it identifies a type of business, never a brand: it will tell you a payment was to a restaurant, never which restaurant. A spending feed built on MCC alone is a feed of categories without names.
Location has the same problem. It arrives as a city data string, not coordinates and not a venue, so it can anchor a transaction to a country but not drop a pin the customer recognises. Turning "BEY LB" into a mappable point in Beirut is purely enrichment work.
The hardest case is the payment facilitator. When a customer pays a small merchant through a payfac like PayPal, SumUp, Zettle or Square, the descriptor leads with the facilitator's prefix, and the underlying merchant is buried behind it or missing altogether. This is where the real naming problem sits: the string names the data fasade, not the café. Getting to the café is the core of the work.
Why coverage behaves differently outside the home market
At home, recognition rests on repetition. Abroad, it rests on database breadth, and that is a different problem. A domestic merchant database only needs the merchants a bank's own customers actually visit, and a small set of high-frequency names covers most of the feed. This is the familiar Pareto pattern: a fifth of the merchants account for most of the transactions, so a modest database looks impressive at home.
That pattern is what stops helping abroad. A traveller's spending is the long tail: a café in one city, a museum in another, a car park, a pharmacy, a local supermarket chain the customer has never used before and never will again. Volume of transactions does not rescue you here, because the merchants a traveller hits are the ones outside the frequent set. What matters instead is how many markets the database genuinely covers, and how deeply.
There is a second, quieter problem. Payment terminals do not sit still. Around a quarter of terminals are replaced each year, on a three-to-four-year lifetime, which means the mapping between a terminal identifier and the merchant behind it keeps changing. Coverage is not a number you reach once. A merchant database that was accurate last quarter degrades unless it is refreshed, which is why an evaluation should treat coverage as a live figure.
Which leaves a bank two ways to get it. Build the foreign merchant database in-house and own the market breadth, the local-script names, the descriptor matching, and the terminal-churn refresh cycle as a permanent commitment. Or source it from an enrichment partner whose whole business is keeping that layer current across markets. For most banks the foreign feed is not where the in-house effort pays off, and it is the merchant-data problem that decides whether the app works abroad at all.
What the customer wants to see on a foreign payment
Four resolved fields carry the recognition. The merchant name, cleaned from the descriptor to the brand the customer knows. The logo, so the eye finds the transaction before the reader does. The category, resolved beyond the broad MCC to something specific enough to be useful in a summary. And the location, lifted from a city string to a point on a map. Together these turn an anonymous line into something the customer recognises at a glance.
Localisation is the part that only surfaces abroad, and it is easy to get the concept wrong. In an Arabic-language app, ماكدونالدز is a transliteration of McDonald's, and it is the correct thing to display. The real distinction is not between script and transliteration; it is between a merchant's registered local name and a machine transliteration generated on the fly from the descriptor. The registered name is reliable, the machine transliteration is not. Many merchants have no registered local-script name at all, and for those, falling back to the Latin brand is correct behaviour. What a data layer has to do is hold the registered local name where it exists and know when to fall back where it doesn't.
The difference is easiest to see in one before and after. In Riyadh, a payment arrives with a descriptor close to SumUp*Cafe 04378 RUH SA. Resolved, the same payment reads as a named café with its logo, a specific Food & Drink category, a location pin in the right district, and, in an Arabic interface, the café's registered Arabic name where one exists.
The trip view and how to build it
The feature travellers value most is the one they never have to set up. When each foreign payment carries a clean merchant, a category, a date, and a location, the app can group a set of transactions into a trip on its own: this cluster of payments, in this country, across these dates, adds up to this total, with this daily average. The customer opens the app after a week away and finds a spending summary of the whole trip without tagging a single line.
To build it, start from the resolved record and cluster on two axes the record already gives you, country and date range, then roll up the total and the daily average from the categories underneath. The grouping logic is simple. The work is making sure the records feeding it are clean, because trip grouping is derived data, and derived data inherits every mistake in the layer beneath it.
That is also where it breaks, so it is worth knowing the edge cases before they reach a customer. If half the payments on a trip resolve and half arrive as unresolved descriptors, the app does not throw an error. It shows a trip that is missing days, a total that is too low, and a set of unknown lines the customer cannot place. The summary looks finished but is wrong, which is worse than showing nothing, because the customer trusts it.
Cash abroad
Cards do not cover a trip end to end, and travellers still reach for cash, so a borderless app usually needs an ATM-finder module. It is a different data set from merchant enrichment, with its own coverage, and it belongs in the app as its own component: nearest machines on a map, each with operator, distance, fees and accessibility, so the customer can choose before walking rather than discover the cost at the keypad.
The pricing detail that matters most is that on a foreign-currency card, the operator fee and dynamic currency conversion (DCC) together can add as much as 12% to a single withdrawal, and which machine the customer lands at is largely luck of the network: in Prague, non-bank operators run 87% of the machines at the main station and more than 63% in the historical centre, and independents are 75.6% of the London network against 20.5% in Amsterdam, where the big three merged their machines into Geldmaat.
See the full picture in the Prague ATM analysis.
The business case and where the data comes from
The reason to build any of this is not only experience, it is cost. Unrecognised foreign descriptors are a direct driver of contact-centre volume: a customer who does not recognise a line calls to ask, or files an "I don't recognise this" dispute, and both land on teams the bank pays for. Every foreign payment resolved to a name the customer knows is a call and a dispute that never happens. That is the internal case for enrichment, and it usually outweighs the UX argument on its own.
Given that, the sourcing question is not whether to buy but how to choose, and the best practice for integrating an enrichment API treats the provider as a structural layer with an update mechanism, not a one-off data drop. Five checks separate a provider that will hold up abroad from one that looks good in a home-market demo. First, foreign coverage: not the headline market count, but recognition rates on merchants outside the provider's strongest regions. Second, localised names: whether registered local-script names are held where the app language needs them. Third, ATM data: whether cash-machine location, operator, and fee information are available, remembering that ATM coverage is a separate footprint from merchant coverage and the two figures should never be conflated. Fourth, response time: whether enrichment is fast enough to run inline within the authorisation budget. Fifth, confidence and fallback: whether the provider returns a confidence signal and a clean descriptor to fall back on, rather than forcing a guess.
One check sits outside the data quality itself and procurement asks it first: where is the data processed, and does it leave the EEA? Third-party processing, outsourcing rules and DORA obligations make the answer material, and it belongs in the build-or-buy decision from the start. The only reliable way to test the rest is a proof of concept on the bank's own foreign-transaction sample.
A useful vendor comparison is a good starting point, but nothing substitutes for running your own tail of transactions through it.
Tapix covers these checks. It resolves merchant name, logo, category and location for foreign transactions through a single API, holds ATM data as a separate module covering most of Europe plus Singapore, Dubai, Colombia and Egypt, and covers 112+ active markets for merchant enrichment. Whether you source the data here or elsewhere, those checks are what a borderless banking app is built on: an app that works the same abroad as it does at home, because the record underneath it does.
