Introduction

Whenever we use credit/debit/ATM card, the data traverse from one system to another. A card-based transaction typically needs to travel between a numbers of systems. For example, a purchase made in a store may travel from the merchant terminal, through an acquirer network or networks, to the issuing bank where the cardholder's account is held. The transaction carries information about the type of transaction, the card used, the merchant, the transaction amount, security information, and so on. The response, authorizing or declining the transaction, needs to be returned via the same route to the terminal.

The data interchange that takes place between different systems needs to follow standard formats for integration, exchange and interoperability. There are many such standards existing. In Healthcare industry HL7, DICOM (Digital Imaging and Communications in Medicine) are the protocols implemented by the system, similarly in financial world there are the standards (protocols) ISO8583, ISO7816 etc, for the various kind of data interchange. ISO (International Organization for Standardization) is a worldwide federation of national standards bodies. ISO 8593 is Financial Transaction card originated, Interchange message specifications adopted by wide segment of Payment Industry (including Acquirers and Issuers). Standard can be further extended to support the transactions taking place between POS (Point of Sale Terminals) and Merchant Acquirer. ISO 8583 specifies message structure, format and content, data element and values of data elements. Application specification may remain at private level (implementer) and the method (message) by which settlement takes place is not within the scope of ISO.

Cardholder-originated transactions include purchase, withdrawal, deposit, refund, reversal, balance inquiry, payments and inter-account transfers. ISO 8583 also defines system-to-system messages for secure key exchanges, reconciliation of totals, and other administrative purposes.

In particular, both Master Card and Visa networks base their transactions on the ISO 8583 standard, as well other institutions and networks.

ISO 8583 Message Structure

The ISO message consists of three major parts; the header, application data, and the trailer. The header and trailer envelop the application data and are used for routing and message integrity. The application data consist of ISO message including Message Type Indicator (MTI), BIT MAP (indicating which data elements are present) and ISO Data Element (the fields of the message).

Application Data

Field #	Description
0	MTI Message Type Indicator
1 - Bitmap	64 (or 128) bits indicating presence/absence of other fields
2 - 128	Other fields as specified in bitmap

Overall we can visualize the transmission of data trough a pipe in below given order:

Now we can jump into details of the different components of the application data.

Message Type Indicator (MTI)

This is a 4 digit numeric field, which classifies the high level function of the message. A Message Type Indicator includes the ISO 8583 version, the Message Class, Message Sub-class, and Transaction Originator. Different versions of the ISO 8583 standard are indicated in the first position of the Message Type Indicator.

0xxx	ISO 8583:1987 version
1xxx	ISO 8583:1993 version
2xxx	Reserved for ISO use
3xxx	Reserved for ISO use
4xxx	Reserved for ISO use
5xxx	Reserved for ISO use
6xxx	Reserved for ISO use
7xxx	Reserved for ISO use
8xxx	Reserved for national use
9xxx	Reserved for private use

Message Class

Message Class	Description
x1xx	Authorization Message
x2xx	Financial Message
x3xx	File Actions Message
x4xx	Reversal & Chargeback Message
x5xx	Reconciliation Message
x6xx	Administrative Message
x7xx	Fee Collection Message
x8xx	Network Management Message
x9xx	Reserved for ISO use

Message Sub-class

Message Sub-Class	Description
xx00	For a request, requiring approval
xx10	For a response to a request
xx20	For an advice of an action that has already been taken, not requiring approval but still requiring a response
xx30	For a response to an advice
xx40	For notification
xx50 – xx90	Reserved for ISO use

Incrementing the fourth position by one indicates a repeat request (except in x300 messages). For example: 1100 = Authorization Request; 1101 Authorization Request Repeat.

Transaction Originator

Transaction Originator	Description
0	Acquirer
1	Acquirer repeat
2	Card issuer
3	Card issuer repeat
4	Other
5	Other repeat
6 - 9	Reserved for ISO use

