ISO 8583 is an international messaging standard for payments initiated with a financial transaction card (credit or debit card). Visa, Mastercard, and various other financial institutions and financial networks base their authorizations on the ISO 8583 standard.
ISO 8583 explained
The ISO 8583 protocol is used for systems that exchange electronic transactions initiated by cardholders using payment cards. Basically, when a cardholder uses a payment card, the electronic transaction data is exchanged throughout the network using ISO 8583 data elements, messages and code values.
The ISO 8583 standard is officially titled "Financial Transaction Card-Originated Messages — Interchange Message Specifications".
It's one of the many standards that denotes how to 'pack and unpack' certain data fields when processing certain financial transactions - in this case the processing of debit and credit cards.
ISO 8583 is a complete specification that enables card-originated financial transactions such as:
-
Purchases
-
Withdrawals
-
Deposits
-
Reversals
-
Refunds
-
Balance inquiry
-
Payments
-
Inter-account transfers
The ISO 8583 specification also defines point-to-point messages for secure key exchanges, totals reconciliation, network sign-on and network sign-off as well as other administrative messages.
The purpose of ISO 8583 is to allow different financial networks and systems to carry out those key exchange transactions and responses safely and securely.
ISO 8583 is used at some point through the communication process for most of the transactions that occur when a customer uses a debit or credit card to make a payment in a store (EFTPOS), or when they use an ATM.
How does ISO 8583 work?
The objective of this ISO protocol is to transmit information for payment processing via a network using TCP/IP sockets. An ISO 8583 message can have up to 63, or 127 fields, and is processed in a linear manner, in other words, it can be processed as it’s being read.
This is the way an ISO 8583 message is structured:
Header – This part is network specific, and shows Institution Identification Codes (IICs) The Institution Identification Code explains why Mastercard and Visa use different message header structure.
The header can be optionally zero padded. It typically shows the size of the message, (which is known in advance by the recipient), but it can also contain information about the size of header plus the size of message.
An example of a header is 0158 which depicts the content of the message (mti+bitmap+data elements) is 158 bytes
Message Type Indicator (MTI) – A message type indicator includes which version of ISO 8583 is being used, as well as the message class, the message function and the message origin. The MTI consists of four numerical parts that identify the specific version of the ISO8583.
Three versions of the standard exist in 1987, 1993, and 2003. The combination of the four MTI fields specifies the type of interchange message that is being transmitted.
Typically, applications use the Message Type Indicator to determine whether the message requires a response and the format of the response.
Digit 1 indicates the version of ISO 8583
Digit 2 indicates the class of the message
Digit 3 indicates the function of the message
Digit 4 indicates who initiated the communication
Image source: Payment systems
For instance, with a Message Type value of 0110, the following example lists what each position indicates:
-
0xxx → version of ISO 8583 (0 = 1987 version)
-
x1xx → class of the message (1 = authorization message)
-
xx1x → function of the message (1 = response)
-
xxx0 → who began the communication (0 = acquirer)
This means that MTI 0110 is an authorization response message stating that the actual financial transaction was originated by the acquirer.
Bitmaps - A bitmap is a field or sub-field contained in a message, which indicates whether there are other data elements or data element sub-fields somewhere else in the message.
Each message class can have one or more bitmaps, and each message always includes a primary bitmap which contains individual bits that indicate which of the fields are present in the specific message. The primary bitmap specifies whether fields 1 – 64 are present.
If there is also a secondary bitmap in the message, it indicates whether fields 65 – 128 exist.
Bitmap Example:
Data elements or fields – Message data elements are defined by the ISO 8583 protocol, and each individual data element contains the information for that specific transaction and each has a specified meaning.
The data elements and code values relating to the transaction, includes amounts, times, dates, and country codes. Organizations that use ISO 8583 may sometimes customize these fields.
There are also some general purpose data elements included in ISO 8583, as well as some system-specific data elements that are used in different ways by various standards that have derived from ISO 8583.
Example 1 : Bit value 2 is assigned to 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 is set out in a standard format which defines:
-
-
The permitted content of the field (for example, binary or numeric values ).
-
The field length (fixed or variable). If it's variable, the length of the field is preceded by a length indicator.
-
The message formats specified in the ISO 8583 protocol are designed to ensure that the systems conforming to this standard are always compatible.
Image source: Wikipedia
Binary data
In data structures, packed binary data usually signifies that there are more bit combinations used to encode the message. Unpacked signifies that some bit combinations remain unused. This is usually to make it more readable. To summarize, ISO 8583 defines two different encoding methods:
-
Packed - or 8 bytes of data
-
Unpacked - or 16 bytes as hexadecimal characters
The following is a table specifying the code values message format and service capture code for each transaction type.
Image source: Wikipedia
Service entry mode value
The Point Of Service (POS) entry mode value has 2 parts:
- PAN entry mode value - the first 2 digits
- PIN entry capability - the third digit
The following table shows PAN entry modes and their meanings.
Image source: Wikipedia
Credit Card Issuer Response Codes
An authorization request on a credit card can be denied for a variety of reasons, often with a different financial request issuer response on each occasion.
The process of passing network specific details throughout the transaction life-cycle is complicated, with many aspects to consider. From advice response messages to authorization advice confirmation, secure key exchange to country specific data elements and data element subfields, it's a lot for merchants and acquirers to take in.
An abbreviated section of the following table shows response codes and meanings:
Image source: TMC
How are messages processed ?
ISO 8583 financial messages consist of a request/response message which is sent between two parties to process the financial transaction. A TCP or other connection type such as:
- UDP
- X.25
- SDLC
- SNA
- ASYNC
- QTP
- SSL
- HTTP
- or another custom connection is opened between the two parties.
A handshake mechanism can also be initiated to prepare both parties for sending messages. Depending on the type of connection, it may kept open as a persistent connection type, or it may be closed, then reopened later for subsequent messages to be sent and received.
What’s the difference between ISO 8583 and ISO 20022?
The ISO 8583 protocol has long been used by the financial industry for card payments and is the legacy standard for every retail financial transaction.
The format has been used since the 1980’s to support card-based financial transactions and is the dominant messaging standard for acquirers, merchants, card issuers and financial institutions.
As we've already covered, ISO 8583 denotes message structure, format and content, as well as data and values of data elements. There are some key differences between this legacy format and the new ISO 20022 standard, which will likely supersede it.
Read our guide What is ISO 20022 and How is it Changing?
Format
ISO 8583 uses a bitmap format with each data element being assigned a specific position indicator in a control field. On the other hand, ISO 20022 uses Unified Modeling Language (UML) and extensible markup language (XML).
Usage today
Global financial organizations use ISO 20022 for high-value payments, with SWIFT making the migration to the standard over the next three years. Mastercard, Visa, and other payment networks use ISO 8583 as the basis for communication authorizations related to card-based payment messages.
Before ISO 20022
Prior to ISO 20022, corporate payments were carried out using SWIFT messaging formats - and retail payments used ISO 8583.
The two protocols had almost no commonality, so the introduction of ISO 20022 is a way to standardize a number of legacy message formats, bringing them into a common structure.
ISO 8583 is still very much in use and retains relevance as a format for a card-based financial transaction, however, with the rapidly evolving payments world of the future may see all use cases migrate to ISO 20022 as the standard messaging format.
Benefits of a common, integrated structure
The retail payments industry could stand to see some huge benefits to adopting a single common structure.
Due to multiple variations of the 8583 standard, it can cause a great deal of complexity, particularly with the certification process, and requires the need for human intervention, documenting and interpreting the standard.
With ISO 20022, transaction information is machine readable and will significantly streamline the payments messaging process.
The importance of real-time payments analytics
Worldpay's report on the art and science of global payments contains some revealing payment statistics and insights into world payment trends.
Various message systems exist to make payment procedures flow seamlessly, but the payment industry is complex and becoming more so with the evolution of cross-border payments and high value payments.
Real-time payments analytics are a vital part of any payment infrastructure, to measure, view growth and make decisions all the way through the payments chain, and across each different platform.
This is even more important now, with the impending global ISO 20022 migration.
Read our guide to secure cross-border payments
How IR can help
IR simplifies the complexity of managing modern communications, payments and infrastructure environments.
Our solutions help you find and resolve performance issues in real-time to ensure your business critical systems are working as they should and user experience throughout e very financial transaction is seamless.
Our payments solutions enable real-time insight into the health of your payments system, allowing transactions to get processed without issue. It enables organizations to:
- Leverage business data to gain visibility into critical accounts, such as settlement or high value customers.
- Easily monitor balance thresholds, flagged accounts, abnormal account usage patterns and project liquidity shortfalls.
- Monitor transaction queue health, volumes, and anomalies to get ahead of potential issues and ensure certain transactions are processed on time.
- View detailed, historical transaction information to investigate and identify the root cause of issues quickly.
Our payments solutions can help you streamline maintenance procedures within your payments system, and help to reduce financial liability.
