When you tap your card, a conversation begins. It’s not a conversation of words, but of data, and it happens almost instantly. This dialogue follows a strict set of rules, a universal grammar for financial transactions known as ISO 8583 The International Organization for Standardization’s standard 8583 defines the message format that devices like point-of-sale terminals and ATMs use to communicate with card issuers.

Think of it as a highly structured digital envelope. Every message contains three core parts: a Message Type Indicator, one or more Bitmaps, and the Data Elements themselves.

The first part of any message is the Message Type Indicator (MTI). This is a four-digit code that immediately tells the receiving system the message's purpose. It answers the question: What is this communication trying to do? The MTI defines the message's version, class, function, and origin.

For example, an MTI of 0100 signifies an authorization request from the merchant's side (the acquirer). The response from the cardholder's bank (the issuer) would come back with an MTI of 0110. This simple code sets the context for everything that follows.

After the MTI comes the bitmap, which is the message's table of contents. ISO 8583 defines up to 128 possible fields for data, from the card number to the merchant's name. But not every message needs every field. Sending a lot of empty data would be incredibly inefficient.

The bitmap solves this. It's a string of 64 bits (8 bytes). If a bit is set to 1, it means the corresponding data element is present in the message. If it's 0, that element is absent. For instance, if the 2nd and 4th bits of the bitmap are 1, the system knows that Data Element 2 (the PAN) and Data Element 4 (the amount) are included in this message.

What about the other 64 fields? The very first bit of this primary bitmap has a special job. If it is set to 1, it signals that a second bitmap is present, which maps the next set of data elements from 65 to 128. This allows the standard to be flexible enough for complex messages without bloating the simpler, more common ones.

Following the bitmap(s) are the data elements (DEs) themselves, packed in sequential order. These are the payload of the message. Some of the most fundamental DEs include:

• DE 2: Primary Account Number (PAN): The long number on the front of the card.
• DE 3: Processing Code: A code indicating the type of transaction (e.g., purchase, cash advance).
• DE 4: Amount, Transaction: The cost of the purchase.
• DE 7: Transmission Date & Time: When the transaction was initiated (in UTC).
• DE 41: Card Acceptor Terminal ID: A unique code for the specific POS terminal.

Finally, how do these messages travel across the world? They are typically sent over dedicated, long-lived TCP/IP sockets. Unlike a web browser that opens and closes connections for each request, payment systems maintain a persistent connection between the acquirer and the payment network. This minimizes the overhead of establishing a new secure link for every single transaction, ensuring speed and reliability.

This combination of a structured message format, efficient data mapping, and a persistent communication channel is the technical foundation that makes global card payments possible.