ISO 8583

24.0 What this chapter gives you#

1. You will be able to explain what the bitmap does, and read the shape of a transaction off eight bytes of hexadecimal before parsing a single value.
2. You will be able to decode a four-digit message type indicator into version, class, function and origin, and say what 0100, 0420, 0800 and 1240 each mean.
3. You will be able to explain why the twelve digits 000000004250 mean nothing until you have read DE 49, and why the same digits are four thousand two hundred and fifty yen in Tokyo.
4. You will be able to say why “ISO 8583 compliant” on a vendor’s data sheet is worth almost nothing, and what three questions to ask instead.
5. You will be able to explain why the 2023 edition reused version digit 2, and why that is a standards body formally conceding that the wire format is frozen.
6. You will be able to distinguish a request from an advice from a repeat, and say which of them may be refused and which may only be acknowledged.
7. You will be able to explain why the industry stayed on the 1987 edition even though the 1993 response codes are better in every respect.
8. You will be able to explain why a malformed bitmap produces a £4,250,000 purchase rather than a parse error at the malformed byte.
9. You will be able to say what DE 90 does, and why a reversal needs five separate sub-elements to name the message it wants undone.
10. You will be able to explain why what leaves a terminal is not an ISO 8583 message, and name the layers wrapped around it.

There is a sentence that gets repeated at payments conferences until it stops meaning anything: ISO 8583 is the language of card payments. It is not a language. It is closer to a filing convention — an agreement about which numbered box holds the amount, which holds the card number, and how to tell the person at the other end which boxes you bothered to fill in.

That is a smaller idea than “language”, and it is the reason the format has survived. Languages evolve and fragment. Filing conventions calcify, and calcification is what you want in a system where a terminal made in 2003 has to be understood by a mainframe replaced in 2019, which has to be understood by a card issuer in a country neither has heard of. The format was first published in 1987, and the overwhelming majority of card authorisations on earth are still carried in messages whose first digit says 1987. This chapter explains what is in one of those messages, digit by digit and field by field, and why the phrase “ISO 8583 compliant” on a vendor’s data sheet tells you almost nothing you needed to know.

The plain version#

Imagine you and a friend need to send each other messages by telegram, and the telegram office charges you by the letter. You will be sending the same kind of message hundreds of times a day: how much, whose account, which shop, what time. Writing out “Amount: forty-two pounds fifty” every time would bankrupt you.

So you agree on a form. Not a form you send — a form you both memorise. Box 2 is always the card number. Box 3 is always what kind of transaction this is. Box 4 is always the amount. Box 11 is always a serial number so you can tell one message from another. Box 39 is always the answer: yes or no.

Now you never have to write a label again. You only write the contents.

But there is a problem. Most messages do not fill in every box. A shop till sending a payment does not need Box 36, which holds data from a bank card’s third magnetic track that nobody has used since the 1980s. If you leave boxes out, how does your friend know that the “000000004250” they are reading is the amount and not something else?

So you add one more thing at the very front of the message: a checklist. Sixty-four ticks in a row, one for each box, in order. A tick means “this box is in the message”. A blank means “skip it”. Your friend reads the checklist first, learns that boxes 2, 3, 4, 7, 11, 12, 13, 14, 18, 22, 25, 32, 37, 41, 42, 43 and 49 are coming, and then reads the contents of exactly those boxes, in exactly that order, and knows what each one is without a single label being sent.

That checklist is called a bitmap, and it is the whole trick. Everything else in ISO 8583 is bookkeeping around it.

A worked example#

You buy a book. £42.50, at a bookshop in London, on 17 March 2026, at 32 minutes and 5 seconds past two in the afternoon. You tap your card. The terminal fills in the form:

Two things in that table are worth stopping on. The amount has no decimal point and no pound sign. It is twelve digits: 000000004250. The decimal point is not sent, because Box 49 already said “826”, which means pounds, and everybody has agreed that pounds have two digits after the point. Four thousand two hundred and fifty pennies. Had the currency been Japanese yen, the same digits would have meant four thousand two hundred and fifty yen, and there would have been no decimal point to imagine. And the card expiry is 2803, not March 2028: year first, then month, so the digits sort in date order if you line them up.

