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.
Understanding the gap between the two is the difference between treating data quality as a passing problem and treating it as the permanent operating condition.
What are payment messaging standards
Every card transaction is a message passed between systems - issuer, acquirer, network, or gateway. The standard defines the format, the fields, and the structure of that message. Without a shared standard, none of these systems could communicate reliably enough to authorise a payment in the time it takes to tap a card.
Messaging standards are basically the plumbing behind everything banks receive as transaction data. The fields available in the standard are, in practice, the upper limit on what an issuer ever sees. Everything that happens downstream (from statement clarity and categorisation to fraud detection and dispute resolution) depends on what the standard allows the message to carry in the first place.
What Card Network Transaction Data Do Banks Receive?
What is ISO 8583
ISO 8583 has been the dominant standard for card payment messaging since the 1980s. It defines a fixed, bitmap-based message format in which each data element (DE) sits in a numbered field - DE2 for the primary account number, DE3 for processing code, DE4 for amount, DE43 for the merchant name and location string, and so on through more than 120 defined positions.
The format was designed for an era when bandwidth was scarce and authorisation latency was the binding constraint. Fields are short, often positional, and frequently overloaded - DE43, or the merchant description, is a single fixed-length string of up to 40 characters in which the acquirer is expected to compress the merchant name, city, and country code. That is where most of the descriptor mess banks deal with today originates. The format does not have room for a clean merchant name; it has room for a 40-character string the acquirer hopes will be intelligible.
The other structural problem is variant fragmentation. There is no single universal ISO 8583. The standard has three published versions (1987, 1993, and 2003), and Visa and Mastercard implement it differently on top of those versions, with their own custom fields and processing rules. Mastercard, Visa, and other payment networks use ISO 8583 as the basis for communication authorisations related to card-based payment messages, but they do not implement it identically. A bank reconciling data from both schemes is, in effect, working with two related but non-interchangeable dialects of the same standard.
This is why the messiness of merchant descriptors, MCCs, and identifiers cannot be fixed at the issuer layer alone. The format itself constrains the data - and different networks apply that format differently.
What is ISO 20022
ISO 20022 is an XML and JSON-based messaging standard developed initially for SEPA credit transfers and high-value payment systems. SWIFT CBPR+ (Cross-Border Payments and Reporting) and SCORE+ (Standardised Corporate Environment) guidelines enable customers to leverage the full richness of ISO 20022 XML formats. Where ISO 8583 is positional and abbreviated, ISO 20022 is structured - fields are named, nested, and large enough to carry full data rather than short strings.
For European banks, the standard is already rooted in wholesale and retail account-to-account payments. The European Central Bank finalised ISO 20022 migration in March 2023, the Bank of England migrated CHAPS in June 2023, and the coexistence period for cross-border MT/ISO 20022 ended on 22 November 2025. The next mandatory milestone for wholesale payments is November 2026, when structured postal addresses become compulsory across CBPR+ and SEPA.
Cards are the next step, and the most complicated one. The ATICA standards (Acquirer-to-Issuer Card Messages) define how ISO 20022 should be used in the acquirer-to-issuer card domain, with explicit attention to coexistence with 8583. But there is no scheme-wide mandate. There has been no mandate in any country towards standardisation of the ISO 20022 framework for cards. In the European Union, a detailed study by the European Cards Stakeholders Group led only to the recommendation of having a market-driven approach to an ISO 20022 migration. Visa and Mastercard support ISO 20022 in newer APIs and instant payment integrations, but the authorisation rails most card transactions still run on are 8583.
ISO 8583 vs ISO 20022 - the key differences for banks
The change matters at the level of individual data fields. The table below shows where the standards diverge in ways banks actually feel.
Two things are worth pulling out. First, the merchant identification gap is the single biggest reason 20022 matters for downstream UX. Cards have lived for decades on ISO 8583. It is elegant in its own way, but it is flat and positional. Fields are overloaded, addresses are often free text, and important context rides in proprietary extensions. A 20022 message can pass a merchant's legal name, doing-business-as name, structured address, and website in separate fields. An 8583 message passes a 40-character string with no guarantee the recipient can interpret it correctly.
Second, the maintenance argument is real and underrated. According to Visa's Building a Competitive Payments Platform with ISO 20022 paper, financial institutions have often spent hundreds or thousands of hours each year remapping ISO 8583 fields to implement network messaging enhancements across multiple networks. With ISO 20022's structured design, once data is mapped, it requires far less maintenance. Schemes change their 8583 extensions constantly. Issuer integrations break. 20022's named-field structure absorbs change more gracefully.
What this means for transaction data quality
In theory, ISO 20022 reduces many of the data quality problems banks deal with today. Richer merchant fields mean less reliance on free-text descriptors. Structured business classification reduces sole dependence on MCCs - which were never designed for consumer-facing categorisation in the first place. In practice, the migration is gradual and uneven, and the data quality problems will not go away. There are three reasons for that:
- Banks will receive a mix of 8583 and 20022 messages for years. Even if a major issuer modernises its core, its acquiring parties may not. Legacy POS terminals continue to produce 8583-formatted authorisation messages long after the central infrastructure changes. The 20022 advantage only materialises when both sides of a transaction speak the new standard end to end.
- The data integrity problem moves but does not disappear. A structured merchant name field is only useful if someone populates it correctly. Acquirers still configure that data, and acquirers still get it wrong. The same incentive misalignment that produces wrong MCCs (merchants choosing categories that attract lower interchange) does not vanish because the field is more clean.
- Merchant identity resolution remains its own problem. Even in a fully structured world, a global brand like Tesco operates through dozens of legal entities, hundreds of acquirers, and thousands of terminals. Resolving "TESCO PRAHA EDEN", "TESCO STORES CZ LTD", and "TESCO SUPERSTORE" to a single canonical merchant entity is not a job the messaging standard does. It is a job the enrichment layer does, regardless of the format the data arrived in.
ISO 20022 is a richer container. It does not produce richer content on its own.
How Tapix fits into this transition
Tapix operates at the data layer, sitting between whatever messaging format the bank receives and whatever the bank wants to show in its app, analytics stack, or risk engine. The format underneath matters less than what banks need to do with the output.
Today, that means resolving the inconsistencies produced by ISO 8583. Tapix takes terminal identifiers, free-text descriptors, MCCs, and partial location data (the raw payload banks actually receive from card networks) and returns clean merchant names, four-level category classifications, GPS coordinates, logos, website URLs, payment gateway identification, and behavioural signals like recurring payment status.
As ISO 20022 adoption grows, the input becomes richer but the merchant identity resolution problem evolves rather than ends. A structured 20022 merchant block still has to be matched against a canonical brand, a real shop location, and a stable category that holds across borders. Tapix already operates on enriched inputs - open banking feeds, instant payment data, and SEPA credit transfers all carry more structured information than card rails.
For banks mid-migration, this matters operationally. An issuer running parallel rails (8583 for legacy authorisation, 20022 for newer instant payment integrations) needs a single consistent output layer to feed downstream systems. Enrichment normalises that output, so the bank's analytics engine, fraud rules, and customer-facing transaction list do not need to know which messaging standard produced any individual record.
