So, what is ISO8583 anyway?

So, what is ISO8583 anyway?

You’ve heard of it! Your colleagues and customers talk about it all the time! You know it has something to do with ATM’s, payment switches and payments terminals, but what actually is ISO8583?

Well, in a nutshell – ISO8583 is a message specification which was developed originally for delivering data related to electronic transactions, which originated from payment card sources – i.e. transaction messages which originate when someone uses a magstripe or EMV card to perform some kind of electronic transaction, whether in an ATM or at a bank or in a store in front of a POS terminal.

In addition to specifying a message format, the specification also specifies a message flow, that is, the types and sequences of each type of message which is sent for each type of interaction.

There are actually many different message flows which can occur in ISO8583-based systems, as well as quite a few variations on the basic ISO8583 standard, but don’t worry – in this article, we will explain all the basics – and once you know these, adding the details of individual variations will be as easy as 1 – 2 – 3.

The basics – Message format

The basic message format for ISO messages is simple – each message consists of x3 main parts:

1. The message type indicator (MTI)
2. The primary, secondary and tertiary bitmaps
3. The message data elements (DE’s)

For instance, following the above, a basic ISO8583 message would look something like the following:

0800 2020000000800000 00000 000001 3239313130303031

In this example:

1. the message type (MTI) would be 0800 – therefore a network message,
2. the primary bitmap would be 20 20 00 00 00 00 00 00, and
3. the data elements (00000, 00001 and 3239313130303031)

As one can see, there are only a few data elements included in the message, and in fact, the presence of these elements, is indicated by the data included in the bitmap. More specifically, when converted into binary, 20 20 00 00 00 00 00 00 converts to 0010 0000 0010 0000 0000 0000 0000 0000 0000 0000 1000 0000 0000 0000 0000 0000 indicating the presence of data element 3 (DE3), data element 11 (DE11) and so on. In this case, the full bitmap indicates the presence of data elements 3, 11 and 41.

The message type indicator codes, for each of the major message types, is given in the table below, while the various data element field types (referred to in the bitmap) can be looked up from the given specifications for each ISO8583 variant (there are too many to list here!).

As indicated above, the primary bitmap indicates the presence of data elements DE3, DE11 and DE41. According to the 1987 IS08583 specification, these data elements correspond to the:

1. DE3 – Message processing code
2. DE11 – System trace or audit number, and
3. DE41 – Card acceptor identification number

The contents of each of these data elements are included sequentially after one another, following the bitmap data, so for the above example:

1. 00000 – Message processing code
2. 000001– System trace number
3. 3239313130303031 – Card acceptor identification number

Message flows

As shown above, the message type indicator (MTI) is comprised of 4 digits, of which only the 1st and 2nd are included in the table above. This is because, these numbers are sufficient to tell the reader what ISO8583 version (the 1st digit) is in use, and the general category of message being dealt with (the 2nd digit). Digits 3 and 4 were indicated with placeholders xx. These placeholder values are now discussed, since together with the general message category digit, help us to understand the general sequence of flows of messages within an ISO8583-based system.  More specifically, the 3rd and 4th digits are now explained as:

1.  3rd digit – the message function, and
2.  4th digit – the message origin

The tables below give the full set of options for both the message function and origin values.

From the tables above, it is clear that, from the Message Type Indicator data, a transaction participant may derive the version of the IS08583 message being used, the general category or class of the message, the intention (i.e. function) of the message, as well as the sender (or origin) of the message.

Using the above system, a typical message flow might include:

1. a 0100 transaction authorisation request message (such as an ID/V or pin check message) , from the terminal to start the transaction,
2. a 0110 transaction authorisation request response message, from the terminal’s acquirer backend, indicating success or failure of the ID/V,
3. a following 0200 transaction request message, from the terminal, including the transaction amount, and any other relevant transaction request data,
4. a corresponding 0210 transaction request response message, from the acquirer backend, again indicating the success of failure of the preceding request.

In the event that an error occurs during the final stages of the transaction (say, during the ATM dispense operation, assuming the message originator is an Automatic Teller Machine, and the ATM fails to dispense the authorised cash amount or there is a breakdown in communications between the terminal, switch and backend systems), a reversal advice message, to cancel and reverse the previously authorised transaction may be initiated, in the form of an 0420 message, from the transaction originator (i.e. the ATM) to the rest of the participants in the transaction.

Similarly, should one of the intended recipients of the reversal advice message, not acknowledge receipt of the 0420 message, the originator may continue to send additional reversal advice repeat messages (0421) until a response is received, in order to ensure transaction integrity.

As was the case in the original example, each of the messages above (0100, 0200, 0420 etc) would include a corresponding set of bitmaps as well as the specific data elements required for that particular message thereafter.

Conclusion

This has been a very brief overview of the ISO8583 message specification and flows – and while there is much more which can be learned, this is enough to get you started in reading and understanding the basics of ISO-based payment network systems.  We hope you enjoyed the ride!

Afferent Software is a well-established player in the global payments industry, with over 20 years of direct development and management experience in the sector. Afferent also produces the industry-leading suite of payments simulators – RapidFire – including both transaction generating (i.e. ATM and POS simulators) as well as backend simulators, capable of receiving and responding to ISO8583 transactions messages.

To learn more about our Team, and expertise, or to chat to someone who could help you with your payment related project, please check out our Services pages or contact us at info@afferentsoftware.com.