����logo

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 5m active card customers sees around 1,5bn 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.

When PSD2 came into effect in 2018, Account Information Service Providers got a formal identity. Banks had to open their APIs to licensed third parties, and consumers gained the legal right to let those third parties access their payment account data. Seven years later, hundreds of AISPs are registered across Europe, and the model has spread to the UK, Brazil, Australia, and parts of the Middle East.

Open any banking app, scroll a recent transaction feed, and the friction usually starts in the same place: a row of cryptic capital letters where a merchant name should be. That row is the payment description - the short text string that comes through with the transaction and lands in the app next to the amount. It is the single field that most determines whether a customer recognises what they bought, who they paid, and whether the charge is legitimate. Banks rarely control it, and in its raw form, it is rarely good enough to display.

When you’re looking for transaction data enrichment tools and their features, six vendors usually come up: ����logo, Tink, Ethoca, Salt Edge, Fiserv, and Plaid. Most comparison posts treat them as interchangeable API swaps. They are not. They sit at different layers of the stack, they solve different problems, and picking the wrong one means paying for capabilities you do not need while missing the ones you do. This article walks through what each tool actually does, what it does not, and how to match them to the problem you are trying to solve.

When a customer taps their card, the bank's issuer system receives a tightly structured but surprisingly thin bundle of card network transaction data. The fields are standardised, the values are constrained, and most of what an end user expects to see in their app - clean merchant names, logos, recognisable categories, exact shop locations - is simply not in the message. Everything from statement clarity to credit decisioning is built downstream of this raw payload, which makes the gap between what arrives and what a customer needs the single most consequential data problem in retail banking.

The EU's revised Consumer Credit Directive (CCD2 for short) is about to change the rules for consumer lending and BNPL across Europe. By November 2026, lenders will need to prove that borrowers can actually afford what they're signing up for. That puts transaction data at the centre of every credit decision.

The topic of global warming, long-term sustainability and overall respect for planet Earth has been discussed for decades, across human activities and industries. Today, there is little doubt that climate change poses a real and significant political and economic risk to humanity.

Business banking product teams have spent the last few years arguing about SME banking trends and UX while the regulatory and competitive ground shifted. Mastercard AN4569 is live. Visa’s mandate hits in 2027. CCD2 is moving the BNPL in a new direction. And challengers that were niche five years ago are now credible.

Every card payment processing triggers a chain of events - money moves between banks, transaction records are created, and what customers see in their banking app is shaped by decisions made long before they tapped their card.

Every card payment generates a transaction record. But if you look at the raw data behind that record, you'll quickly notice a problem: the location information it contains is almost never specific enough to tell you where the customer actually was.

Every time a card is tapped, swiped, or entered online, a stream of raw transaction data is generated behind the scenes. Banks, payment processors, and fintechs all receive this data - yet very few of them can make it immediately useful.