The International Organization for Standardization (ISO) message format 8583 lets a card issued by one bank be authorized at a terminal operated by a different acquirer. It defines the structure of messages between acquirers and card issuers during a transaction, allowing each system in the chain to read and respond to the request without requiring a custom connection between every pair of institutions. Published in 1987, this international standard still operates across many major card networks. It manages the authorization step each time a card is tapped, swiped, or entered online.

Below, we’ll cover how ISO 8583 messages are built, what a Message Type Indicator (MTI) is, and how it compares with ISO 20022.

Key takeaways

• ISO 8583 defines the message format that lets card issuers and acquirers communicate during authorization, eliminating the need for a custom integration between each pair.

• Each message is built from an MTI, a bitmap, and data elements—the structure that helps keep authorization fast at network scale.

• ISO 8583 still dominates card authorization, even as ISO 20022 gains adoption on other payment systems; the two standards generally serve different functions.

What is ISO 8583?

ISO 8583 is an international standard that defines how financial transaction messages are formatted and exchanged between card payment systems. Visa, Mastercard, and many domestic card networks built their authorization systems on some variant of it.

How does ISO 8583 work?

ISO 8583 works as a request-and-response protocol between two systems, so the receiver knows exactly what to expect before opening the message. One party sends a request, usually asking for authorization to charge a card, and the other sends back a response built to the same rules.

Here’s how it works:

• Shared grammar: Both sides read and write messages using the same field definitions, so a system in one country can interpret a message built by a completely different institution.

• Transport independence: The message can travel over a leased line, an old X.25 network, or Transmission Control Protocol/Internet Protocol (TCP/IP)—the modern rules that control how data moves over the internet. The protocol only defines what’s inside the message, not how it’s transported.

• Longevity by design: Networks have swapped their physical infrastructure many times over the decades without changing the underlying message format.

How is an ISO 8583 message structured?

ISO 8583 messages are generally built from several components. The structure is compact, which keeps messages small and fast to process, even at network scale.

Here are the main elements:

• MTI: A four-digit number that identifies the message’s version of ISO 8583 (e.g., 1987, 1993, or 2003), as well as its class, function, and origin.

• Bitmap: A field or sub-field indicating whether there are other data elements or data element sub-fields elsewhere in the message. A secondary bitmap might also exist.

• Data elements: The actual transaction data, such as amount, date, time, and country codes.

How does ISO 8583 power real-time card authorization?

When a customer taps a card, the terminal builds an authorization request and sends it to the acquirer—the financial institution or payments provider that handles transactions on the business’s behalf. The acquirer then routes the message to the relevant card network, which reads the account number, identifies the issuing bank, and forwards the request to the issuer. The issuer checks the account, runs its own fraud checks, and sends back a response with an approval or decline. That response retraces the same path back to the terminal.

The entire process typically happens immediately, even with multiple systems, sometimes on different continents, exchanging formatted messages and making decisions. ISO 8583’s fixed structure makes that speed possible. The MTI and bitmap tell every system in the chain exactly what to expect, eliminating the need to parse free-form data or guess at what a field means. Businesses that use a payments provider such as Stripe don’t have to build or manage these messages themselves.

What are the limitations of the ISO 8583 standard?

The ISO 8583 standard isn’t self-describing, which means a message doesn’t include field names or explanations, so a system needs a matching specification document to interpret it correctly. This slows down onboarding new connections between institutions. Visa, Mastercard, and various domestic networks each maintain their own variant of ISO 8583, with different field definitions and usage rules. The result is that two systems claiming compliance can still fail to communicate.

ISO 8583 has limited support for structured data because it’s a format built around short, mostly numeric fields, and it wasn’t built for account-to-account payments. ISO 8583 is a card-authorization protocol at heart. Extending it to cover things such as instant bank transfers has generally meant working around its assumptions rather than with them.

Is ISO 8583 still the right protocol as ISO 20022 adoption grows?

ISO 20022 is a newer messaging standard increasingly used in cross-border wire transfers, Automated Clearing House (ACH), and payment systems such as Fedwire and Single Euro Payments Area (SEPA) Instant Credit Transfer. These messages are often represented in Extensible Markup Language (XML), which makes them more self-describing and able to carry richer structured data than ISO 8583. A wire transfer can include detailed remittance information, structured party data, and regulatory reporting fields, all in an extensible format.

Since ISO 20022 messages run considerably larger, they can take more work to parse than ISO 8583’s compact format. Card networks have discussed migration paths toward ISO 20022 for years. However, the sheer scale of existing ISO 8583 infrastructure, number of terminals, acquirers, and issuers that would need to update in step, means a full transition will be gradual rather than imminent.

Anyone building or evaluating payment infrastructure should understand that both standards matter for different jobs. ISO 8583 remains the best fit for anything that touches card-present or card-not-present authorization, while ISO 20022 is suited for wire transfers, real-time payment systems, and places where structured, richer transaction data is the priority.

How Stripe Issuing can help

Stripe Issuing allows you to easily create, distribute, and manage custom cards—generating new revenue streams and enhancing your customer experience.

Issuing can help you:

• Launch new card products: Quickly create physical, virtual, or tokenized cards customized to your specific business needs—whether that’s expense cards, rewards, or something else.

• Improve operational efficiency: Automate card issuance and management through Stripe’s APIs, reducing the complexity of working with multiple card issuers.

• Enhance customer experience: Offer your customers a branded card experience that integrates seamlessly with your existing products and services.

• Gain visibility and control: Access detailed transaction data and controls to monitor card usage, set spending limits, and suspend cards when needed.

• Expand revenue opportunities: Monetize your card programs by collecting shared interchange revenue or by offering value-added services.

• Access Stripe’s expertise: Benefit from robust infrastructure and compliance support, influenced by Stripe’s experience powering card programs for leading companies.

Learn more about how Stripe Issuing can help you drive growth with custom card programs, or get started today.

FAQs about ISO 8583