What Is ISO 8583?

What ISO 8583 actually is

It is an international standard for financial transaction card-originated messages. It does not describe a network, an API or a product — it describes how to lay bytes out so two systems that have never met can agree on what a payment request says. That is why a 1987 standard still carries most of the world's card traffic: the format outlived every technology built on top of it.

Three editions exist — 1987, 1993 and 2003 — and 1987 is still the one you are most likely to meet. They differ in which fields exist and how wide some of them are, so the edition is not a footnote: the same bytes can decode differently under two editions. The first digit of the MTI tells you which one you are reading.

Almost nobody runs plain ISO 8583. Visa, Mastercard, and domestic switches each publish their own dialect: the same field numbers, their own meanings for the private fields, their own extra codes, sometimes their own character encoding. The standard gives you the envelope; the scheme specification tells you what is written inside. Treat any implementation guide you are handed as the authority over the base standard where the two disagree.

The shape of a message

Read a message left to right in three parts.

1. The MTI — four digits saying what this message is

Each digit does one job:

So 0100 is a 1987 authorization request from an acquirer, and 0110 is the response to it. 0400 is a reversal request, 0800 a network management message such as a sign-on or an echo test. Reading the four digits separately is faster than memorising a list of MTIs.

2. The bitmap — which fields are in this message

The bitmap is 64 bits, usually written as 16 hex characters. Bit n set means data element n is present, in ascending order, and absent fields simply are not there — there is no padding and no placeholder. That is the whole trick of the format: it stays compact without a schema, because the bitmap is the schema.

Bit 1 is special: it does not mean DE1, it means a second bitmap follows, extending the range to DE128. If bit 1 is not set, the message stops at DE64 and there are only 16 hex characters of bitmap.

Two mistakes account for most bitmap bugs: counting bits from 0 instead of 1, and forgetting that the bitmap can be sent as raw binary (8 bytes) rather than hex text (16 characters). Both produce fields that parse one position out.

3. The data elements — the values themselves

Each field is either fixed length, or prefixed by its own length:

The declared length is counted in characters of the value, which is not always bytes: under Hex/BCD two digits pack into one byte, and a binary field's length may be given in bytes or in bits depending on the specification. When a parser drifts one field at a time, the length unit is the first thing to check.

A message, decoded

Here is a complete authorization request, assembled from a test card number and a placeholder terminal. Nothing here is real cardholder data.

010072200000008080001641111111111111110000000000000010000821143000123456TERM0001702

Taken apart, left to right:

Notice that DE4 means nothing until DE49 is read. That ordering — currency before amount — is the single most common source of amounts that are wrong by a factor of a hundred.

You can paste the message above into the parser on the home page and watch it come apart field by field.

The fields you will actually touch

There are 128 data elements. In practice a handful carry almost every question you will be asked:

The field dictionary has all 128 with lengths, formats and notes.

The code tables

Most ISO 8583 work is not parsing — it is looking up what a value means. The tables worth bookmarking:

• DE39 response codes — why a transaction was declined, and whether retrying is sensible.
• DE3 processing codes — the full transaction-type and account-type list, code by code.
• DE22 POS entry modes — magstripe, chip, contactless, keyed, and what each implies.
• MTI decoder — the four digits, taken apart.
• EMV TLV tags — for the contents of DE55.
• ISO 4217 currency codes — including how many decimals each currency has.

Where implementations differ

Four places where the standard stops and someone else's document takes over. Every one of them has cost somebody a week.

• The private fields. DE48, DE60–DE63 and friends are reserved for private use, which means each scheme fills them with its own sub-structure. There is no universal decode. If you do not have the specification, you cannot read them — and guessing produces something that looks plausible and is wrong.
• Character encoding. ASCII, EBCDIC and Hex/BCD are all in use, sometimes for different fields of the same message. A message that decodes to mojibake is usually an encoding assumption, not a corrupt file.
• Field widths across editions. DE22 is three digits in 1987 and twelve in 2003. A parser built for one edition will silently misread the other from that field onward.
• Extra codes. Schemes add response codes and processing codes beyond the standard list. An unfamiliar value is far more likely to be scheme-specific than invalid, so fail soft and log it rather than rejecting the message.

Frequently asked questions

Is ISO 8583 still used?

Yes — it carries the large majority of card authorization traffic worldwide. ISO 20022 is growing in account-to-account and instant payments, and some schemes are migrating, but card rails run on 8583 and will for years. The two coexist rather than one having replaced the other.

What is the difference between ISO 8583 and ISO 20022?

8583 is compact positional bytes designed for 1980s links; 20022 is XML or JSON with a rich data model. 8583 says less in far fewer bytes, which is why it survives on latency-sensitive card networks. They are different formats for overlapping jobs, not versions of one thing.

Do I need the paid standard to work with ISO 8583?

For the base structure — MTI, bitmap, field numbers, lengths — no; that is well documented publicly, including on this site. For the private fields and the extra codes your traffic actually contains, you need the specification from your scheme or processor. That part is not public and cannot be inferred.

Why does my parser drift after a few fields?

Nearly always a length unit or an encoding: a binary field whose length is in bytes read as characters, a Hex/BCD field read as ASCII, or a bitmap sent as 8 raw bytes read as 16 hex characters. Find the last field that decoded correctly and check its length rule.

Read next

• Worked ISO 8583 message examples
• ISO 8583 field dictionary (DE2–DE128)
• The full DE3 processing code list
• An ISO 8583 learning path