ISO 8583 Bitmap Decoder

What the bitmap does

ISO 8583 messages have no field delimiters. Instead, a bitmap at the front declares which data elements are present, and the receiver reads them in numerical order using the format definitions it already holds. Eight bytes, sixty-four bits, one per data element.

Bit 1 — the most significant bit of the first byte — is special. It is not DE 1; it signals that a secondary bitmap follows, covering DE 65 to 128. Within that secondary bitmap, DE 65 in turn signals a tertiary bitmap for DE 129 to 192, though you will rarely meet one in the wild.

A practical consequence: if the first hex digit of your bitmap is 8 or higher, there is a secondary bitmap and the message data starts 16 bytes in, not 8. Getting this wrong shifts every subsequent field and produces the classic "everything parses as garbage" symptom.

Finding the bitmap in a raw message

In an ASCII-encoded message the layout is normally a length header, then four characters of MTI, then the bitmap. The bitmap itself may be 16 hex characters (ASCII-encoded, one character per nibble) or 8 raw bytes (binary) depending on the endpoint. Both are common; only the endpoint's specification tells you which.

If a bitmap decode gives you an implausible field set — DE 3 and DE 4 missing from an authorisation, say — you are probably off by the length header, or reading ASCII as binary.

Why the rest of the message is harder

The bitmap is the one part of ISO 8583 that works the same everywhere. Field contents are another matter: DE 48, 60-63 and 120-127 are reserved for private use and every processor defines them differently, often as nested TLV or positional substructures. That is why this tool decodes the bitmap and the field names rather than pretending to parse a whole message — doing that properly needs your acquirer's specification, not a generic parser.

One field is worth pulling out separately: DE 55 is EMV chip data in BER-TLV form. Paste it into the TLV parser.