What Is the ISO 8583 Standard and Why Is It Important

ISO 8583 is a global standard for messaging in payment transactions involving financial cards, such as credit and debit cards. Major networks and institutions, including Visa and Mastercard, rely on the ISO 8583 standard, using proprietary variants and extensions to process and authorise these transactions.

In the following sections, we take a deep dive into the ISO 8583 standard, explaining what it is in detail, how it works, and why it matters.

What Is ISO 8583?

The ISO 8583 or the “Financial Transaction Card-Originated Messages – Interchange Message Specifications” is an international standard for financial transaction card-originated interchange messaging. 

It’s the International Organisation for Standardisation standard for systems that exchange electronic transactions initiated by those who use credit or debit cards to make payments. 

In other words, many payment card transactions use ISO 8583-defined data elements, message formats, and code values. Other standards such as ISO 20022-based formats are also used depending on the system and region.

It’s one of several standards that define how specific data fields should be “packed and unpacked” during the processing of card-based financial transactions. 

ISO 8583 enables card-originated transactions like:

• Withdrawals;
• Deposits;
• Reversals;
• Purchases;
• Refunds;
• Payments;
• Balance Inquiry;
• Inter-account transfers. 

It also outlines point-to-point messages used for secure key exchange transactions, transaction totals reconciliation, network sign-on and sign-off, along with various other administrative functions.

How the ISO 8583 Works

This protocol aims to send information for payment processing through a network. It defines the structure of payment messages, but it is transport-agnostic and can operate over various communication methods, such as TCP/IP, X.25, SNA, or another custom connection.

An ISO 8583 message can contain up to 128 fields in the original ISO 8583 standard, and up to 192 data elements in later releases. It’s handled in a linear fashion – meaning it can be processed as it’s being read.

In the following section, you can find the elements that make up the ISO 8583 message structure.

Header

In practical ISO 8583 implementations, the header is not defined by the ISO 8583 standard itself but is instead a transport- or scheme-specific wrapper added for routing or framing. 

This header is sometimes called a TPDU (in ISO 7816 / ISO 8583 over OSI-layer protocols) or a scheme header, and its structure varies between networks and card schemes.

The header may include optional zero padding. It usually indicates the message’s size, which the recipient already knows in advance, but it can also specify the combined length of both the header and the message.

Message Type Indicator (MTI) 

The Message Type Indicator includes which ISO 8583 version is being used, along with the message class, function, and message origin. 

It’s made up of four numeric components that together identify the exact ISO 8583 version:

• Digit 1 – the version of ISO 8583;
• Digit 2 – the class of the message;
• Digit 3 – the function of the message;
• Digit 4 – who initiated the message or location of source.

The standard has four editions – 1987, 1993, 2003, and the most recent one – 2023. By combining the four MTI digits, you can determine the exact type of interchange message being sent.

In practice, systems rely on the MTI to decide whether a response is required and what format that response should follow.

For example, a Message Type value of 0110 indicates the following:

• 0xxx – ISO 8583 version (0 = 1987 version)
• x1xx – message class (1 = authorisation message)
• xx1x – message function (1 = response)
• xxx0 – location of source (0 = acquirer)

This indicates that MTI 0110 represents an authorisation response message, confirming that the financial transaction itself was initiated by the acquirer.

Other examples include 0100 (Authorisation Request), 0110 (Authorisation Response), 0120 (Authorisation Advice), and more.

Bitmaps

A bitmap is a field or subfield within a message that signals the presence of other data elements or data element subfields elsewhere in that message. 

It’s used to minimise message size by excluding unnecessary data fields. A field is considered to be present only in the case that the corresponding bit in the bitmap is set. It can be represented as 8 bytes of binary data or as 16 hexadecimal characters in the ASCII or EBCDIC character sets. 

Each message class may contain one or more bitmaps, but every message includes at least a primary bitmap. This primary bitmap uses individual bits to show which fields are included, specifically covering fields 1 through 64.

