Payment Industry Blog

Every feature in a personal finance app - categories, spending summaries, subscription alerts, carbon insights, even an agent that cancels a forgotten trial - sits on one thing: the quality of the transaction data underneath. Here's how enrichment turns raw payment strings into a PFM customers actually trust, across every payment rail and every market.

"Subscription management" means four different things to four different banks - a simple list, a forecasting overview, a control button, or a security audit. Each serves a distinct motivation and draws on a distinct data source. This article breaks down all four solutions, what each is worth to the customer, and how to weigh them before committing engineering effort.

Gen Z is the heaviest-subscribing generation and fails on those subscriptions at roughly twice the rate of everyone else. But subscriptions are only the start. This piece breaks down four things Gen Z actually expects from a bank - seeing what they pay for, getting answers without digging, having their spending reflected back accurately, and banking with an institution that looks like them - and shows the European evidence behind each. Underneath all four sits the same dependency: a clean, enriched transaction record.

You want to build a subscription manager, a spending overview, or an affordability model - and the transaction feed hands you a terminal string that reads like a licence plate. Getting from that raw string to a shop a customer recognises takes two separate operations: cleansing and enrichment. Here's what each one does, which one your feature actually depends on, and how it holds up across card, SEPA and open banking data.

Gen Z decides fast whether a banking app is worth keeping open, and the choice comes down to five features: clear transaction history, subscription management, merchant-named notifications, spending insights with an annual recap, and per-transaction carbon tracking. Each one fails in a specific way when the transaction record underneath it is not accurate. This piece walks through those failure modes and the exact data fields that prevent them - and shows why a bank scoping these as five separate builds is really buying the same merchant-identity layer five times over.

Chargebacks are an important tool providing clients with the ability to dispute transactions and reclaim funds. These happen when a client contacts their bank to reverse a transaction, often because they believe the transaction was unauthorized, fraudulent, or incorrect. Chargebacks themselves also present significant challenges for merchants, banks, and fintech companies, often resulting in substantial financial losses. And the rise of digital banking has only magnified the importance of efficient chargeback management. With many automation tools available, banks need to understand that prevention is often the cheapest and smartest option available, making clear payment history more important than ever.

Digital banks serve over 500 million customers worldwide, yet fewer than a quarter turn a profit. This guide covers what it takes to build one - licences, architecture, acquisition cost, and the monetisation levers that lead to sustainable margins - with launch stories from Partners Banka and SwissBorg.

CCD2 takes effect on 20 November 2026, and self-declared income won't cut it anymore. But open banking data is far messier than a bank's internal records, so the provider you pick decides how reliable your creditworthiness assessment really is. Here's how to run a proof of concept on your own customers and judge vendors on coverage, accuracy, and classification depth.

CCD2 was meant to be transposed across the EU by November 2025, yet many member states still don't have final legislation. The frontrunners are the Nordics and the Netherlands - and each is rewriting creditworthiness assessment its own way. Here's how the Netherlands, Denmark, Sweden and Finland are tightening the rules, and why no credit register alone is enough to comply.

Across Europe, many merchants sell distinct and varied subscription products. That is how the subscription economy appears in bank transaction data: dense, fragmented, and structurally difficult to read. The brand-name surface looks tidy, with Netflix, Spotify and Apple at the front. Underneath, every merchant runs roughly six pricing variations, on average, across different amounts, billing cycles, currencies and payment paths.

Visa subscription management mandate has been in force since 18 April 2026 across 13 European markets, and the question for product teams has moved from whether to build subscription management to how to build it correctly. The full mandate overview covers all three of Visa's 2026/2027 requirements; this article focuses only on and what it takes at the implementation level. The rule asks issuers to do three things: identify and label three recurring transaction types, enable merchant-level stop instructions with the correct decline responses, and inform cardholders that cancelling a card charge does not end their contract with the merchant. None of these are unreasonable. Each one, though, depends on the quality of the transaction data sitting underneath the interface.

Mastercard AN4569 has been in force since 2023, and Visa's enhanced merchant data mandate follows in January 2027. The two requirements overlap more than they differ - and one enrichment layer, built to the right standard, covers both. Here's what European issuers need to meet, where the mandates align, and how to turn compliance into infrastructure.

Banks hold the richest behavioural data of any industry - every purchase, every transfer, every recurring obligation. And almost nothing they build with it feels personal. Sentient design is the model that would change that: interfaces that observe the user, infer what they need, and act before being asked. The model is real, the early examples exist, and bank product teams are starting to ask how to implement it. But every sentient moment depends on something most banks still don't have under control: clean, enriched transaction data that the AI can actually read. But first, you have to start with small steps. So we sat down with Ergomania's design strategist to learn how.

Merchant name inconsistency seems to be the rule in raw transaction data. A single global brand can appear as twenty or more distinct strings in a bank's transaction feed. Same merchant. Same card. Sometimes the same store on the same day. The descriptors land differently anyway. It is a structural property of how card payments work, and any product built on top of unresolved transaction data inherits the inconsistency by default.

A mid-sized European retail bank with 5 million active card customers sees around 1,5 billion card transactions a year - every purchase a data point on where the customer shops, what they spend on, and how their habits shift over time. The raw material for almost every personalised banking product sits in that feed. The question is not necessarily about access, more like whether the data, once you reach for it, is usable enough to build on - clear enough for customers, structured enough for analytics, consistent enough for credit and risk models.

When a card transaction lands in a bank's core system, it carries a handful of identifiers that determine whether the bank can actually tell its customer where they spent their money. The merchant ID (or MID) is one of the most important of these, and one of the most misunderstood. It is the primary key acquiring banks use to track merchants, and it is one of the main reasons the same real-world business can appear as dozens of unrelated entities in a bank's transaction data.

Wholesale and account-to-account payments have largely completed the move and instead of it being ISO 8583 vs ISO 20022, it’s more of an evolution. Card payments have not - there is no scheme-wide mandate, no fixed timeline, and the European Cards Stakeholders Group has explicitly recommended a market-driven approach. For banks and fintechs, this split reality matters: ISO 20022 is reshaping what transaction data fields are available, how rich that data is, and what you can build on top of it - but on the card rails most issuers depend on, ISO 8583 will remain the operational standard for years.

Withdraw cash from the wrong ATM in central Prague and you can pay tens or hundreds of crowns more than you should. Independent operators like Euronet apply withdrawal fees that vary by card type and country of issue, with foreign cards consistently charged the most. The fees are not the only problem - it's the density of these ATMs and the lack of clear information about them that turns an ordinary cash withdrawal into a costly guessing game.