Professional Documents
Culture Documents
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.
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
Overall we can visualize the transmission of data trough a pipe in below given order:
<group id="_x0000_s1026" style="Z-INDEX: 251657216; POSITION: absolute; MARGIN-TOP: 6.5pt; WIDTH: 353.25pt; HEIGHT: 18pt;
MARGIN-LEFT: 0px" coordsize="7065,360" coordorigin="1440,15105" /><shapetype id="_x0000_t133" coordsize="21600,21600"
path="m21600,10800qy18019,21600l3581,21600qx,10800,3581,l18019,qx21600,10800xem18019,21600nfqx14438,10800,18019,e"
o:spt="133" /><path o:connecttype="custom" gradientshapeok="t" textboxrect="3581,0,14438,21600"
o:connectlocs="10800,0;0,10800;10800,21600;14438,10800;21600,10800" o:connectangles="270,180,90,0,0" o:extrusionok="f" />
https://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print 1/14
5/7/2017 Introduction to ISO 8583 - CodeProject
</shapetype /><shape id="_x0000_s1027" style="POSITION: absolute; WIDTH: 1800px; HEIGHT: 360px; TOP: 15105px; LEFT: 1440px"
type="#_x0000_t133" /><shadow on="t" /><textbox />
HEADER
</textbox /></shape /><shape id="_x0000_s1028" style="POSITION: absolute; WIDTH: 1380px; HEIGHT: 360px; TOP: 15105px; LEFT:
2640px" type="#_x0000_t133" /><shadow on="t" /><textbox />
MTI
</textbox /></shape /><shape id="_x0000_s1029" style="POSITION: absolute; WIDTH: 1740px; HEIGHT: 360px; TOP: 15105px; LEFT:
3540px" type="#_x0000_t133" /><shadow on="t" /><textbox />
BIT MAP
</textbox /></shape /><shape id="_x0000_s1030" style="POSITION: absolute; WIDTH: 2880px; HEIGHT: 360px; TOP: 15105px; LEFT:
4680px" type="#_x0000_t133" /><shadow on="t" /><textbox />
DATA ELEMENT
</textbox /></shape /><shape id="_x0000_s1031" style="POSITION: absolute; WIDTH: 1920px; HEIGHT: 360px; TOP: 15105px; LEFT:
6585px" type="#_x0000_t133" /><shadow on="t" /><textbox />
TRAILER
Now we can jump into details of the different components of the application data.
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.
Message Class
Message Sub-class
https://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print 2/14
5/7/2017 Introduction to ISO 8583 - CodeProject
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
Description
Originator
0 Acquirer
1 Acquirer repeat
2 Card issuer
4 Other
5 Other repeat
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
https://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print 3/14
5/7/2017 Introduction to ISO 8583 - CodeProject
Bitmap(s)
https://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print 4/14
5/7/2017 Introduction to ISO 8583 - CodeProject
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'.
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.
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.
https://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print 5/14
5/7/2017 Introduction to ISO 8583 - CodeProject
Abbreviation Meaning
an Alphanumeric
b Binary Data
z Tracks 2 & 3 code set as defined in ISO 7811 & ISO 7813
h Hex Data
Length of variable field that follows. LL - Two-digit length indicator (1 byte BCD) LLL -
LL, LLL
3-digit length indicator (2 bytes BCD)
Variable field of up to 17. The .. is a two-digit length indicator (1 byte BCD) specifying
..17 the number of digits defining the length of the variable data to follow.
..125 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.
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.
https://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print 6/14
5/7/2017 Introduction to ISO 8583 - CodeProject
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]
0 MTI 0800 08 00
080020200000008000000000000000013239313130303031
In above example, 0800 is the message type indicator; first position represents version number:
0 is for request
0 is for acquirer
Primary Bitmap
0 20 0010 0000 3
1 20 0010 0000 11
2 00 0000 0000
3 00 0000 0000
https://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print 7/14
5/7/2017 Introduction to ISO 8583 - CodeProject
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
32393131 30303031
MTI: 0800
In above sample, two new fields#60 and #70 are present. Here is our message representation:
MTI: 0800
Primary Bitmap
1 20 0010 0000 11
2 00 0000 0000
https://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print 8/14
5/7/2017 Introduction to ISO 8583 - CodeProject
3 00 0000 0000
4 00 0000 0000
5 80 1000 0000 41
6 00 0000 0000
7 10 0001 0000 60
Secondary Bitmap
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.
https://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print 9/14
5/7/2017 Introduction to ISO 8583 - CodeProject
41 Terminal ID 29110001
42 Merchant ID 1001001
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.
Optional header
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
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
https://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print 10/14
5/7/2017 Introduction to ISO 8583 - CodeProject
30 30 30 31 00 10 54 45 53 54 20 4D 45 53 53 47
03 01
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 (24)
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
0000 0
0001 1
0010 2
0011 3
https://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print 11/14
5/7/2017 Introduction to ISO 8583 - CodeProject
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.
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) 10 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.
https://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print 12/14
5/7/2017 Introduction to ISO 8583 - CodeProject
Example:
License
This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)
Share
https://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print 13/14
5/7/2017 Introduction to ISO 8583 - CodeProject
Introduction to FORTRAN Interoperability with Window Tabs (WndTabs) Add-In for DevStudio
.NET
SAPrefs - Netscape-like Preferences Dialog WTL for MFC Programmers, Part IX - GDI Classes,
Common Dialogs, and Utility Classes
Permalink | Advertise | Privacy | Terms of Use | Mobile Article Copyright 2010 by Suman Kumar
Seleccionar idioma
Web02 | 2.8.170630.1 | Last Updated 7 Aug 2010 Everything else Copyright CodeProject, 1999-2017
https://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print 14/14