Understanding ISO 8583 Message Structure

If you work in payment processing, you’ve likely encountered ISO 8583 — the international standard for financial transaction messaging. This guide breaks down the core components of an ISO 8583 message and explains how each piece fits together.

What is ISO 8583?

ISO 8583 is a messaging standard used across the global payment industry. It defines the format for messages exchanged during card-based financial transactions, including:

• Authorization requests and responses
• Financial transactions (purchases, refunds)
• Reversals and chargebacks
• Network management messages

Every time you swipe, tap, or insert a card, an ISO 8583 message travels from the terminal to the acquirer, through the card network, and to the issuing bank.

The Three Components

Every ISO 8583 message consists of three parts:

1. Message Type Indicator (MTI) - 4 digits identifying the message type
2. Bitmap - Indicates which data elements are present
3. Data Elements - The actual transaction data

Let’s examine each component in detail.

Message Type Indicator (MTI)

The MTI is a 4-digit code that tells you exactly what kind of message you’re dealing with.

Common MTI Values

0100 - Authorization Request
0110 - Authorization Response
0200 - Financial Request (Capture)
0210 - Financial Response
0400 - Reversal Request
0410 - Reversal Response
0800 - Network Management Request
0810 - Network Management Response

Tip: Use our ISO 8583 Studio to decode MTI values from raw messages.

Bitmaps: The Message Map

The bitmap is the clever part of ISO 8583. Instead of sending every possible field, the bitmap indicates which data elements are actually present in the message.

Primary vs Secondary Bitmap

• Primary Bitmap (64 bits) - Always present, covers fields 1-64
• Secondary Bitmap (64 bits) - Optional, covers fields 65-128

If bit 1 of the primary bitmap is set to 1, a secondary bitmap follows.

Reading a Bitmap

Consider this hex bitmap:

7234054128C28805

Converting to binary:

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

Each 1 indicates a present field. Reading left to right:

• Bit 2 = Primary Account Number (PAN)
• Bit 3 = Processing Code
• Bit 4 = Transaction Amount
• …and so on

Try it yourself: Paste a bitmap into our Validators & Calculators tool to see which fields are present.

Data Elements

After the bitmap come the actual data elements. ISO 8583 defines 128 possible fields, though most messages use only a subset.

Key Data Elements

Variable Length Fields

Some fields have variable lengths. These use LLVAR or LLLVAR encoding:

• LLVAR: 2-digit length prefix (max 99 bytes)
• LLLVAR: 3-digit length prefix (max 999 bytes)

For example, Field 2 (PAN) might look like:

1649XXXXXXXX1234

Where 16 indicates the PAN is 16 digits long.

Real-World Example

Here’s a complete authorization request:

0100723405412880880016491234567890123456000000000100000012345678123456001234567890123456...

Breaking it down:

• 0100 - MTI (Authorization Request)
• 7234054128808800 - Primary Bitmap
• 164912345678901234 - Field 2: PAN (16 digits)
• 000000 - Field 3: Processing Code (Purchase)
• 000001000000 - Field 4: Amount ($10.00)
• …

Want to parse this yourself? Use our ISO 8583 Studio.

Field 55: The EMV Connection

Field 55 contains EMV chip data encoded in BER-TLV format. This is where you’ll find:

• Tag 9F26: Application Cryptogram (ARQC/TC/AAC)
• Tag 9F27: Cryptogram Information Data
• Tag 9F10: Issuer Application Data
• Tag 9F33: Terminal Capabilities

For a deep dive into TLV parsing, see our EMV Tag Reference or decode your data using the EMV Tag Inspector.

Next Steps

• Discover the engineering behind routing these messages in our Payment Orchestration Architecture guide.

This post is part of the ISO 8583 Mastery series. Follow along as we explore payment messaging in depth.