So by knowing the MTI value we can identify the type of message. For Example: If MTI value is 1200, then from the table above we can find other details. First position is for Version Number and value in MTI is 1, so message version is based on ISO 8583:1993. Second Position is for Message Class and value in MTI is 2, so message is a financial message. Third position is for message sub-class/function and the value in MTI is 0, so the given message is a request message. Fourth position is for Transaction Originator and value in MTI is 0, so the message is coming from Acquirer. When we consolidate all these we do find that message with MTI value 1200 is an ISO 1993 Financial Request Message sent by Acquirer.

So if we summarize, then Message Class/Type is (a n4 - 4 Digits Numeric Value) required for all ISO 8583 messages in order to identify the message class and the Message Type can be one of the following values (this is a partial list):

MTI	Description
x100	Authorization Request
x101	Authorization Request Repeat
x102	Authorization completion confirmation
x103	Authorization completion confirmation repeat
x110	Authorization Response
x112	Authorization completion response
x120	Authorization Advice
x121	Authorization advice repeat
x122	Authorization advice completion confirmation
x123	Authorization advice completion confirmation Report
x130	Authorization Advice Response
x132	Authorization advice completion response
x200	Financial Request
x210	Financial Response
x220	Financial Advice
x230	Financial Advice Response
x300	Acquirer File Update Request
x302	Issuer File Update Request
x310	Acquirer File Update Response
x312	Issuer File Update Response
x320	Acquirer File Update Advice
x322	Issuer File Update Advice
x330	Acquirer File Update Advice Response
x332	Issuer File Update Advice Response
x400	Acquirer Reversal Request
x402	Issuer Reversal Request
x410	Acquirer Reversal Request Response
x412	Issuer Reversal Request Response
x420	Acquirer Reversal Advice
x422	Issuer Reversal Advice
x430	Acquirer Reversal Advice Response
x432	Issuer Reversal Advice Response
x5xx	Reconciliation Request Messages
x6xx	Administrative Request Messages
x800	Network Management Request
x810	Network Management Request Response

Bitmap(s)

A bitmap is an indexing technique used in an ISO 8583 message to indicate which Data Elements are present. The presence of a data element in a specific message is indicated by a one (1) in the assigned position; a zero (0) indicates the absence of a data element in the assigned position. Each application transaction includes one (1) bit map. A bit map consists of 64 bits numbered from the left starting with bit 1. The first bit of the bit map represents a secondary bit map. If any ISO message does not support secondary bit map processing, then the first bit of the bit map is '0'.

Bit 1	Bit 2	Bit 3	Bit 4	…	Bit 64
Field 1 Secondary bit map. ‘1’ if present else ‘0’	Field 2 Primary Account Number	Field 3 Processing Code	Field 4 Amount, Trans		Field 64 Message Auth Code

A message contains at least one bitmap called the Primary Bitmap, indicating the presence of Data Elements 1 up to 64.

A Secondary Bitmap may be located at Data Element one, and hence the first bit in Primary Bitmap tells us whether there is a secondary bitmap or not. The secondary bitmap indicates the presence of Data Elements 65 up to 128.

A message can contain up to three bitmaps in the latest version of the ISO 8583 standard. The bitmap may be transmitted as 8 bytes (binary), or sometimes with the 8 bytes unpacked into 16 hexadecimal characters 1-9, A-F (ASCII).

 

Data Elements

Data Elements are fields carrying the information of the transaction itself. There are up to 128 Data Elements in the original ISO 8583 (1987) standard, and up to 192 Data Elements in later releases. Each Data Element has a specified meaning and format. ISO 8583 also includes some general purpose Data Elements and system-specific Data Elements that are used in different ways by different standards derived from ISO 8583.