If a secondary bitmap is present, it further indicates whether fields 65 through 128 are part of the message.

Data elements 

Message data elements are defined within the ISO 8583 standard, and each one represents specific transaction information, with its own clearly defined purpose and specified meaning. At the same time, the standard also includes general-purpose elements and system – or country-specific data elements. 

These elements include transaction details such as amounts, timestamps, dates, and country codes. Organisations implementing ISO 8583 may also tailor certain fields to meet their own requirements.

The standard also provides general-purpose data elements, along with system-specific ones that different implementations, built on top of ISO 8583, use in various ways.

Here are two examples:

• Example 1 –  Bit value 2 is assigned to the primary account number, Bit 3 is assigned to processing code, Bit 4 is for transaction amount, etc.

• Example 2 – x + n Numeric (amount) values, where the first byte is either ‘C’ to indicate a positive or credit value, or ‘D’ to indicate a negative or Debit value, followed by the numeric value (using n digits)

Each data element follows a standardised format that specifies the type of content the field may contain (numeric value or binary data) and the field’s length, which can be fixed or variable. 

Binary data

Earlier, we mentioned that data structures can be packed or unpacked.

Packed binary data indicates that the message uses the maximum number of bit combinations to encode information. Unpacked data, on the other hand, leaves some bit combinations unused, often to improve readability. 

In ISO 8583, the bitmap specifically may be encoded in either packed form (8 bytes of data) or unpacked (16 bytes represented as hexadecimal characters).

Service Entry Mode Value

The Point Of Service entry mode value includes two parts:

• Primary Account Number or PAN entry mode value – the first two digits;
• PIN entry capability – the third digit. 

The following table demonstrates PAN entry modes and their meanings in the original 1987 version of ISO 8583:

PAN Entry Mode	Meaning
00	Unknown
01	Manual
02	Magnetic Stripe
03	Bar Code
04	OCR
05	Integrated circuit card (ICC). CVV can be checked.
07	Auto entry via contactless EMV.
10	Merchant has Cardholder Credentials on File.
80	Fallback from integrated circuit card (ICC) to magnetic stripe.
90	Magnetic stripe as read from track 2. CVV can be checked.
91	Auto entry via contactless magnetic stripe.
95	Integrated circuit card (ICC). CVV may not be checked.
99	Same as the original transaction.

Source: Wikipedia

Credit Card Issuer Response Codes

A credit card authorisation request can be declined for numerous reasons, and the financial request issuer response may vary each time.

The flow of network-specific information throughout a transaction’s lifecycle is complex, involving many components. From advice response messages and authorisation advice confirmations to secure key exchanges and country-specific data elements and subfields, there’s a lot for merchants and acquirers to manage.

A condensed portion of this table shows response codes and their meanings for ISO 8583-1987:

Code	Response Reason	Code	Response Reason
00	Approved	54	Expired Card
01	Refer to Card Issuer	55	Incorrect PIN
02	Refer to Issuer’s special conditions	56	No Card Record
03	Invalid Merchant	57	Trans, not Permitted to Cardholder
04	Pick Up Card	58	Transaction not Permitted to Terminal
05	Do Not Honor	59	Suspected Fraud
06	Error	60	Card Acceptor Contact Acquirer
07	Pick Up Card, Special Conditions	61	Exceeds Withdrawal Amount Limits
08	Honor with identification	62	Restricted Card
09	Request in Progress	63	Security Violation
10	Partial Amount Approved	64	Original Amount Incorrect
11	VIP Approval	65	Exceeds Withdrawal Frequency Limit
12	Invalid Transaction	66	Card Acceptor Call Acquirer Security
13	Invalid Amount	67	Hard Capture – Pick Up Card at ATM
14	Invalid Card Number	68	Response Received Too Late
15	No Such Issuer	75	Allowable PIN Tries Exceeded
16	Approved, update track 3	76	Previous message not found
17	Customer Cancellation	77	Data does not match original message
18	Customer Dispute	80	Invalid Date
19	Re-enter Transaction	81	Cryptographic failure
20	Invalid Response	82	Incorrect CVV
21	No Action Taken (no match)	83	Unable to verify PIN
22	Suspected Malfunction	84	Invalid authorization life cycle
23	Unacceptable Transaction Fee	85	No reason to decline

