The ISO 20022 migration is being described as the largest coordinated change to global payments infrastructure in a generation. SWIFT mandated adoption across its network. Central banks running RTGS systems are converting. Visa and Mastercard have both published roadmaps. FedNow launched native ISO 20022 support from day one.
Most product managers working in payments know the migration is happening. Far fewer understand what it actually changes — and specifically, what it means for the decisions they make about their product.
This piece explains the difference between ISO 8583 and ISO 20022 in terms that are useful for a product manager — not a messaging format engineer.
What ISO 8583 Is
ISO 8583 is the messaging standard that underlies card transaction processing. Every time a Visa or Mastercard transaction is authorised, cleared, or settled between an issuer and an acquirer through a card network, that communication is happening in ISO 8583 format — or a proprietary variant derived from it.
It was designed in the 1980s for a specific purpose: moving authorisation requests and responses between processors quickly and reliably. It does that job extremely well. It's compact, fast, and proven at enormous scale.
What it wasn't designed for: rich data. An ISO 8583 message has a fixed set of data elements — fields with defined positions and lengths. There's a field for the merchant name, a field for the transaction amount, a field for the terminal ID. But there's very limited space for contextual information — the invoice number, the itemised purchase detail, the remittance reference. The standard was built for authorisation speed, not data richness.
"ISO 8583 was built to move money fast. ISO 20022 was built to move data alongside the money. That distinction drives everything that follows."
What ISO 20022 Is
ISO 20022 is a methodology for defining financial messaging standards — not a single message format, but a framework for building message formats that are XML or JSON-based, richly structured, and extensible.
The key difference from ISO 8583 is the data capacity. An ISO 20022 payment message can carry structured remittance information — invoice numbers, payment references, creditor identifiers, purpose codes — alongside the core transaction data. It's not just "£1,500 was paid." It's "£1,500 was paid against invoice INV-2026-0042 for services rendered under contract REF-XYZ, to account holder J. Smith at Sort Code 12-34-56."
That level of data richness enables things that ISO 8583 structurally cannot: automated reconciliation, real-time compliance screening with context, richer fraud analytics, and straight-through processing without human intervention at the receiving bank.
The Core Differences for Product Teams
What the Migration Actually Involves
The migration is not a single switch. It's a multi-year coexistence period during which both standards run simultaneously, with translation layers handling the conversion between them. SWIFT's coexistence period — where ISO 20022 and MT messages both operate on the SWIFT network — has been phased in since 2023, with full cutover expected by November 2025.
For banks and fintechs operating in this period, the practical reality is a translation problem: messages arrive in ISO 20022, get translated to ISO 8583 for card system processing, then translated back. Every translation is a potential point of data loss — the rich remittance fields in an ISO 20022 message get truncated or dropped when the downstream system only supports 8583 field structures.
This is where it becomes a product problem: the enriched data that ISO 20022 promises is only available end-to-end if every system in the chain can handle it. Banks that have modernised their ISO 20022 ingestion but haven't addressed their internal systems — core banking, card processing, reconciliation — will send and receive richer messages but won't be able to use the data.
What It Means in Practice for Product Managers
The migration creates product opportunities and product risks in roughly equal measure. Here's where PMs need to be paying attention:
Reconciliation as a product feature
For banks with corporate or SME customers, ISO 20022's structured remittance data makes automated reconciliation genuinely achievable at scale — not as a fintech bolt-on, but as a core feature of a business banking product. The banks that build this into their product proposition early will have a durable advantage over those treating reconciliation as the customer's problem.
Compliance screening quality
Sanctions screening and AML monitoring are significantly more accurate when payments carry full counterparty context. ISO 20022's LEI (Legal Entity Identifier) support and structured originator/beneficiary fields give compliance systems more signal to work with. For product managers building on payment rails where false positives are a customer experience problem, this is relevant — fewer holds, faster processing, better explainability.
Cross-border product design
The richness of ISO 20022 data is most valuable in cross-border payments, where the current experience (slow, opaque, expensive, reconciliation-heavy) is most broken. Product teams building international payment products now need to understand which corridors are moving to ISO 20022 rails — and which are still on MT or proprietary formats — because the product experience is fundamentally different depending on which rails the payment travels.
The truncation risk
This is the risk that doesn't show up in the migration plan. When a payment enters a system that can't process the full ISO 20022 payload, the rich data gets dropped. The payment clears, but the remittance information is lost. For a corporate customer who needed that invoice reference to auto-reconcile, the payment is functionally broken. Product managers need to understand where in their stack truncation can occur — and either fix it or communicate the limitation honestly.
FedNow and real-time payments
FedNow launched with ISO 20022 as its native message format — meaning any bank or fintech building on FedNow rails is already operating in an ISO 20022 environment. The implications for instant payment product design in the US are significant: the data richness is available from day one, but only to products that are built to use it. Building an instant payment product on FedNow and not leveraging the remittance data fields is like buying a high-resolution screen and running it at 720p.
The Action List for PMs
-
→
Map your stack's ISO 20022 readinessWhich systems in your chain receive, process, and forward ISO 20022 messages? Where does truncation occur? This is the audit that determines your actual capability vs. your theoretical capability.
-
→
Identify which payment corridors have migratedNot all rails have converted. Your cross-border product may touch ISO 20022 on one leg and an MT format on the return. Know the map.
-
→
Evaluate the reconciliation opportunityIf you serve business customers who process significant payment volumes, the reconciliation use case is a near-term product opportunity — not a 2028 roadmap item. The data is there today on ISO 20022 corridors. The question is whether your product surfaces it.
-
→
Talk to your compliance team about screening qualityISO 20022's richer counterparty data should be improving your AML screening accuracy. If it isn't — if your compliance system is treating the enriched fields as optional context rather than primary screening input — that's a configuration problem worth fixing.
-
→
Don't wait for the cutoverThe coexistence period is the time to build ISO 20022 capability, because the cost of being caught unprepared at the cutover date is significantly higher than the cost of migration work done at pace. The banks treating this as an infrastructure team problem rather than a product team problem will find themselves unable to compete on payment data quality when the market has moved.
Working on a payments infrastructure migration?
If your team needs payments standards expertise applied to a real programme — ISO 20022 migration, FedNow build, cross-border product design — let's talk.
Book a call