For example: Bit value 2 is assigned to Primary Account Number, 3 is assigned to Processing Code, 4 is for Transaction Amount similarly, and so on. And bit value 128 is for Message Authentication Code Field. For each data element ISO specifies the data format and size. ISO also specifies which all data elements are mandatory or optional for a particular message.

 

Data Element Format

ISO-8583 specifies different kind of fields that basically fall in following categories:

• Fixed length

• Numeric

• Alphanumeric

• Binary

• Variable length

• Max-length 99

• Numeric

• Alphanumeric

• Binary

• Max-length 999

• Numeric

• Alphanumeric

• Binary

• Nested message

 

Each Data Element has a standard format. This consists of the allowed content of the field (numeric, binary, etc) as well as the allowed length. This is indicated by the convention of allowed content followed by length as described in the following sections.

 

Field Type Attributes

Abbreviation	Meaning
a	Alphabetic, including Blanks
n	Numeric Values only
s	Special Characters only
an	Alphanumeric
as	Alphabetic & Special Characters only
ns	Numeric and Special Characters only
ans	Alphabetic, numeric & Special Characters
b	Binary Data
z	Tracks 2 & 3 code set as defined in ISO 7811 & ISO 7813
h	Hex Data
LL, LLL	Length of variable field that follows. ‘LL’ - Two-digit length indicator (1 byte BCD) ‘LLL - 3-digit length indicator (2 bytes BCD)
..17 ..125	Variable field of up to 17. The ‘..’ is a two-digit length indicator (1 byte BCD) specifying the number of digits defining the length of the variable data to follow. Variable field of up to 125 characters. The ‘…’ is a three-digit length indicator (2 bytes BCD), specifying the number of digits defining the length of the variable data to follow.

A Data Element may have a fixed or variable length. A length indicator precedes a variable length field in a message.

Fixed Length Data Element

Fixed-length Data Elements have a defined length in the ISO 8583 standard, and no length indicator is required in the message. These are indicated by including the length after the allowed content e.g. Data Element 3 has format 'n6', which means a fixed-length field of 6 numeric digits.

Variable Length Data Element

Other data elements may have variable length, and a length indicator is included before the data element in the message. The length indicator itself has a defined length: for example, a 1-digit length indicator is only sufficient for a variable-length field with a length from 1 up to 9, while a 3-digit length indicator can support field values up to 999.

Variable length fields are indicated by two dots '..' followed by the maximum length of the field. The length indicator is represented by a number of 'L' characters corresponding to the length of the length indicator e.g. Data Element 2 has format n..19, LLVAR which means a field with a maximum of 19 numeric digits with a 2-digit length indicator.

The problem is not complexity but diversity, ISO-8583 is not specific about how a given field is represented, so you can have a numeric field represented as a sequence of ASCII characters, EBCDIC characters, BCD, etc.

Variable length fields have a prefix specifying its length, but how this is represented is not defined, different vendors uses different representations (i.e. BCD, EBCDIC, binary value).

 

Sample Messages

[Refer Appendix A for number system basics]

Sample 1: 0800 Message

#	Name	Value	Hex Value
0	MTI	0800	08 00
1	PRIMARY BITMAP	Indicates presence of fields 3, 11 and 41	20 20 00 00 00 80 00 00
3	PROCESSING CODE	000000	00 00 00
11	SYSTEM TRACE AUDIT NUMBER	000001	00 00 01
41	CARD ACCEPTOR TERMINAL IDENTIFICATION	29110001	32 39 31 31 30 30 30 31

 

Here is the binary representation of our 0800 message:

080020200000008000000000000000013239313130303031

 

In above example, 0800 is the message type indicator; first position represents version number:

       • 0 is for version 1987

Second position is message class:

       • 8 is for network management

Third position is message sub-class/function:

       • 0 is for request

And last position is used to describe transaction originator:

       • 0 is for acquirer

 

So "0800" is a version 1987 network management request.

 

Next we have field 1, primary bitmap:

 

Primary Bitmap

