Payment Messaging Standards: ISO 8583 & ISO 20022

Message Structure: MTI, Bitmap & Data Elements

Every ISO 8583 message has three structural components:

• Message Type Indicator (MTI) — a 4-digit code encoding version, message class, message function, and transaction originator. MTI 0100 means: version 0 (ISO 8583:1987), financial message class (0xxx), request function (xx0x), acquirer originator (xxx0).
• Primary Bitmap — 8 bytes (64 bits) where each bit indicates whether the corresponding Data Element (DE01–DE64) is present in the message. Bit 1 of the primary bitmap, when set, signals the presence of a Secondary Bitmap (DE65–DE128), extending the message to 128 potential fields.
• Data Elements (DEs) — variable-length or fixed-length fields carrying the transaction data. Each DE has a defined format (n = numeric, a = alpha, an = alphanumeric, b = binary, z = track 2) and maximum length.

Bitmap Interpretation

To read a primary bitmap, convert each hex byte to 8 binary bits and map bit positions to DE numbers. A bit value of 1 means the field is present; 0 means absent.

Primary Bitmap (hex):  F2 3C 40 81 28 E0 92 00

Byte 1: F2 = 1111 0010  → DE01 DE02 DE03 DE04 _ _ DE07 _
Byte 2: 3C = 0011 1100  → _ _ DE11 DE12 DE13 DE14 _ _
Byte 3: 40 = 0100 0000  → _ DE19 _ _ _ _ _ _
Byte 4: 81 = 1000 0001  → DE25 _ _ _ _ _ _ DE32
Byte 5: 28 = 0010 1000  → _ _ DE38 _ DE41 _ _ _
Byte 6: E0 = 1110 0000  → DE42 DE43 DE44 _ _ _ _ _
Byte 7: 92 = 1001 0010  → DE49 _ _ _ DE53 _ _ _  (bit 1 = secondary bitmap present? No: DE65 not set in byte 1 bit 1 = 1 — yes, secondary present if DE01=1)
Byte 8: 00 = 0000 0000  → no fields DE57–DE64

Note: DE01 = 1 (F2 bit 1 = 1) → Secondary Bitmap present in this message.
Fields present: DE02, DE03, DE04, DE07, DE11, DE12, DE13, DE14,
                DE19, DE25, DE32, DE38, DE41, DE42, DE43, DE44, DE49, DE53

Key Data Elements Reference

Message Type Pairs

ISO 8583 uses request/response pairs and advice/acknowledgement pairs. Understanding the pairing logic is critical for timeout handling and duplicate detection:

Sample 0100 Message — Hex Dump Interpretation

The following illustrates how to read a raw 0100 authorisation request off the wire. Field boundaries are computed by reading the bitmap and applying each DE’s length rules:

Raw hex (simplified example — TPDU omitted):

  30 31 30 30                        ← MTI: "0100" (ASCII-encoded)
  72 34 04 C0 28 80 10 00            ← Primary Bitmap
  10 4761739001010119                ← DE02: LLVAR n19 — PAN (len=10 encoded as "10", PAN follows)
  00 00 00                           ← DE03: Processing Code "000000" (purchase, from/to unspecified)
  00 00 00 01 00 00                  ← DE04: Amount "000000010000" = 100.00 in minor units
  04 02 11 49 30                     ← DE07: Transmission DateTime "0402114930" = Apr 02 11:49:30 UTC
  00 04 37                           ← DE11: STAN "000437"
  11 49 30                           ← DE12: Local Time "114930"
  04 02                              ← DE13: Local Date "0402"
  27 01                              ← DE22: POS Entry Mode "270" — 07=contactless, 0=unverified PIN
  31 36 35 34 30 30 30 30 30 30 30 31← DE41: TID "16540000001" (8 bytes, space-padded)
  31 32 33 34 35 36 37 38 39 41 42 43← DE42: MID "123456789ABC" (15 bytes, space-padded)
  08 40                              ← DE49: Currency Code "840" (USD)