Somewhere between one and two seconds later, a message comes back the other way with almost nothing in it. The serial number, so the till knows which purchase this is about. A six-character code the bank made up, A4T29B, so that if there is ever an argument the two sides have something to point at. And Box 39, which is two characters long:

00

That is it. Two characters. 00 means yes. Anything else means some flavour of no, and the till has a printed list telling it what to say to the customer for each one. The receipt prints. You take your book.

Why it is not written out in words#

Suppose you wrote that same purchase out with labels, the way a modern computer system usually would, so that every value has its name written next to it. It comes to 639 characters. Trim the labels down to bare numbers and it still comes to 289. Written in the numbered-box form with the checklist at the front, it is 181 characters, and if you use the compact way of writing digits — two squeezed into the space of one letter — it is 129. In 1987, a shop’s card terminal talked to its bank down a telephone line at 1,200 bits per second, which is about 120 characters every second. So:

And that is one direction. Double it for the reply. The difference between the first row and the last row is the difference between a customer waiting eleven seconds at the till and a customer waiting two. The format was not designed to be elegant. It was designed to fit down a copper wire while somebody stood there holding their shopping.

Four kinds of message#

There are only four things any of these messages can be. A question asks: may I take £42.50 from this card? An answer comes back the other way carrying the yes or the no. A notice says: I have already done something, and I am telling you about it — a shop whose terminal lost its phone line and took the payment on paper sends a notice, not a question, and the bank cannot refuse something that has already happened. A cancellation says: forget the last one. If the till asked for £42.50 and the answer got lost on the way back, the till does not know whether the money was set aside, so it sends a cancellation quoting the exact details of the message it wants undone, and keeps sending it until somebody confirms.

Question, answer, notice, cancellation. Everything else — sign-on messages, key exchanges, the nightly totals two banks send each other to check they agree — is one of those four wearing a different hat.

Where the plain version stops being true#

It is not one form. It is an agreement to number the boxes. This is the most important correction in the chapter and the one the industry is loosest about. ISO 8583 specifies the shape of the envelope: a message type at the front, one or two checklists, then the contents in checklist order. It does not, in the current edition, even contain the list of what the boxes mean. In the third edition, published in July 2023, the message definitions, field definitions and code values were deliberately moved out of the standard and into a separately maintained register, so that they can be changed without republishing an International Standard. Two systems can both be entirely faithful to ISO 8583 and be unable to exchange a single message, because faithfulness to ISO 8583 does not settle what goes in box 48, or box 62, or what response code 05 means to you as opposed to me.

“Binary format” is only about a tenth true. The checklist genuinely is binary — eight raw bytes whose individual bits carry meaning. But the rest of the message is usually characters: digits and ordinary letters, written in ASCII or, on older mainframes, in EBCDIC. Some implementations pack numeric fields two digits to a byte and some do not, and the standard permits both, so the same logical message can be 129 bytes on one link and 181 on another. Sizes quoted for ISO 8583 messages are always sizes for a particular implementation, never for the format.

The box numbers do not mean the same thing everywhere. In the 1987 edition, data element 24 holds a network routing identifier; in the 1993 edition the same number holds a function code doing an entirely different job. Response codes are two characters long in 1987 and three in 1993. And the codes saying which kind of account to take the money from differ between published specifications that both describe themselves as ISO 8583: one major scheme’s documentation uses 10 for savings and 20 for a current account, while a major acquirer’s published message specification uses 01 and 02 for the same two things. The box number is agreed. The contents are negotiated.

The standard is silent about everything that makes it work. ISO 8583 says nothing about how a message gets from the terminal to the bank, how you know where one message ends and the next begins, how you prove it was not tampered with, or how the money actually moves afterwards. All of that is bolted on outside: routing headers borrowed from an older transport standard, a length prefix in front of every message on a TCP connection, a cryptographic checksum in the last field, and a separate settlement process hours or days later. Reading ISO 8583 and expecting to understand a card network is like reading the specification for a shipping container and expecting to understand global trade. It is also why 00 does not mean the money moved: it means the issuer agreed that it would, and the instruction that shifts funds between banks is a different message sent later, often the following day.

The technical version#

What ISO 8583 is, precisely#

