Every personal finance management feature a bank ships sits on one thing: the quality of the transaction data underneath it. Categories, spending summaries, subscription alerts, carbon insights, an agent that cancels a forgotten trial. None of them work if the raw payment record is a chaotic string and a four-digit code. A PFM is only as good as the enrichment beneath it, and as those features start acting on the data, it becomes the whole foundation.
What enrichment is
Transaction data enrichment turns a raw payment record into something a person can read. A card authorisation arrives as a merchant string, an amount, and a merchant category code. The string might say SQ *COFFEE 0421 LON or PAYPAL *SPOTIFY. Enrichment resolves that into a clean merchant name, a logo, a category, a location, and whatever context the feature needs, before it ever reaches the customer.
Everything downstream inherits this. If the enrichment is wrong or missing, every feature built on top inherits that too.
Why granularity decides the PFM
A personal finance management view works when the categories are right, and "right" is mostly a question of granularity. Too broad and the overview tells the customer nothing. Too fine and it becomes a filing system no one maintains. The fastest way to lose a customer is the "Other" category, because every transaction that lands there is one the enrichment could not resolve, and a fat "Other" slice reads as the app not knowing where the money went.
Granularity has a second axis the label alone misses: what the payment was for. A charge to a card processor tells you who was paid, not what was bought. A subscription tag sits on top of a stable merchant match and turns "a payment to a merchant" into "a monthly subscription to a book service", the thing the customer recognises. That distinction between who and what for is where a lot of PFMs fail.
There is a working sequence behind this:
- Categorise spend beyond MCC with intent-based, customer-readable categories.
- Reduce "Other" by resolving merchant identity and brand logo first.
- Add subscription and recurring tags on top of a stable merchant match.
- Improve PFM insights and dispute handling with clearer context per transaction.
And it has to hold across every payment type, not one. A PFM ingests card transactions and ATM withdrawals, bank transfers, QR payments, and open banking data under PSD2, and each arrives in a different shape. Transfers and open banking feeds are harder to enrich than card data, because there is no merchant category code and often no clean merchant reference, only a free-text field entered by the sender. A PFM built into a banking app that categorises cards well but drops every transfer into "Other" is still a broken overview.
Granularity beyond MCC
To see why this is hard, look at what banks are usually working with: the merchant category code. MCCs are 1980s infrastructure, four-digit codes built for fraud routing and interchange, assigned at the terminal or acquirer level rather than to the merchant itself. There are only a few hundred of them, and a single business can be tagged with several depending on which terminal a payment runs through.
Costa Coffee is the standard illustration. Look at where its transactions actually land across MCCs and you get a scatter, not a category:
One merchant, five codes, and none of them says coffee. Roughly one transaction in three lands somewhere other than "restaurant", so a PFM leaning on MCC alone scatters a single coffee chain across half the food menu (Tapix analysis).
The gap widens the moment you want context beyond the label. On MCC, a ski resort, a FlixBus coach ticket, and a Lime e-scooter hire all read as "Travel". For a spending overview that is extremely vague; for a carbon feature it is wrong, because the emissions profile of a mountain gondola, an intercity bus, and a shared scooter could not be further apart.
This is the gap enrichment closes. Rather than trusting the terminal code, Tapix categorisation cross-references the merchant against 500+ side tags and other signals to narrow the category and, where it matters, attach the right multiplier. This is why MCC codes do not help much with payment categorisation once you move past the basic grouping.
What breaks when people travel
The customer flies abroad, and this is exactly when they open the app. A holiday or a work trip is peak PFM usage: unfamiliar currency, unfamiliar merchants, and a real need to check what just got charged. It is also where locally trained enrichment falls apart. A model tuned on domestic merchants has never seen the corner restaurant in Lisbon or the transit operator in Tokyo, so foreign transactions drop into "Other" at the precise moment the customer is watching most closely.
Global coverage is the requirement here. Enrichment that stays legible at home and abroad means the merchant, the category, and the logo resolve whether the payment happened down the road or on another continent. Tapix runs across 112+ markets with 800k+ merchants in the database, and can launch enrichment in a new market in a matter of weeks, because the global dataset, human verification, and matching pipeline are already built rather than assembled per country. That is what lets the overview hold together when customers cross borders, rather than breaking exactly where it is most watched.
What reliable data unlocks
Once the feed is clean, the features stack up on the same foundation.
Notifications are the re-engagement loop. A push that says "£4.20 at Costa Coffee, Old Street" earns a glance and a tap; a push that says "£4.20 at SQ *COFFEE 0421" earns a support ticket, or worse, a fraud query. The notification is only worth sending when the merchant name and category are clean, which means the enrichment has to be right before the message goes out.
Subscriptions surface the same way. Recurring charges are detectable when the tags are reliable, streaming, software, energy, gym, and roughly half of customers in the region carry at least one (Tapix analysis, CEE). Surfacing them, with frequency and next billing date, is the difference between a customer who trusts the app to watch their money and one who finds the forgotten trial on their statement three months late. This is the basis for recurring payments intelligence, and it runs on exactly the same enriched feed as the notifications.
It also happens to be a compliance requirement now. The Visa and Mastercard mandates on recurring transactions expect verified merchant detail and genuine recurring-payment control, so the enrichment that powers the customer-facing subscriptions view is the same layer that satisfies the scheme rules. One data foundation serves the feature and the mandate at once, which is worth remembering when subscription work gets scoped as either "product" or "compliance" and funded as only one.
What it looks like when banks go deeper
The banks that push enrichment furthest show what the ceiling looks like, and readers will recognise the names.
Raiffeisen Bank built carbon insights on enriched transaction data for more than a million mobile customers, using carbon footprint insights to show the environmental context of spending. The framing is customer education, helping people understand the footprint behind everyday purchases, not surveillance of what they buy. It only works because the underlying category is right. Estimate CO2 off a miscategorised transaction and the number is misleading in a way an environmentally engaged customer spots immediately.
bunq leans on enriched data to give customers a clean, readable spending picture inside a product built around simplicity, where an unresolved merchant would stand out at once. Monzo's "Year in Monzo" is a different flavour of the same principle: their engineering team built spending "eras", trip reports, and categorised annual roundups on merchant-level detail, turning a year of transactions into something people shared. That is Monzo's own engineering account, but it shows what merchant-tier data makes possible. Revolut does something similar with Trips and Net Worth, folding enriched transactions into travel summaries and a running picture of where money sits. Different products, one precondition: none of it renders without clean merchant and category data underneath.
Is the future of PFM dead?
The pie chart of last month's spending was always a passive artefact, something you looked at and closed, and the next generation of PFM does not just show you the money, it acts on it. Agents already flag a price rise, cancel or block a subscription you forgot, and warn you before an overdraft charge lands. PFM is becoming agentic.
Which raises the stakes on the data. A chart built on a miscategorised transaction is a small annoyance; you notice the wrong label and move on. An agent built on the same bad data cancels the wrong subscription, blocks a payment you needed, or reassures you about a balance that is about to go negative. When software acts on your behalf, a mistake in the underlying data is a wrong action taken in your name. Clean, trusted, enriched data is precisely what makes it safe to let software act at all.
See how enriched data compares on your own transactions in the Tapix sandbox.