Field breakdown:
  ├── MTI       : 0100   (Auth Request, Acquirer-originated)
  ├── DE02 (PAN): 4761739001010119  [masked in logs as 476173******0119]
  ├── DE03      : 000000  (Purchase transaction)
  ├── DE04      : 000000010000  (USD 100.00)
  ├── DE07      : 0402114930  (Apr 02, 11:49:30 UTC)
  ├── DE11      : 000437  (STAN for retry/duplicate matching)
  ├── DE12      : 114930  (local time)
  ├── DE13      : 0402   (local date)
  ├── DE22      : 270    (contactless NFC entry, unverified PIN capability)
  ├── DE41      : 16540000001  (Terminal ID)
  ├── DE42      : 123456789ABC  (Merchant ID)
  └── DE49      : 840   (USD)

Network Management — Sign-On & Sign-Off

Before a terminal or host can process transactions, it must establish a session with the switch using 0800 Network Management messages:

• Sign-On (0800 / DE70=001) — terminal sends an 0800 with DE70 set to 001. The switch validates the terminal ID and PIN key exchange (where applicable), then responds with an 0810 and DE39=00 to confirm the session is active.
• Sign-Off (0800 / DE70=002) — terminal sends an 0800 with DE70=002 at end of business or before a restart. The switch closes the session.
• Echo Test (0800 / DE70=301) — used for keep-alive / link health monitoring. The switch echoes DE70 back in the 0810 response; a response of DE39=00 confirms the communications path is active.

Network Interface Identifier (NII) in the TPDU header identifies the switch endpoint. Correct NII configuration is required for multi-switch environments (e.g. domestic switch and Visa/Mastercard international switch on the same host).

Reading Visa VTC Simulator Output

The Visa Test Center (VTC) simulator logs each test case transaction with a structured output. Key fields to examine:

• MTI mismatch — if the simulator expected a 0200 but received a 0100, the acquirer’s host is classifying the transaction type incorrectly. Check DE03 (Processing Code) interpretation — ATM cash withdrawal should be 0200, not 0100.
• DE39 Response Code anomalies — unexpected response codes (e.g. 05 Do Not Honour for what should be an approval) indicate the acquirer host is declining simulator test cards. Verify the test BIN ranges are configured in the host’s routing table and approval overrides.
• MAC errors — Message Authentication Code validation failures in the VTC output indicate a key management problem. Check that the session keys are correctly derived from the master key, that the MAC algorithm (DES, 3DES, or AES) matches the scheme specification, and that the MAC data field boundaries are correctly implemented.
• DE55 (ICC Data) content errors — Visa VTC validates EMV tag content within DE55. Common failures: missing mandatory tags (9F26 Application Cryptogram, 9F36 ATC, 84 DF Name), incorrect tag order (tags must be BER-TLV compliant but scheme rules impose additional ordering requirements), or cryptogram type mismatch (TC sent when ARQC expected).

Reading Mastercard MIP Simulator Output

The Mastercard Interface Processor (MIP) simulator provides detailed field-level validation output for each test case:

• Field presence errors — MIP flags missing mandatory fields (e.g. DE61 absent on a contactless transaction). Cross-reference the MIP test case specification table for the exact required/optional/prohibited field set per transaction type and entry mode.
• DE22 POS Entry Mode errors — contactless transactions must carry POS entry mode 07x. If the terminal sends 05x (chip contact) for a tap transaction, MIP will fail the test case with an entry mode mismatch. Similarly, fallback to magnetic stripe from EMV must set the correct fallback indicator in DE22 digit 3.
• Reversal handling — MIP verifies that timeout reversals (0400) are sent correctly when a response is not received within the configured timeout window. Missing reversals, or reversals with incorrect DE90 (Original Data Elements) content, are common certification failures.
• DE48 additional data errors — Mastercard uses DE48 sub-fields extensively. Incorrect sub-field delimiters, missing sub-element tags (e.g. SE61 for wallet data), or incorrect sub-element lengths are flagged as DE48 format errors in MIP output.