ISO 8583 is an International Standard maintained by ISO Technical Committee 68 (Financial services), Subcommittee 9 (Information exchange for financial services). Its title is Financial-transaction-card-originated messages — Interchange message specifications. Its scope is one sentence: it “specifies a common interface by which financial-transaction-card-originated messages can be interchanged between acquirers and card issuers”, and it “specifies message structure and format, including normalized data types”. It then says explicitly that “the method by which messages are transported or settlement takes place is not within the scope of this document”.

The editions are:

The third edition cancels and replaces all three parts published between 1998 and 2003 and reunifies them into a single document, and it does so by making that document much smaller: the messages, data elements and code values that used to occupy the bulk of ISO 8583-1:2003 are now published separately at standards.iso.org/iso/8583 and maintained by an ISO 8583 maintenance agency, which as of writing is the Association française de normalisation (AFNOR). The foreword records the reason: the document “has been restructured to facilitate maintenance of the messages, data elements and code values by a new ISO 8583 maintenance agency”.

The 2023 edition also carries a note that tells you what four decades did to the subject matter. It observes that “a range of tokens now exist for identifying account relationships”, and warns that “the actual token numeric issued by a financial institution can be different from the associated card numeric”. A standard about cards has quietly conceded that the thing in the message is frequently not a card. Its only normative references are ISO/IEC 7812-1 and ISO/IEC 7816-6.

Message structure#

Clause 4.1.1 of the 2023 edition specifies that every message shall be constructed in exactly this sequence:

1. the message type;
2. one or two message bitmaps;
3. a series of data elements, in the order of the bitmap representation.

There is no framing, no terminator and no length. Those are the transport’s problem, and every deployment solves them differently.

The message type identifier, digit by digit#

The message type is four digits. The first is a version number; the remaining three are the message type identifier proper, which the standard describes as “a three-digit numeric field identifying the message class, message function and transaction originator”.

Position 1 — version. The standard’s Table 1 assigns:

The repetition of 2 is not an error, and it is the most quietly devastating line in the standard. The 2023 footnote explains that “code no. 2 is reused for this edition since no changes have been incorporated into this document that would necessitate a new version to properly construct or parse a message for processing”. A new version digit is only assigned, per clause 4.1.2.2, “when sufficient changes have been made in a revision of this document such that it is necessary to know which version was used to construct a message in order to properly process the message”. Thirty-six years on, ISO published a new edition and did not need a new digit: a standards body formally acknowledging that the wire format is frozen.

Position 2 — message class. What kind of business this message is about.

The distinction between class 1 and class 2 is the dual-message versus single-message divide, and it decides the entire downstream architecture. An authorisation message asks whether funds are available and obtains an approval but posts nothing to the account; a separate clearing exchange posts it later. A financial message asks and posts in one go. Credit cards overwhelmingly run dual-message; ATM withdrawals and much domestic debit run single-message.

Position 3 — message function. What this message does within its class.

The standard’s definitions are worth quoting because the industry uses these words loosely. A request is a “message in which the sender informs the receiver that a transaction is in progress”, and a response is required to complete the activity. An advice is a “message in which the sender notifies the receiver of an action that has been taken, requiring no approval but requiring a response”. The difference is not politeness: a request can be refused, an advice can only be acknowledged. Functions 6 and 7 arrived in the 2003 edition and are almost never seen on live scheme links.

Position 4 — transaction originator.

The repeat values matter more than they look. Clause 4.2 requires that “whenever a repeat message is identified, that repeat message shall be identical to its original message, with the exception of the message type identifier and, if necessary, date and time transmission and the message authentication code data elements”. A repeat is a byte-for-byte retransmission with a changed origin digit, and that is how the receiver knows it may be a duplicate rather than a second purchase.

Reading them together. The four digits compose:

Note the last two. 1240 is Mastercard’s First Presentment message and 1442 is a chargeback: both are 1993-version messages, and both travel over the same scheme as the 1987-version 0100 that authorised the purchase in the first place. One transaction, two editions of the standard, routinely.

The bitmap#

The second component is “one or two message bitmaps, each consisting of 64 bits. Each bit signifies the presence (1) or the absence (0) in the message of the data element associated with that particular bit.”

