Almost every card authorization on earth still rides ISO 8583 — a compact, fixed-field binary message defined in the 1980s. It is unglamorous, it is everywhere, and understanding the MTI and bitmaps is how you read what a switch is actually doing.
Compact, positional, fast — and dialect-ridden.
ISO 8583 is the international standard for financial transaction card-originated messages — the format that carries authorization, reversal, and clearing requests between terminals, switches, schemes, and issuers. If you tap a card and an answer comes back in under two seconds, an ISO 8583 message almost certainly made that round trip.
It is deliberately compact: fixed-length and variable-length fields, packed binary, designed for an era of expensive bandwidth. That compactness is why it is fast and why it is awkward — meaning lives in positions and codes, not in named fields. Schemes layer their own dialects on top (Visa Base I, Mastercard, etc.), so “ISO 8583” in practice means “a scheme’s variant of ISO 8583.”
MTI says what; the bitmap says which fields; the elements carry the data.
Three moving parts. The MTI (Message Type Indicator) is a four-digit code saying what kind of message this is. The bitmap is a 64-bit (often two-bitmap, 128-bit) field where each bit flags whether a given data element is present. The data elements (DE 1–128) carry the actual values — PAN, amount, processing code, and so on.
| Part | What it answers | Example |
|---|---|---|
| MTI | What type of message? | 0100 authorization request, 0110 response, 0400 reversal |
| Primary bitmap | Which of DE 1–64 are present? | Bit 3 set → processing code is included |
| Data elements | The actual values | DE 2 = PAN, DE 4 = amount, DE 3 = processing code, DE 39 = response code |
The MTI itself encodes four things: version, message class, function, and origin. 0100 = ISO-1987 version (0), authorization class (1), request function (0), from acquirer (0). The response 0110 flips the function digit. Read the four digits and you know the message’s job.
DE 39 is the verdict. Everything before it is the question.
A simplified authorization request — MTI, the bitmap indicating which data elements follow, then the elements themselves. Real messages are packed binary; this is the logical view:
# MTI 0100 authorization request (acquirer -> issuer) MTI 0100 # Primary bitmap: bits set => these DEs are present Bitmap 7234 0000 0E80 0000 (hex, illustrative) # Data elements named by the bits above DE 2 PAN 476173******0119 DE 3 Processing code 00 00 00 (00 = purchase) DE 4 Amount 000000015000 (ZAR 150.00) DE 7 Transmission DT 0529101500 DE 11 STAN (trace) 004217 DE 41 Terminal ID TERM0042 DE 49 Currency code 710 (ZAR) # Issuer replies MTI 0110 with: DE 39 Response code 00 (00 = approved)
The interrogation is always: read the MTI, walk the bitmap, parse the present elements. DE 39 is the one everyone watches — 00 approved, 05 do-not-honour, 51 insufficient funds. The decline reason a customer sees is a translation of a two-character DE 39 code.
Latency and a vast installed base keep it alive. The auth edge has the weakest migration case.
ISO 8583 authorizes the overwhelming majority of card transactions globally in 2026, decades after richer standards arrived. That is not inertia for its own sake — there are real reasons it persists.
Authorization is latency-critical — a tap must clear in under two seconds. A compact binary message beats a verbose XML one on the wire and in parsing. For yes/no auth, ISO 8583’s thinness is a feature.
Switches, issuer hosts, and terminal fleets worldwide speak it. Replacing the format means re-certifying the entire estate against every scheme — a multi-year, high-risk undertaking with no customer-visible upside.
ISO 8583 dominates real-time authorization; clearing and reporting are where ISO 20022’s rich data adds more value. The pressure to migrate is strongest where data richness pays, weakest at the auth edge.
The destination is ISO 20022; the auth leg is the longest part of the trip.
The schemes are moving. Mastercard and Visa have published roadmaps to carry authorization on ISO 20022 (Mastercard’s programme has been the most public), and instant-payment rails were born ISO 20022-native. But card authorization is the last and hardest domain to migrate, for the reasons above.
ISO 8583’s coded fields and ISO 20022’s structured elements do not map one-to-one. Gateways translating between them must make judgement calls — and judgement calls drop or distort data.
Expect terminals and hosts speaking 8583 to a switch that speaks 20022 upstream, with translation in the middle, for a long time. “Migration complete” for card auth is a horizon, not a date — unlike the cross-border CBPR+ cutover, which already happened (Nov 2025).
Own a switch, know your bitmaps. Build on an API, consume the JSON.
If anyone on your team owns a switch, an issuer host, or terminal certification, ISO 8583 literacy is non-negotiable. The bugs that cost real money — misqualified transactions, reversal mismatches, wrong response-code handling — live in the data elements. You cannot debug a decline storm from a dashboard; you read it in DE 39s and STANs.
Building or operating acquiring/issuing processing, certifying terminals, or running a domestic switch. Here, fluency is core competence — the format is your job.
Building a merchant-facing product on top of a PSP’s API. You consume normalised JSON; the 8583 lives below you. Do not rebuild a switch to accept a card — integrate one.
A mishandled reversal (0400) can double-credit or strand funds; a misread response code declines good customers or approves bad ones. These errors are invisible until reconciliation or a chargeback — and they scale with volume.
For SA and African processors: domestic switching still runs heavily on ISO 8583, and the migration pressure is lighter at the auth edge than for cross-border flows. Treat 8583 as a live, long-lived skill — not legacy you can skip on the way to ISO 20022.