Byte	Hex Value	Bit Value	Field #
0	20	0010 0000	3
1	20	0010 0000	11
2	00	0000 0000
3	00	0000 0000
4	00	0000 0000
5	80	1000 0000	41
6	00	0000 0000
7	00	0000 0000

So we've parsed MTI, (0800) bitmap (2020000000800000), we know fields 3, 11 and 41 are present, so our next field is number 3.

In our example, field #3 is using a BCD representation, so a value of "000000" is represented with just three bytes whose values are "00 00 00". Same goes for field #11 whose value is "000001", it's represented as "00 00 01". In our example, field #41 is an 8-byte alphanumeric field represented as 8 ASCII characters

Message: 08002020 00000080 00000000 00000001

                32393131 30303031

 

MTI: 0800

Bitmap: 20200000 00800000

Field 03: 000000

Field 11: 000001

Field 41: 3239313130303031 (ASCII for "29110001")

 

Sample 2: Another 0800 message

#	Name	Value	Hex Value
0	MTI	0800	08 00
1.a	PRIMARY BITMAP	Indicates presence of secondary bitmap plus fields 3, 11 and 41	A0 20 00 00 00 80 00 10
1.b	SECONDARY BITMAP	Indicates presence of field 70	04 00 00 00 00 00 00 00
3	PROCESSING CODE	000000	00 00 00
11	SYSTEM TRACE AUDIT NUMBER	000001	00 00 01
41	CARD ACCEPTOR TERMINAL IDENTIFICATION	29110001	32 39 31 31 30 30 30 31
60	RESERVED FOR PRIVATE USE	TEST MESSG	00 10 54 45 53 54 20 4D 45 53 53 47
70	NETWORK MANAGEMENT INFORMATION CODE	301	03 01

 

In above sample, two new fields#60 and #70 are present. Here is our message representation:

Message: 0800A020 00000080 00100400 00000000

                00000000 00000001 32393131 30303031

                00105445 5354204D 45535347 0301

 

MTI: 0800

Primary bitmap: A0200000 00800010

Secondary bitmap: 04000000 00000000

Field 03: 000000

Field 11: 000001

Field 41: 3239313130303031 (ASCII for "29110001")

Field 60: 0010 54455354204D45535347 (length=10, value="TEST MESSG")

Field 70: 0301

 

Let's break down this bitmap:

Primary Bitmap

Byte	Hex Value	Bit Value	Field #
0	A0	1010 0000	Secondary bitmap present plus #3
1	20	0010 0000	11
2	00	0000 0000
3	00	0000 0000
4	00	0000 0000
5	80	1000 0000	41
6	00	0000 0000
7	10	0001 0000	60

 

Secondary Bitmap

Byte	Hex Value	Bit Value	Field #
0	04	0000 0100	70
1	00	0000 0000
2	00	0000 0000
3	00	0000 0000
4	00	0000 0000
5	80	0000 0000
6	00	0000 0000
7	00	0000 0000

To make things complex to developers, different vendors choose different padding styles when handling odd length BCD fields. So in order to represent "003" one vender may use two bytes with the values "00 03" while another may use "00 30".

Same goes for variable length fields, field length as well as field values can be padded right or left, that's not defined by ISO-8583, it's just a matter of fact of different implementations.

Then we have nested fields, some implementations use reserved for private use fields to carry other ISO-8583 messages. These messages are usually packed as variable length binary fields as seen by outer message.

Real Life Samples

A real example may help us to understand what kind of information is exchanged during an authorization request, and response:

Sample Authorization Request

Field #	Description	Value	Comments
0	MTI	0100	Authorization request
2	Primary Account Number	4321123443211234
3	Processing Code	000000
4	Transaction Amount	000000012300	i.e. 123.00
7	Transmission data/time	0304054133	MMYYHHMMSS
11	System trace audit number	001205
14	Expiration date	0205	YYMM
18	Merchant Type	5399
22	POS Entry Mode	022	Swiped Card
25	POS Condition Code	00
35	4321123443211234=02051	2312312332	Track 2
37	Retrieval Reference Number	206305000014
41	Terminal ID	29110001
42	Merchant ID	1001001
49	Currency	840	American Dollars

 