The primary bitmap is always present and indexes data elements 1 to 64. Bit 1 does not index a data element; it signals the presence of a secondary bitmap covering elements 65 to 128. In the 1993 and later editions, data element 65 can in turn signal a tertiary bitmap covering 129 to 192, which is exceptionally rare in production.

Take the message from the worked example, which carries data elements 2, 3, 4, 7, 11, 12, 13, 14, 18, 22, 25, 32, 37, 41, 42, 43 and 49, and no secondary bitmap. Writing a 1 in each of those positions and a 0 everywhere else:

0111 0010 0011 1100 0100 0100 1000 0001
0000 1000 1110 0000 1000 0000 0000 0000

Grouped into nibbles and written in hexadecimal, that is:

723C448108E08000

Eight bytes. Seventeen fields declared. No field names, no delimiters, no terminators, no ambiguity about order. Going the other way, 7010001102C04804 expands to

0111 0000 0001 0000 0000 0000 0001 0001
0000 0010 1100 0000 0100 1000 0000 0100

which declares elements 2, 3, 4, 12, 28, 32, 39, 41, 42, 50, 53 and 62 — a response message, carrying a card number, processing code, amount, local time, fee, acquirer identifier, response code, terminal, merchant, settlement currency, security control information and one private field. You can read the shape of a transaction off eight bytes before parsing a single value, which is why network engineers debug card traffic from hex dumps.

Data element notation#

Each data element is defined by a content type and a length rule.

Length is either fixed or variable. A fixed field is written with its length: n 6 is exactly six digits. A variable field carries its own length in a prefix, written as leading dots: n..19 is an LLVAR field, a two-digit length followed by up to nineteen digits; ans...999 is an LLLVAR field, a three-digit length followed by up to 999 characters. Clause 4.4.2 onwards distinguishes primitive elements, which have no internal structure; constructed elements, holding a fixed number of sub-elements all of which must be present; and, from 2003, composite elements, which contain datasets indexed by a second-level dataset bitmap or encoded as tag-length-value under ISO/IEC 8825.

The elements that carry a purchase#

Several of these repay a closer look.

DE3, processing code, is six digits in three pairs: transaction type, the account the money comes from, the account it goes to. 000000 is a purchase from the default account, 010000 a cash withdrawal, 200000 a refund, 300000 a balance enquiry. The account-type pairs are where implementations diverge most visibly, and the divergence is public: Mastercard’s Single Message System material uses 00 for no account specified, 10 for savings, 20 for checking and 30 for a credit card account, while Worldpay’s published Lync ISO 8583 message specification builds cash withdrawal from savings as 010100 and cash advance from credit as 010300. Both describe ISO 8583. Neither is wrong. They are not the same dialect.

DE4, amount, is twelve digits with no sign and no decimal separator. The implied decimal position comes from the currency in DE49, an ISO 4217 code: 826 for pounds sterling and 840 for US dollars, both with two minor digits; 392 for Japanese yen, with none; 414 for Kuwaiti dinar, with three. A system that stores amounts as decimal strings and infers the exponent from the currency will survive; one that stores them as floating-point will not.

DE7, DE12 and DE13 are three different clocks. DE7 is the transmission date and time in MMDDhhmmss, expressed in Coordinated Universal Time by the sender of that particular message, and it changes at every hop. DE12 is the local transaction time at the point of sale, hhmmss, and DE13 the local transaction date, MMDD. Neither carries a year in the 1987 edition, so a system reconstructing a full timestamp has to supply the year from somewhere else, and the last week of December is where that assumption goes to die.

DE11, the system trace audit number, is six digits assigned by the message originator. It is not globally unique and was never meant to be: it is unique within one acquirer, within one processing day, and it wraps at 999999. Its job is to let the two ends of one link match a response to a request.

DE37, the retrieval reference number, is twelve alphanumeric characters and is the identifier that survives longest into the dispute process. Its internal construction is not fixed by ISO; a common convention is a single-digit year, a three-digit day of year, a two-digit hour and a six-digit sequence, which is how the example 607614430041 was built: year 6, day 076 (17 March), hour 14, sequence 430041.

DE38, the authorisation identification response, is the six-character approval code the issuer generates and the receipt prints. DE39 is the response code: two alphanumeric characters in the 1987 edition, three in 1993.

