Mastercard AN4569 compliance requires card issuers in 47 European countries and territories to show cardholders who they actually paid, instead of the short description that arrives from the acquirer. The rule has been binding since 14 October 2023, and Visa's equivalent requirement takes effect on 23 January 2027.
This guide covers what the mandate asks for, how to display the data, whether to build or buy the enrichment behind it, what to budget, and how to get value from it beyond the minimum.
What Mastercard AN4569 requires from issuers
AN4569, Revised Standards for the Display of Enhanced Merchant Data, was announced by Mastercard in early 2021 and became effective for issuers in the Europe region on 14 October 2023. The core obligation fits in one sentence: when enhanced merchant data is available, the issuer must provide it so the cardholder can recognise a transaction they are querying.
The Mastercard Rules name four data points: the merchant's public-facing or "doing business as" name, its location, its contact details and its logo. The data must reach the cardholder through the banking app, mobile wallet, internet banking or another digital channel that is at least easy to access.
Two details matter here. "When available" is not a loophole. It ties the obligation to data an issuer can reasonably obtain, which means the quality of your data source effectively sets your level of compliance. And the rule targets the moment a cardholder queries a payment, which in practice is the transaction detail screen: the first place a confused customer looks before picking up the phone.
Simply put, consumers are demanding more clarity around what they bought/who they bought it from, and the provider side aims to decrease the number and costs of chargebacks.
Visa's Enhanced Merchant Data rule: the second deadline
Visa has introduced a parallel requirement. From 23 January 2027, issuers of Visa consumer cards in most European countries must display enhanced merchant data in their cardholder-facing digital channels. The fields overlap heavily with Mastercard's, with one notable difference: Mastercard lists the merchant logo explicitly, while Visa's minimum does not require it.
The geographic scopes also differ, so each market in a bank's portfolio needs checking against both lists. For issuers on both schemes, the practical conclusion is simple: a scheme-independent enrichment layer covers both rules with a single integration. Banks that met AN4569 with a Mastercard-specific workaround have less than four months to revisit it.
Why the mandate exists: the cost of an unrecognised transaction
Unclear transaction records generate disputes that should never happen. An Ethoca-commissioned Aite Group study of US consumers, cited by Mastercard in 2020, found that 96% of consumers want more details to help them recognise purchases, and that nearly 25% of transaction disputes could be avoided by providing those details, logos included.
The economics have worsened since. Mastercard's 2025 State of Chargebacks report, based on Datos Insights research, expects global chargeback volume to grow 24% between 2025 and 2028, reaching 324 million transactions a year. The total financial impact is forecast to rise from $33.79bn to $41.69bn over the same period, and European chargeback volume is expected to grow by 27%. For issuers, the heaviest cost is operational: each dispute costs a financial institution between $9.08 and $10.32 to process.
Many of these disputes start with simple confusion. Mastercard notes that cardholders often fail to recognise legitimate card-not-present charges, particularly when they paid through a third-party app or service, and end up disputing their own purchases. A customer who sees a payment gateway code instead of the shop they visited assumes the worst and calls the bank. A recognisable name, logo and location answers the question before the call is made, which is why enriched merchant data also sits at the centre of dispute and chargeback prevention.
Payment data enrichment: the engine behind compliance
Enrichment links the raw transaction record to external sources so the bank can show information the descriptor does not contain, without asking the customer for anything. The input is what the acquirer sends: a truncated merchant string, an MCC code and sometimes a city. The output is the brand, the specific shop, its location and its contact details.
The data follows a natural hierarchy. At the top sits the merchant, with its brand name, logo and website. Below it sits the individual shop, with its address, GPS location, phone number and Google Place ID. Payment gateways add a further layer. When a purchase runs through PayPal, Stripe or a BNPL provider, the description often shows the intermediary rather than the shop, and identifying the merchant behind the gateway is the difference between a recognisable transaction and a dispute.
Correctness is the hard part, because merchant data does not stand still. Brands rebrand, logos are redesigned, and shops open, close and move. A merchant database that is accurate at launch degrades every month it is not maintained, and an outdated logo confuses a customer as much as a missing one. When assessing any data source, judge it on three dimensions: coverage (the share of transactions enriched for each data point), accuracy (how often each data point is correct) and information richness (depth beyond the basics, such as the real merchant behind a gateway or the exact shop inside a mall). Accuracy comes first: a clear placeholder is better than a wrong logo, as the cost of data inaccuracy shows.
How to display enriched merchant data in the banking app
Compliance is ultimately judged on the transaction detail screen. The following display practices meet the mandate while keeping the screen readable.
Merchant name
Lead with the clean brand name in the payment overview. If the brand name is unavailable or uncertain, fall back to the original merchant description. Keep the original descriptor accessible in the detail view as well: it can contain verification codes or payment references that the customer or the support team may need.
Logo
Show logos in a square 512x512 format, optimised for a white background and without frames. When no logo exists, use a category placeholder, such as a fuel pump for a petrol station, instead of a blank space or a generic card icon. For account-to-account transfers, consider adding bank logos, which are particularly useful in markets with high transfer volumes such as the UK.
Location
Display the purchase location on a map with a precise pin, and show the full text address beside it. The pin should point to the shop where the purchase happened, not the merchant's headquarters. Many banks exclude the map for online purchases, which leaves the customer unsure whether the location is unknown or irrelevant. Label these transactions explicitly as "Online" instead. Where a Google Place ID is available, the app can show photos, ratings and opening hours directly in the transaction detail.
Make the map interactive, so a tap opens the customer's preferred navigation app. Where a Google Place ID is available, the app can show photos, ratings and opening hours directly in the transaction detail. Place IDs are not available for every transaction, so the design must work without them.
Contact details
Show the merchant's phone number and website as tappable actions. A customer who can call the merchant directly from the transaction detail resolves the "what is this payment?" question with the merchant.
Three principles hold the screen together. Consistency means every transaction uses the same fields, layout and fallbacks, so gaps in the data never look like errors. Accessibility means logos carry text alternatives and nothing essential depends on the map alone. Usability means keeping cognitive load low: name and logo in the transaction list, the full detail one tap away.
In-house or third-party: choosing how to comply
There are two routes to compliance, and the decision rests less on the initial build than on what happens after it.
Building in-house means creating a merchant knowledge base from scratch: matching raw descriptions to brands, sourcing logos, geolocating shops and resolving payment gateways. The build alone typically takes months. Maintenance is the larger commitment. Adding new merchants, removing closed ones and catching rebrands requires a permanent team, and keeping accuracy high usually combines matching algorithms with human validation. Every person on that team is diverted from the bank's own product roadmap.
A specialised provider brings an existing merchant database and an established correction process. Tapix integrations typically take one to three months for incumbent banks and two to four weeks for fintechs. Swisscard, for example, met and exceeded AN4569 requirements after a three-month integration. Deployment options matter for regulated institutions too: enrichment can run as a cloud REST API or on-premise within the bank's own infrastructure.
Four questions usually settle the decision. Can the bank staff a merchant data team indefinitely, not just for the launch? Does the timeline allow months of build work before Visa's January 2027 deadline? Can an internal database match the coverage needed for every market where customers shop, including cross-border e-commerce? And will the solution work across both card schemes without a second project?
Budgeting for Mastercard AN4569 compliance
AN4569 is easier to fund when it is treated as a product investment with a measurable return.
On the cost side, third-party enrichment is typically priced by the number of enriched transactions. As a rough guide, monthly fees range from around €1,000 for smaller neobanks to around €20,000 for large banking groups. An in-house build carries a different set of costs: engineering time, a data and validation team, logo sourcing, infrastructure and ongoing maintenance with no end date.
On the return side, dispute handling gives a specific benchmark. Using Mastercard's 2025 figure of $9.08 to $10.32 per dispute, an issuer that prevents 1,000 unnecessary disputes a month saves roughly $9,000 to $10,000 in processing costs alone. That figure excludes the support calls avoided, the refunds no longer absorbed and the customer trust that a clear transaction feed builds over time.
Three items are commonly missed when scoping the budget. The first is another scheme: a budget that covers only Mastercard will need reopening for Visa. The second is design and front-end work, since data that the app does not display does not count towards compliance. The third is any data beyond the mandate the bank plans to use later, which is cheaper to include in one integration than to add in a second project.
Going beyond the AN4569 minimum
The mandate sets a floor, but it is only the beginning. The same enrichment layer that delivers the four required data points can power features that customers notice and internal teams use.
Clean, visual payments overview: Adding purchase category, GPS location and merchant URL to the required fields turns the transaction list into something customers can scan in seconds. This is the foundation of a clear transaction history, and it is the part of the app customers open most often.
Dispute reduction and fraud detection: Detailed merchant data gives both customers and fraud teams more to work with. GPS location confirms whether a card was used where the customer was, and category data highlights purchases in higher-risk segments.
Customer behaviour analytics: Categories, Google Place IDs and carbon tags give analytics teams a structured view of spending that raw MCC codes cannot provide. That supports segmentation, product design and customer behaviour insights across the whole portfolio.
Recurring payments overview: The mandate covers individual transactions, but customers increasingly want to see their commitments in one place. Recurring Payments Intelligence detects subscriptions and regular payments, with frequency, next billing date and amount, so the bank can offer a subscription management view covering everything from streaming services to utility bills.
Personal finance management and spending insights: Transaction categorisation into 25 categories and 530+ store-level tags is the basis for personal finance management: spending breakdowns, budgets and personalised insights. Combined with carbon footprint insights, the same data can show customers the environmental impact of their spending alongside its cost.
From compliance to a better transaction feed
Revolut, bunq, Swisscard and Soldo already display enriched merchant data that meets the mandate, and their customers have come to expect it. With Visa's deadline less than four months away, the remaining question for most banks is how to enrich transaction data well.
Tapix by Dateio enriches 4bn+ transactions a month for 90+ banks and fintechs across 140+ markets, recognising 1,400,000+ merchants with 130,000+ unique logos and getting one transaction wrong in every six million. One integration covers both Visa and Mastercard mandate compliance.
Visit our Tapix sandbox to see the output on your own data.