Sample Authorization Response

Field #	Description	Value	Comments
0	MTI	0110	Authorization response
2	Primary Account Number	4321123443211234
3	Processing Code	000000
4	Transaction Amount	000000012300	i.e. 123.00
7	Transmission data/time	0304054133	MMYYHHMMSS
11	System trace audit number	001205
14	Expiration date	0205	YYMM
18	Merchant Type	5399
22	POS Entry Mode	022	Swiped Card
25	POS Condition Code	00
35	4321123443211234=02051	2312312332	Track 2
37	Retrieval Reference Number	206305000014
38	Authorization number	010305
38	Response code	00	Approved
41	Terminal ID	29110001
42	Merchant ID	1001001
49	Currency	840	American Dollars

 

Transmission protocol

Once we have a binary representation of a given ISO-8583 message we have to transmit it over the wire using some communication protocol (i.e. TCP/IP, UDP/IP, X.25, SDLC, SNA, ASYNC, QTP, SSL, etc.).

ISO-8583 does not define any communication protocol; so different vendors have chosen different protocols. Many implementations (specially old ones) require support for some kind of routing information (i.e. a CICS transaction name), so they use different sorts of headers. A few of them (specially stream based ones) require some kind of trailers as well.

Transmission protocol is composed of an

• Optional header

• ISO-8583 message data

• Optional trailers

 

A TCP/IP based implementations may use a couple of bytes to indicate message length, so our 0800 example described earlier would be sent as:

00 46 08 00 A0 20 00 00 00 80 00 10 04 00 00 00

00 00 00 00 00 00 00 00 00 01 32 39 31 31 30 30

30 31 00 10 54 45 53 54 20 4D 45 53 53 47 03 01

 

0046 is the message length expressed in network byte order.

But this is just one way of specifying message length, other implementation may choose to send four ASCII bytes, i.e.

30 30 34 36 08 00 A0 20 00 00 00 80 00 10 04 00

00 00 00 00 00 00 00 00 00 00 00 01 32 39 31 31

30 30 30 31 00 10 54 45 53 54 20 4D 45 53 53 47

03 01

 

30303436 being the ASCII representation of "0046".

A few of them perform odd things with those headers, flagging rejected messages (i.e. you send a 0100 and instead of receiving a 0110 with a suitable response code you get back your own 0100 with some proprietary flag in the header indicating for example a temporarily failure such as destination unreachable).

Conclusion

There are many different implementations of ISO8583, and many local variations. Although ISO 8583 defines a common standard, it is not typically used directly by systems or networks. Instead, there are a number of different standards in use on different transaction networks, all based on ISO 8583 but with proprietary variations.

 

Appendix A

Number System

The base value of a number system is the number of different values the set has before repeating itself. For example, decimal has a base of ten values, 0 to 9. Different number system and its base value are as below:

• Binary = 2 (0, 1)
• Octal = 8 (0 - 7)
• Decimal = 10 (0 - 9)
• Duodecimal = 12 (used for some purposes by the Romans)
• Hexadecimal = 16 (0 - 9, A-F)
• Vigesimal = 20 (used by the Mayans)
• Sexagesimal = 60 (used by the Babylonians)

Binary Number System is commonly used in computers. For detailed discussion, please refer to any elementary computing science book.

Nibble

A nibble is group of four bits, or half an octet (an octet being an 8-bit byte). As a nibble contains four bits, there are sixteen (2⁴) possible values, so a nibble corresponds to a single hexadecimal digit (thus, it is often referred to as a "hex digit" or "hexit"). A full byte is represented by two hexadecimal digits. Therefore, it is common to display a byte of information as two nibbles. A set of three nibbles can be referred as a tribble. The nibble is often called a semioctet in a networking or telecommunication context.