DE55 is where EMV lives, and it is a format inside a format. The 2023 standard is explicit that the composite dataset structure “does not apply to the integrated circuit card (ICC)-related data element, as the linking of related sub-elements shall be accomplished in accordance with the definitions given in ISO/IEC 7816-6”. DE55 is therefore a bag of EMV tag-length-value objects — the application cryptogram in tag 9F26, the cryptogram information data in 9F27, the application transaction counter in 9F36, the terminal verification results in 95, the unpredictable number in 9F37 — parsed by entirely different rules from the message carrying them, and commonly capped by schemes far below the ISO maximum of 999 bytes.

DE52 carries the PIN, always enciphered, as a 64-bit block formatted according to ISO 9564-1. Format 0 blocks, which combine the PIN with digits of the account number, dominate the installed base; format 4 exists to allow AES. DE64 and its secondary-bitmap twin DE128 carry a message authentication code computed with a shared key, so the receiver can detect tampering in transit.

DE90, original data elements, is forty-two digits and is a constructed field in the strict sense: five sub-elements, all mandatory, no length prefixes, laid out end to end.

Four plus six plus ten plus eleven plus eleven is forty-two. DE90 is how a reversal names its victim, and the fact that it needs five separate fields to do so tells you something true and slightly alarming about how transactions are identified in this format.

Why a bitmap rather than a text format#

The engineering argument has four parts, and only the first is about size.

Size. The worked authorisation above, encoded with ASCII digits and a hexadecimal bitmap, is 181 bytes; with packed binary-coded decimal numerics and a raw binary bitmap it is 129. The same content as tagged text with descriptive names is 639 bytes, and with the tags reduced to bare field numbers it is 289. On a 1,200 bit-per-second dial-up link with start and stop bits — ten bits per character — that is the difference between roughly eleven seconds of round trip and roughly two. On a 9,600 bit-per-second X.25 leased line shared between hundreds of terminals, it is the difference between a switch that copes at the Saturday peak and one that does not.

Determinism. A bitmap-indexed message can be parsed with a fixed loop, a lookup table and no dynamic memory allocation whatsoever. There is no tokeniser, no nesting, no escaping, no quoting and no ambiguity about whether a value is a string or a number, because the field definition already said. A terminal with sixteen kilobytes of RAM could parse this in 1987, and a switch handling tens of thousands of messages a second can parse it now without a garbage collector ever running.

Bounded worst case. Every field has a maximum length declared in the specification, so the largest possible message is computable in advance and buffers can be statically sized. Text formats have no such property.

Honesty about what it costs. All four of those advantages come from positional encoding, and positional encoding has one enormous liability: the message is not self-describing. A malformed bitmap does not produce a parse error at the malformed byte; it produces a message in which every subsequent field is read at the wrong offset with the wrong length, and the failure surfaces somewhere else entirely, often as a nonsense amount. Anyone who has debugged card traffic has seen a £42.50 purchase arrive as £4,250,000 because one field upstream was written one digit short.

The three versions, and why 1987 will not die#

1987, the first edition, defined 128 data elements, a two-character response code in DE39, and DE24 as a network international identifier used for routing.

1993 kept the message structure identical and changed the vocabulary. The most consequential change was to response codes, which became three digits arranged so that the leading digit tells you which class of message the code belongs to:

So 000 is approved, 100 is do not honour, 101 is expired card, 116 is insufficient funds, 200 is do not honour and retain the card, 911 is issuer timed out. Within each hundred, the standard reserves blocks for ISO, national and private use, so a scheme can invent codes without colliding with the standard. It is a better design than the 1987 flat two-digit list in every respect. DE24 was redefined as a function code, and the data element count rose to a possible 192 through a tertiary bitmap.

2003 went further and broke things. Currency ceased to be a standalone data element and became a sub-element of each amount, which is arguably correct and which invalidates every parser written for the previous sixteen years. Composite data elements and datasets arrived, along with the option of encoding sub-elements as tag-length-value under ISO/IEC 8825.

2023 restructured the document, moved the definitions to a maintenance agency, folded in accumulated corrections approved by the registration and maintenance management group, and reused version digit 2.

