In this essay
ISO 8583 is the card industry's interchange standard for messages between acquirers and issuers, built from a message type, a bitmap and numbered data elements. ISO 20022 is a broader financial messaging standard built on a shared business model and data dictionary, usually exchanged as XML, and it now carries bank-to-bank payments such as Swift cross-border traffic. ISO 20022 does define card message sets, including Acquirer to Issuer Card Messages (ATICA), but ISO revised ISO 8583 as recently as 2023. Card products should plan for the two to coexist, not for a single cutover date.
What is the difference between ISO 8583 and ISO 20022?
ISO describes ISO 8583 as a common interface for exchanging card-originated messages between acquirers and card issuers, specifying message structure and format, including normalized data types. The current edition, ISO 8583:2023, replaces ISO 8583-1:2003, ISO 8583-2:1998 and ISO 8583-3:2003, and message, field and value definitions are provided by the ISO 8583 maintenance agency. ISO: ISO 8583:2023 The 2003 edition stated that the method of settlement was outside its scope. ISO: ISO 8583-1:2003 In practice each network and host publishes its own profile of the standard; read the ISO 8583 profile before copying a field table explains why that matters.
ISO 20022 is organized into business areas, each with a four-letter code, and messages are identified by that code plus a message number, variant and version. For example, caaa.001.001.15 is AcceptorAuthorisationRequestV15. ISO 20022: message definitions Every message draws on the same repository of business components. ISO 20022: the repository
| Aspect | ISO 8583 | ISO 20022 |
|---|---|---|
| What it is | Interchange specification for card-originated messages | Methodology and repository for financial messages across many business areas |
| Current form | ISO 8583:2023 (edition 3) | A maintained catalogue of versioned message definitions |
| Structure | Message type indicator, bitmap, numbered data elements | Tagged, nested business elements from a shared data dictionary, typically XML |
| Identification | Message type such as an authorization request or reversal | Business area, number, variant and version, such as caaa.001.001.15 |
| Customization | Network and host profiles define fields and codes | Usage guidelines set by each community or market infrastructure |
| Main use today | Card authorization traffic between acquirer, network and issuer | Bank payments, including Swift cross-border instructions; card sets also exist |
The ISO 8583 payment message lifecycle walks through the message type, bitmap and data elements in a real authorization.
Which ISO 20022 message sets cover card payments?
The ISO 20022 Registration Authority's business area list includes a family of card areas. ISO 20022: business areas
| Code | Business area | What it covers |
|---|---|---|
| caaa | Acceptor to Acquirer Card Transactions | Authorisation, cancellation and capture between card acceptor and acquirer |
| cain | Acquirer to Issuer Card Transactions | Authorisation, reversal and financial presentment between acquirer and issuer |
| casp | Sale to POI Card Transactions | Messages between a sale system and a point of interaction (terminal) |
| catm | POI Management | Terminal management between a terminal management system and the POI |
| catp | ATM Card Transactions | ATM-to-host messages such as cash withdrawals |
| caam, caad, casr, cafr, cafm | ATM Management, Card Administration, Settlement Reporting, Fraud Reporting and Disposition, File Management | Supporting card operations |
The cain area holds the ATICA messages. ATICA began as a reverse-engineering of ISO 8583, with an initial set of 13 message definitions published as a proof of concept in February 2016. ISO 20022 RMG newsletter, April 2018 Its message definition report describes, for example, an authorisation initiation sent by an acquirer or agent to an issuer to request approval of a card transaction. ISO 20022: ATICA message definition report, version 2 The caaa and catm sets are published under the name Card Payments Exchanges (CAPE). ISO 20022: CAPE acceptor to acquirer report
Where is each standard used today?
ISO 8583 sits on the authorization path between acquirer and issuer: merchant systems typically send API calls to a gateway, and the acquirer or processor converts them into the network's ISO 8583 profile for the issuer.
ISO 20022 has taken over bank payment messaging. Swift reported that the final switch for cross-border payment instructions happened on 22 November 2025, after which ISO 20022 is required for all payment instructions on its network. Swift: community completes switch to ISO 20022 Swift's structured address rules then follow; see the November 2026 address cut-off.
ISO 20022 card sets are published and versioned, but whether your acquirer, terminal estate or network supports them is a question for each provider, not something the standard decides.
Will card payments move to ISO 20022?
Not on a single date. Three facts point to coexistence:
- ISO published a new edition of ISO 8583 in 2023, so the card standard is being maintained, not retired.
- ISO 20022 card message sets exist, which gives networks and processors an option to adopt them for specific flows.
- Some bank legs around a card business, such as cross-border payouts and supplier payments sent over Swift, already use ISO 20022.
The likely pattern is that card authorization keeps running on network ISO 8583 profiles for the foreseeable future, while the payments around it speak ISO 20022. That is a judgment, not a published network roadmap: ask your network and processor for theirs.
What should a payments PM plan for?
| Area | What to do now |
|---|---|
| Internal data model | Model payments in your own canonical schema, richer than any single message, and map out to ISO 8583 profiles and ISO 20022 messages |
| Card authorization | Keep network ISO 8583 profiles under version control; do not budget a rewrite without a network mandate |
| Bank legs | Treat payouts, refunds to accounts and treasury transfers as ISO 20022 work today |
| Translation | Document every field where ISO 20022 data is truncated or dropped when mapped to ISO 8583 |
| Evidence | Store raw messages and normalized records together for disputes, audit and reconciliation |
| Vendor questions | Ask processors, switches and terminal vendors which ISO 20022 card sets they support and on what timeline |
For the bank-side program itself, ISO 20022 migration: what payment product teams must know covers data mapping, validation and partner testing.
FAQ
Is ISO 8583 being replaced by ISO 20022?
Not on a fixed timeline. ISO revised ISO 8583 in 2023 and card networks run their own ISO 8583 profiles, while ISO 20022 card message sets exist alongside them.
What is ATICA in ISO 20022?
Acquirer to Issuer Card Messages, the ISO 20022 set in the cain business area. It covers authorisation, reversal and financial presentment between acquirers and issuers.
What is the difference between MT, MX and ISO 8583?
MT is Swift's legacy bank message format, MX refers to ISO 20022 XML messages on Swift, and ISO 8583 is the card interchange standard. See SWIFT MT vs MX.
Does Swift's ISO 20022 migration affect card authorizations?
No, card authorizations do not travel over Swift payment messages. It affects the cross-border bank transfers a payments business sends or receives, such as supplier payments and some payouts.
Should a new card platform be built on ISO 20022?
Build on an internal canonical model and implement whatever interface each network and acquirer requires, which today usually means an ISO 8583 profile. Add ISO 20022 card messages where a partner supports them.
Closing thought and further reading
Swift finished its ISO 20022 switch in November 2025. ISO revised ISO 8583 in 2023. For card products, that points to coexistence, not a cutover.
Need help applying this to your business?
Explore practical support for payment operations, product decisions, program delivery and AI automation, grounded in the challenges behind this essay.


