ISO 8583: The Card Messaging Standard

When you tap a card, an authorization request races from the terminal to the acquirer, across a card network, to the issuer, and back — typically in under two seconds. For most of that journey the message is formatted according to ISO 8583, the international standard for card-originated financial transaction messaging. First published in 1987 and refined in 1993 and 2003, it remains the backbone of card payments and ATM networks worldwide. This post explains how it is structured and why it endures.

The shape of an ISO 8583 message

An ISO 8583 message has three parts: a message type indicator, one or more bitmaps, and a series of data elements. Together they describe what kind of transaction this is and carry its fields in a compact, position-based format rather than named tags.

Message Type Indicator (MTI)

The MTI is a four-digit code that classifies the message. Each digit means something:

• First digit — the version of the standard (0 for 1987, 1 for 1993, 2 for 2003).
• Second digit — the message class, such as authorization (1), financial (2), reversal (4), or network management (8).
• Third digit — the function: request, request response, advice, and so on.
• Fourth digit — who originated the message.

So 0100 is an authorization request, 0110 its response, 0200 a financial request, 0210 its response, and 0800 a network management (echo/sign-on) message. Learning to read the MTI is the first step to understanding any card message.

The bitmap

Because a card message can carry up to 128 possible fields but any given message uses only a few, ISO 8583 uses a bitmap to indicate which data elements are present. The primary bitmap is 64 bits; each bit that is set to 1 means the corresponding data element is included. If bit 1 is set, a secondary bitmap follows to address fields 65–128. This makes messages compact: you send only the fields you need, and the bitmap tells the receiver exactly which ones are there and in what order.

Data elements

After the bitmaps come the data elements (DEs), in numeric order of their bit positions. Each DE has a defined format and length — fixed or variable, numeric or alphanumeric. Some of the most important include:

• DE 2 — Primary Account Number (the card number).
• DE 3 — Processing code (purchase, withdrawal, refund).
• DE 4 — Transaction amount.
• DE 7 — Transmission date and time.
• DE 11 — System trace audit number, used to match request and response.
• DE 39 — Response code, telling the acquirer whether the transaction was approved (00) or why it was declined.
• DE 41 — Terminal ID; DE 42 — merchant ID.

Why it is not human-readable

Unlike ISO 20022's verbose XML, ISO 8583 is a binary, position-based format designed for the constrained networks and processing power of the 1980s. This makes it extremely efficient — a message is small and fast to parse — but opaque without a specification in hand. There is also no single universal dialect: card networks and processors each define their own variant with private data elements and specific field usages, so a message that parses on one network needs mapping to work on another. This fragmentation is a big reason integrations are specialised and certification-heavy.

The transaction lifecycle

A typical card purchase involves a chain of ISO 8583 messages. The terminal sends a 0100 authorization request; the issuer replies with a 0110 carrying an approval or decline in DE 39. Later, clearing and settlement may use financial and batch messages, and any reversal — say a timeout or a customer cancellation — uses a 0400-class message. Network management 0800 messages keep the links alive with echo tests and sign-on. Matching a response to its request relies on fields like the trace number (DE 11) and terminal identifiers.

Why it still runs the world

ISO 8583 is decades old, yet it processes an enormous share of global transactions. It persists because it is deeply embedded: terminals, switches, processors, and issuer hosts all speak it, certification is expensive, and the format is fast and proven. There is a slow, long-horizon migration toward ISO 20022 for cards, but the installed base is so large that ISO 8583 will be with us for many years. Understanding it is essential for anyone working near card rails.

Key takeaways

• ISO 8583 is the standard messaging format for card and ATM transactions, in use since 1987.
• Messages consist of a four-digit MTI, one or more bitmaps, and position-based data elements.
• The MTI encodes version, class, function, and origin; 0100/0110 are authorization request/response.
• Bitmaps indicate which data elements are present, keeping messages compact; key fields include the PAN (DE 2), amount (DE 4), and response code (DE 39).
• Network-specific dialects and heavy certification make card integrations specialised, and the standard endures because it is deeply embedded and efficient.