Keep in mind that these are valid for the original ISO 8583-1987, as later versions use three- and four-digit response codes.

Key Features of ISO 8583

Ideally, merchants should search for financial processing systems that are compliant with ISO 8583. This is because the core features of this protocol enable it to minimise false declines, unhappy clients, and lost revenue.

These features include:

• Standardised Format – the protocol ensures consistent message formats across different payment networks and systems, facilitating interoperability.
  
• Flexibility With Data Elements – ISO 8583 allows customisation for country-specific or institution-specific requirements. For example, data elements can include local currency codes or regional identifiers.
  
• Security and Reliability – supports secure key exchanges and encrypted data for safe transaction processing. 

These features are also the reason behind the importance of ISO 8583.

The Importance of ISO 8583

As noted, this standard enables seamless communication between banks, card issuers, and payment processors across borders. For example, a customer using a credit card abroad can complete transactions without compatibility issues.

In addition, it supports the exchange of transaction data for ATMs, POS terminals, card machines, and online payments. The protocol also reduces errors by providing a clear structure for message formats and data interpretation. For instance, using specific codes for transaction types means more precise processing. 

Not to mention the improvements made in payment security. ISO 8583 defines secure mechanisms for transmitting sensitive data like card details and transaction amounts.

In some cases, this helps prevent unauthorised access during payment processing.

ISO 8583 vs. ISO 20022

The differences between ISO 8583 and ISO 20022 can be observed from the perspective of format and usage. 

While ISO 8583 uses a bitmap format where each data element is assigned a specific position indicator in a control field, ISO 20022 uses Unified Modelling Language and Extensible Markup Language. 

International financial institutions use ISO 20022 for high-value payments, while Mastercard, Visa, and other payment networks continue to use ISO 8583 as the foundation for handling card-based payment message authorisations.

Challenges with ISO 8583

Despite the benefits provided by ISO 8583, it can also go hand in hand with a few challenges.

For example, integrating ISO 8583 standards into existing banking systems can be difficult, requiring an in-depth understanding and the ability to configure systems for MTIs, bitmaps, and data elements. 

The implementation process can further be complicated by variations in data element requirements across regions. Moreover, integrating this protocol with newer protocols like ISO 20022 demands extra effort and resources. 

Not to mention that staying compliant with ISO 8583 while trying to maintain high levels of security can also be challenging. 

Is ISO 8583 Relevant Today?

While there are newer standards, like mentioned above, ISO 8583 remains relevant today. 

It’s ideal for card payment systems, like ATMs, POS terminals, and payment gateways. It’s also suitable for cross-border payments, ensuring compatibility across international systems. 

Also, financial institutions and other established networks can benefit from it. 

Conclusion

In a nutshell, ISO 8583 is a foundational standard for secure, efficient, and standardised card payment processing globally. Its structured approach to financial messaging ensures compatibility and reliability across diverse payment networks. 

While newer standards like ISO 20022 are gaining traction, ISO 8583 remains indispensable for card-based transactions, reinforcing its ongoing relevance in the financial industry.

Frequently Asked Questions

What types of transactions use ISO 8583?

ISO 8583 is primarily used for card-based transactions, including purchases, cash withdrawals, balance inquiries, and refunds.

Who uses ISO 8583?

ISO 8583 is widely used by banks, payment networks like Visa and Mastercard, and financial institutions that process electronic card transactions.

Why is ISO 8583 important?

ISO 8583 ensures interoperability between financial systems, allowing secure, reliable, and standardised processing of card-based transactions across different banks and networks.