BCD

Binary code decimal digits (0-9) are represented using FOUR bits. The valid combinations of bits and their respective values are

Binary Value	Digit
0000	0
0001	1
0010	2
0011	3
0100	4
0101	5
0110	6
0111	7
1000	8
1001	9

The binary combinations 1010 to 1111 are invalid and are not used.

If the computer stores one BCD digit per byte, then it is called normal BCD. The unused nibble may be either all 0's or all 1's.

If two BCD digits are stored per byte, it is called Packed BCD. This occurs in data transmission where numbers are being transmitted over a communications link. Packed BCD reduces the amount of time spent transmitting the numbers, as each data byte transmitted results in the sending of two BCD digits.

Consider the storing of the digits 56 in Packed BCD format.

7	6	5	4	3	2	1	0	< Bit Number
0	1	0	1	0	1	1	0
MSB							LSB

The UPPER nibble holds the value 5, whilst the LOWER nibble holds the value 6. So the BCD equivalent of (56) ₁₀ is (0101 0110) _BCD.

 

EBCDIC

EBCDIC (Extended Binary Coded Decimal Interchange Code) is an 8-bit character encoding. EBCDIC was developed separately from ASCII. EBCDIC is an 8-bit encoding, versus the 7-bit encoding of ASCII. A single EBCDIC byte occupies eight bits, which are divided in two halves or nibbles. The first four bits is called the zone and represent the category of the character, whereas the last four bits is called the digit and identify the specific character.

EBCDIC/ASCII Tables Equivalency

Character	EBCDIC	ASCII	Character	EBCDIC	ASCII
	HEX/BINARY	HEX/BINARY		HEX/BINARY	HEX/BINARY
A	C1 1100 0001	41 0100 0001	S	E2 1110 0010	53 0101 0011
B	C2 1100 0010	42 0100 0010	T	E3 1110 0011	54 0101 0100
C	C3 1100 0011	43 0100 0011	U	E4 1110 0100	55 0101 0101
D	C4 1100 0100	44 0100 0100	V	E5 1110 0101	56 0101 0110
E	C5 1100 0101	45 0100 0101	W	E6 1110 0110	57 0101 0111
F	C6 1100 0110	46 0100 0110	X	E7 1110 0111	58 0101 1000
G	C7 1100 0111	47 0100 0111	Y	E8 1110 1000	59 0101 1001
H	C8 1100 1000	48 0100 1000	Z	E9 1110 1001	5A 0101 1010
I	C9 1100 1001	49 01001 001	0	F0 1111 0000	30 0011 0000
J	D1 1101 0001	4A 0100 1010	1	F1 1111 0001	31 0011 0001
K	D2 1101 0010	4B 0100 1011	2	F2 1111 0010	32 0011 0010
L	D3 1101 0011	4C 0100 1100	3	F3 1111 0011	33 0010 0110
M	D4 1101 0100	4D 0100 1101	4	F4 1111 0100	34 0011 0100
N	D5 1101 0101	4E 0100 1110	5	F5 1111 0101	35 0011 0101
O	D6 1101 0110	4F 0100 1111	6	F6 1111 0110	36 0011 0110
P	D7 1101 0111	50 0101 0000	7	F7 1111 0111	37 0011 0111
Q	D8 1101 1000	51 0101 0001	8	F8 1111 1000	38 0011 1000
R	D9 1101 1001	52 0101 0010	9	F9 1111 1001	39 0011 1001
			Space	40 0100 0000	20 0010 0000

Example:

46 (Decimal) = 101110 (Binary) = 2E (Hex) = 0100 0110 (BCD) = 34 36 (ASCII) = F4 F6 (EBCDIC)

 

Final Remark: Thanks for reading the article. I appreciate your time. Happy Reading.