Deployment tells a different story from publication. Visa’s BASE I technical specifications, which define the authorisation messages of the V.I.P. system, are built on the 1987 edition with a large body of Visa-specific additions. Mastercard’s Customer Interface Specification carries authorisations as 1987-version messages; its Integrated Product Messages clearing formats carry presentments and chargebacks as 1993-version messages such as the First Presentment/1240. The 2003 edition, twenty-three years after publication, never achieved meaningful adoption on scheme links at all.

The reason is not inertia in the pejorative sense. It is arithmetic. A card network is a mesh of bilaterally certified endpoints — acquirers, processors, gateways, issuer hosts, ATM estates, terminal fleets — numbering in the tens of thousands, and every pair that exchanges messages has been through a certification process that produced a signed test result. A change to the wire format requires every one of those pairs to re-certify, and a flag day on which both ends switch simultaneously, because a 1987 parser handed a 2003 message does not degrade gracefully; it misreads the amount. The value of the newer edition is real but marginal, and the cost of the transition is catastrophic. So the industry stayed on 1987 and expressed everything new in private-use fields, which brings us to the part that actually costs money.

What “ISO 8583 compliant” is worth#

Roughly nothing, on its own. The right question is never “is it ISO 8583?” but “which specification, which version of that specification, and have you got the certification letter?”

Every network of consequence publishes its own document. A partial list of the names, which is useful because these documents are what integration projects actually work from:

They diverge in ways that go well past field contents. Visa’s BASE I messages are normally carried with a 22-byte header whose values determine the format variant of certain data elements, and BASE I places data elements in three bitmapped arrays of 64 elements each, with all three bitmaps positioned together after the message type and before the message body — rather than deriving the second and third from bit 1 of the primary and bit 1 of DE65, as the standard describes. A parser written strictly to ISO will not read a BASE I message at all.

Mastercard carries the bulk of its proprietary content in private data. In authorisation messages that content lives in numbered subelements of DE48; in clearing messages it lives in private data subelements, the four-digit PDS tags such as PDS 0032 for enhanced acceptor name or PDS 0198 for device type indicator. The same business fact appears in a different container depending on whether you are looking at the authorisation or the clearing record, which is a large part of why reconciliation between the two is the work it is.

Below the schemes, national and vendor dialects abound. Australia’s AS 2805 series incorporates ISO 8583 and extends it across a far wider range of payment topics; processor platforms such as ACI’s BASE24 define their own external message formats, ISO 8583 in shape and proprietary in content. Data elements 60 to 63 and 120 to 127 are reserved for private use in the standard itself, which is its way of saying: put your incompatibilities here, and stop asking us.

The practical consequence is that conformance is not a property of your code. It is a property of a certification event between your endpoint and one named counterparty, on one named specification, at one named version, evidenced by a test script both sides signed. “We are ISO 8583 compliant” is a statement about a shape.

Message flow#

Request and response. The acquirer sends 0100; the issuer answers 0110. The response echoes the fields the two sides use to match it to the request — conventionally DE7, DE11, DE32 and DE37, though the precise matching key is set by each scheme and not by ISO — and adds DE38 and DE39. The acquirer runs a timer, and if it expires the acquirer does not know whether the issuer approved, because a response can be lost after the issuer has already committed a hold. That ambiguity is the origin of most of what follows.

Repeat. On a timeout, the acquirer may retransmit with origin digit 1 instead of 0, producing 0101. Per clause 4.2 the repeat must be byte-identical apart from the MTI, the transmission date and time and the MAC. The issuer, seeing the same STAN and retrieval reference number, is expected to return the original decision rather than authorise a second time.

Reversal. If the acquirer concludes that the transaction did not complete — timeout after retries, a customer who removed the card, a till that crashed mid-sale — it sends 0400, quoting DE90 so the issuer can find the original, and expects 0410. Reversals are retried persistently, sometimes for days, because an unreversed authorisation leaves the cardholder’s available balance reduced against a purchase that never happened. Where the acquirer is stating a fact rather than asking permission, it uses the advice form 0420, acknowledged with 0430.

Advice. Advices exist for everything that happened before anyone could ask. A terminal that authorised offline because the amount fell below its floor limit sends 0220. A transaction approved by the scheme on the issuer’s behalf while its host was unreachable — stand-in processing — reaches the issuer as an advice, because by then the answer has already been given to the merchant.

