ISO 8583:1987 (ASCII)

Introduction

An ISO 8583 message is a message type indicator, a bitmap, and the data elements the bitmap says are present.

The message type indicator is four digits and each one means something. The first is the version of the standard; the second is the class of business — authorization, financial, reversal, network management; the third is the function, which is what separates a request from the response that answers it; and the fourth is who originated it. That is why 0100 and 0110 are a pair: same version, same class, one asks and one answers.

The bitmap says which data elements the message carries. Each bit stands for one element, so a message contains only what it needs and a reader knows what to expect before parsing any of it. Elements are numbered, not named, and the names in this document are what the standard calls them.

An element may be a single value or a composite of parts. Positional parts are fixed slices of a fixed-width field, read by their offset. TLV parts each carry their own tag and length, so a message may carry parts this document does not list, and those are preserved rather than dropped.

Amounts are in the minor unit of their currency, which is the last thing to get wrong: 1000 in a two-decimal currency is 10.00, and in a currency with no minor unit it is 1000. Each amount here names the element that carries its currency.

What this document cannot tell you is what a scheme requires of you. The standard defines the elements; a scheme decides which ones it wants, what its own codes mean, and what it does with the ones it did not anticipate. Those are in the documents under References, and they are obtained from their publishers.

How to read this

A rule may carry a condition, shown under When: it applies only where the condition holds, and the first matching rule wins.

Help

The words this reference uses, and what each one means. Every one of them is a link from wherever it appears above.

Usage

conditional

The element has more than one rule in this message, and which applies depends on what else the message carries. The rules are listed beside it under When, in the order they are evaluated: the first match wins.

forbidden

The element must not be present. A request carrying a response code is the usual example — the answer to a question nobody has answered yet.

mandatory

The element must be present in that message. A message without it is malformed, whatever else it carries.

optional

The element may be present. Saying so is not the same as leaving it unlisted: it records that someone considered it and decided either way is correct.

Response value

echo

The response must carry the same value the request did. It is the sharpest conformance check available: a trace number that comes back changed means correlation is broken, and the switch that changed it is the fault.

modified

The value comes from the request's but may differ, and the difference is the point. A partial approval returns less than the amount asked for, so this must not be compared for equality — only that it relates.

new

The responder produced this value; there was nothing in the request to echo. A response code is the case — the issuer decides it, and comparing it to anything in the request is meaningless.

varies

This element's rules for the message do not agree on where its value comes from. The distinction is per case, and the element's own section carries it.

Composites

bitmapped

A leading bitmap says which parts the element carries, the same way a message's bitmap says which elements it carries.

positional

The element is a fixed-width string cut into parts at fixed offsets. Nothing in the message says where one part ends, so the layout is the only thing that knows.

tlv

Each part announces itself with a tag and a length, so a message may carry parts this document does not list. Those are preserved on the way through rather than dropped: a switch that discards what it did not recognise breaks the parties either side of it.

Value kinds

amount

A figure in the minor unit of the currency named beside it: 1000 is 10.00 where the currency has two decimals, and 1000 where it has none. Dividing by a fixed hundred is the mistake this kind exists to prevent. A rule compares it as a number, so it matches whatever padding the element is written with.

date

A date in the layout the element declares. Comparisons on it are chronological rather than lexical, so an expiry compares as a date and not as a string of digits.

datetime

A combined date and time in the layout the element declares, compared chronologically.

numeric

A value that is a number rather than a code: a trace number, a sequence, a count. A rule compares it as a number, so the padding it is written with does not matter. This is the difference from an element with no kind at all, which compares as the characters it carries -- and has to, because a response code of "00" is not "0".

time

A time in the layout the element declares, compared chronologically.

Classification

chd

Cardholder data under the PCI definition: masked in logs and console output.

pan

The cardholder's account number. It is masked in logs and console output wherever it appears, and the masking follows the classification: it cannot be switched off by the spec that declared it. It is digits and it is not a number: a leading zero makes it a different card, so a rule compares the characters it carries.

pii

Personal data about the cardholder rather than the card. Masked in logs and console output.

sad

Sensitive authentication data — a PIN block, a cryptogram, track data. Masked in logs, and never retained after authorization.

Wire types

Binary

Raw bytes, passed through without interpretation.

Bitmap

The bitmap itself: one bit per element, saying which the message carries. A second bitmap follows when the first says so.

Composite

An element built from parts rather than holding one value. How the parts are found is the layout — positional, tlv or bitmapped.

Hex

Bytes written as pairs of hexadecimal characters, so one byte occupies two.

Numeric

Digits, right-aligned and padded with zeros to the declared length.

String

The value is characters in the field's encoding. Most elements are this, including numeric ones that travel as digits rather than as packed numbers.

Track2

Track 2 of a magnetic stripe, with its own separator between the account number and the rest.

Encodings

ASCII

Characters as ASCII, one byte each. The most common encoding in a modern interface.

BCD

Binary-coded decimal: two digits share a byte, so a six-digit value occupies three. Halves the bytes on the wire and doubles the ways to get the length wrong.

BerTLVTag

A BER-TLV tag as EMV writes them: one byte, or two when the first says the tag continues.

EBCDIC

The character encoding of IBM mainframes, still in use wherever the host at one end of the link is one.

Length prefixes

ASCII.Fixed

There is no length on the wire. The element is exactly as long as the spec says, always.

ASCII.LL

Two ASCII digits precede the value and give its length, so the element can be up to 99 long.

ASCII.LLL

Three ASCII digits precede the value and give its length, up to 999.

BerTLV

A BER length: one byte for short values, or a byte saying how many length bytes follow for longer ones.

Value sets

Every set this spec declares, and the elements it governs. A set is documented here once; the elements that use it link back to this.

account_type

Governs DE 3, DE 54.

This list is complete; anything else is invalid.

currency_iso4217

Governs DE 49, DE 50, DE 51, DE 54, DE 55.

This list is complete; anything else is invalid.

network_mgmt_code

Governs DE 70.

The documented set. Others may occur.

pos_entry_mode

Governs DE 22.

This list is complete; anything else is invalid.

processing_txn_type

Governs DE 3.

This list is complete; anything else is invalid.

response_code

Governs DE 39.

The documented set. Others may occur.

References

The documents this spec was written from. They are cited, not carried: a standards body sells its own, and a scheme issues its own under its terms.

• ISO 8583-1:2003, Financial transaction card originated messages — International Organization for Standardization
  Sold by ISO and by national standards bodies. The 1987 edition this spec follows is withdrawn and obtained the same way.
  https://www.iso.org/standard/31628.html
• EMV Integrated Circuit Card Specifications, Book 3 — Application Specification — EMVCo, LLC
  Annex A is the data element dictionary the tags under DE 55 come from. EMVCo publishes the specifications for download at no charge, under its own terms of use; the tag numbers and short names here are the labels, not the dictionary text.
  https://www.emvco.com/specifications/
• Scheme interface manuals
  Each scheme issues its own under its own terms, to its members. They are what decide which elements a scheme requires, what its private codes mean, and how it treats values it did not anticipate — none of which the standard settles.
• moov-io/iso8583 — Moov Financial, Inc.
  The wire vocabulary this spec consumes rather than restates. Apache 2.0.
  https://github.com/moov-io/iso8583

The spec, as written

Sections fold; the top two levels start open.

The wire layer, resolved

Not part of the document above. moov:spec87ascii names a base resolved from the linked library, so it cannot drift from upstream and arrives with a dependency update. This is that base with this spec's own overrides applied.