Completion. A pre-authorisation taken at a hotel check-in or a fuel pump is 0100 for an estimated amount; the final amount arrives later as a financial advice 0220, which is why a hotel hold can sit on a card for days after checkout.

Network management. 0800 and 0810 keep the link itself alive. DE70, the network management information code, distinguishes the purposes; the values almost universally implemented are 001 for sign-on, 002 for sign-off and 301 for an echo test. Echo tests run every few seconds on a live link, and a switch that stops answering them is taken out of rotation before any customer notices. When you read that a card network was “down for eleven minutes”, the detection almost certainly happened in an 0800.

Reconciliation. Class 5 messages carry the totals each side believes it exchanged during a settlement window — counts and amounts of credits, debits, reversals and fees, in data elements 74 to 89.

One authorisation, framed for the wire#

What actually leaves a terminal is not an ISO 8583 message. It is an ISO 8583 message wrapped in whatever the link demands. A typical arrangement over TCP:

The five-byte transport header is a Transaction Protocol Data Unit, inherited from an older transport standard and kept because ISO 8583 itself contains no routing information at all. Its convention is one byte of protocol identifier, conventionally 60, then two bytes of destination address and two of source address; the response is formed by swapping the two addresses. None of it is in ISO 8583. All of it is mandatory in practice.

Where it runs out#

The pressure on ISO 8583 is not performance. Switches process these messages in tens of microseconds. It is that the world now wants to say things the format has no room for: full merchant and payee details for sanctions screening, structured remittance information, extended tokenisation data, richer fraud signals, and the growing bulk of EMV data in DE55. The industry’s answer for thirty years has been to overload private fields with sub-formats — subelements inside DE48, PDS tags inside clearing records, TLV inside DE55 — until a message contains three different encoding schemes nested inside each other and the integration cost of any change is measured in quarters.

That is the case for ISO 20022, and the subject of a later chapter. ISO 8583 is not being replaced because it failed, but because it succeeded so completely that a format designed to fit a purchase down a 1,200 bit-per-second telephone line is now the constraint on what a purchase is allowed to mean.

The next chapter takes the bitmap on its own and shows, bit by bit, what those sixty-four flags do to the parser at the other end.

24.98 Common wrong ideas#

Wrong: ISO 8583 is the language of card payments. Right: it is a filing convention specifying the shape of the envelope, and since 2023 the standard does not even contain the message, field and code definitions, which now live in a separately maintained register.

Wrong: two systems that are both faithful to ISO 8583 can exchange messages. Right: faithfulness settles nothing about what goes in DE 48 or DE 62, or what response code 05 means to you as opposed to me; conformance is a property of a certification event between two named endpoints, not of your code.

Wrong: ISO 8583 is a binary format. Right: only the bitmap is genuinely binary; the rest is usually characters in ASCII or EBCDIC, and because the standard permits both packed and unpacked numerics the same logical message is 129 bytes on one link and 181 on another.

Wrong: a data element number means the same thing in every edition. Right: DE 24 is a network routing identifier in 1987 and a function code in 1993, and response codes are two characters in 1987 and three in 1993.

Wrong: a response code of 00 means the money moved. Right: it means the issuer agreed that it would; the instruction that shifts funds between banks is a different message sent later, often the following day.

Wrong: the amount field carries its own currency and decimal point. Right: DE 4 is twelve unsigned digits with no separator, and the implied decimal position comes from the ISO 4217 code in DE 49 — two places for sterling, none for yen, three for the Kuwaiti dinar.

Wrong: a repeat message is simply another attempt. Right: clause 4.2 requires it to be identical to its original apart from the message type identifier, the transmission date and time and the MAC, which is precisely how the receiver knows it may be a duplicate rather than a second purchase.

Wrong: DE 11 uniquely identifies a transaction. Right: the system trace audit number is unique only within one acquirer within one processing day and wraps at 999999; DE 37 is the identifier that survives into the dispute process.

Wrong: a parser written strictly to the standard will read any scheme’s traffic. Right: Visa’s BASE I carries a 22-byte header and places three bitmapped arrays together after the message type rather than deriving them from bit 1, so a strictly conformant parser will not read a BASE I message at all.

Wrong: the industry stays on the 1987 edition out of inertia. Right: it is arithmetic — tens of thousands of bilaterally certified endpoint pairs would each have to re-certify and switch on a flag day, because a 1987 parser handed a 2003 message does not fail cleanly, it misreads the amount.

24.99 Chapter summary in 20 lines#

1. ISO 8583 is not a language but a filing convention: an agreement about which numbered box holds which value, and how to tell the other end which boxes you bothered to fill in.
2. The whole trick is the bitmap, sixty-four bits declaring the presence or absence of each data element, so that no field name ever has to travel.
3. That compression was necessity rather than elegance: at 1,200 bits per second the difference between labelled text and numbered boxes was the difference between a customer waiting eleven seconds and waiting two.
4. Every message is a message type, one or two bitmaps, and then the data elements in bitmap order, with no framing, no terminator and no length, all of which are the transport’s problem.
5. The four-digit message type indicator encodes version, class, function and origin, and reading it digit by digit tells you what kind of message you are holding before you parse anything else.
6. There are really only four kinds of message: a question that may be refused, an answer, an advice that may only be acknowledged, and a cancellation that quotes the message it wants undone.
7. The 2023 third edition moved the messages, data elements and code values out of the standard into a register held by a maintenance agency, so that they can change without republishing an International Standard.
8. It also reused version digit 2, formally conceding that nothing had changed in a way that affects how a message is constructed or parsed.
9. The standard is silent about transport, framing, integrity and settlement, so every deployment bolts on a length prefix, a routing header inherited from an older standard, and a cryptographic checksum.
10. Data elements are defined by a content type and a length rule, fixed or variable, with the variable ones carrying two- or three-digit length prefixes of their own.
11. DE 4 carries twelve digits with no decimal separator, and the exponent comes from the ISO 4217 currency code in DE 49, which is why floating-point storage of amounts does not survive contact with this format.
12. DE 7, DE 12 and DE 13 are three different clocks — universal time rewritten at every hop, and a local time and date carrying no year at all.
13. DE 11 matches a response to a request across one link, while DE 37 is the twelve-character handle that survives into clearing and into a dispute months later.
14. DE 55 is a format inside a format: EMV tag-length-value objects linked according to ISO/IEC 7816-6, carried inside a message parsed by entirely different rules.
15. DE 90 names the victim of a reversal with five mandatory sub-elements totalling forty-two digits, which says something true and slightly alarming about how transactions are identified here.
16. The bitmap buys size, deterministic parsing, a bounded worst case and no dynamic allocation, at the single cost that the message is not self-describing.
17. A malformed bitmap therefore does not fail at the malformed byte; every later field is read at the wrong offset, and a £42.50 purchase arrives as £4,250,000.
18. The 1993 edition’s three-digit response codes, classed by leading digit, are better than the 1987 flat list in every respect and still lost, because re-certifying the mesh costs more than the improvement is worth.
19. Every network of consequence publishes its own specification, and the divergences run past field contents into bitmap layout and private data, so “we are ISO 8583 compliant” is a statement about a shape.
20. The format is not being replaced because it failed but because it succeeded so completely that a design fitted to a 1,200 bit-per-second telephone line is now the constraint on what a purchase is allowed to mean.

Chapter sources: ISO 8583:2023, third edition, clauses 1, 3, 4 and 7 and Table 1; ISO catalogue entries for ISO 8583:1993, ISO 8583-1:2003 and ISO 8583:2023; the ISO register of maintenance agencies; ISO 4217; ISO 9564-1; ISO/IEC 7812-1 and ISO/IEC 7816-6; Mastercard Switch Rules, Transaction Processing Rules, Single Message System documentation and Mastercard Developers material for message types 1240 and 1442, DE48 subelements and PDS tags 0032 and 0198; Worldpay Lync ISO 8583 Message Specification v1.3 for processing codes; iso8583.info for the Visa BASE I message structure and the scheme specification names; EFTlab for the Transaction Protocol Data Unit; and the Wikipedia ISO 8583 article for the consolidated 1987 and 1993 data element and response code tables, cross-checked against the standard text where possible.