Académique Documents
Professionnel 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. 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 1 - Bitmap 2 - 128
MTI Message Type Indicator 64 (or 128) bits indicating presence/absence of other fields Other fields as specified in bitmap
Overall we can visualize the transmission of data trough a pipe in below given order: HEADER 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 1xxx 2xxx 3xxx 4xxx 5xxx 6xxx ISO 8583:1987 version ISO 8583:1993 version Reserved for ISO use Reserved for ISO use Reserved for ISO use Reserved for ISO use Reserved for ISO use
http://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print
1/11
3/14/2014
7xxx 8xxx 9xxx Reserved for ISO use Reserved for national use Reserved for private use
Description
Acquirer Acquirer repeat Card issuer Card issuer repeat Other Other repeat 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 x100 x101 Description Authorization Request Authorization Request Repeat
Authorization completion confirmation Authorization completion confirmation repeat Authorization Response Authorization completion response Authorization Advice Authorization advice repeat Authorization advice completion confirmation Authorization advice completion confirmation Report Authorization Advice Response
http://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print
2/11
3/14/2014
x132 x200 x210 x220 x230 x300 x302 x310 x312 x320 x322 x330 x332 x400 x402 x410 x412 x420 x422 x430 x432 x5xx x6xx x800 x810 Bitmap(s) Authorization advice completion response Financial Request Financial Response Financial Advice Financial Advice Response Acquirer File Update Request Issuer File Update Request Acquirer File Update Response Issuer File Update Response Acquirer File Update Advice Issuer File Update Advice Acquirer File Update Advice Response Issuer File Update Advice Response Acquirer Reversal Request Issuer Reversal Request Acquirer Reversal Request Response Issuer Reversal Request Response Acquirer Reversal Advice Issuer Reversal Advice Acquirer Reversal Advice Response Issuer Reversal Advice Response Reconciliation Request Messages Administrative Request Messages Network Management Request Network Management Request Response
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 Field 1 Secondary bit map. 1 if present else 0 Bit 2 Bit 3 Bit 4 Bit 64 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.
http://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print
3/11
3/14/2014
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.
LL, LLL
..17
http://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print
4/11
3/14/2014
..125
A Data Element may have a fixed or variable length. A length indicator precedes a variable length field in a message.
Sample Messages
[Refer Appendix A for number system basics]
PRIMARY BITMAP
PROCESSING CODE SYSTEM TRACE AUDIT NUMBER CARD ACCEPTOR TERMINAL IDENTIFICATION
11
000001
00 00 01
41
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 0
Hex Value 20
Field # 3
http://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print
5/11
3/14/2014
1 20 0010 0000 11
2 3 4 5 6 7
00 00 00 80 00 00
0000 0000 0000 0000 0000 0000 1000 0000 0000 0000 0000 0000 41
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")
Byte 0 1 2 3 4 5 6
Hex Value A0 20 00 00 00 80 00
Bit Value 1010 0000 0010 0000 0000 0000 0000 0000 0000 0000 1000 0000 0000 0000
41
http://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print
6/11
3/14/2014
7 10 0001 0000 60
Secondary Bitmap
Byte 0 1 2 3 4 5 6 7
Hex Value 04 00 00 00 00 80 00 00
Bit Value 0000 0100 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Field # 70
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.
Field # 0 2 3 4 7 11 14 18 22 25 35 37 41
Description MTI Primary Account Number Processing Code Transaction Amount Transmission data/time System trace audit number Expiration date Merchant Type POS Entry Mode POS Condition Code 4321123443211234=02051 Retrieval Reference Number Terminal ID
Value 0100 4321123443211234 000000 000000012300 0304054133 001205 0205 5399 022 00 2312312332 206305000014 29110001
YYMM
Swiped Card
Track 2
http://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print
7/11
3/14/2014
42 Merchant ID 1001001
49
Currency
840
American Dollars
Sample Authorization Response 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.
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 4) 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
http://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print 8/11
3/14/2014
Binary code decimal digits (0-9) are represented using FOUR bits. The valid combinations of bits and their respective values are
Binary Value 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001
Digit 0 1 2 3 4 5 6 7 8 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 0 MSB 6 1 5 0 4 1 3 0 2 1 1 1 0 0 LSB < Bit Number
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.
http://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print
9/11
3/14/2014
H C8 1100 1000 48 0100 1000 Z
I J K L M N O P Q R
C9 1100 1001 D1 1101 0001 D2 1101 0010 D3 1101 0011 D4 1101 0100 D5 1101 0101 D6 1101 0110 D7 1101 0111 D8 1101 1000 D9 1101 1001
49 01001 001 4A 0100 1010 4B 0100 1011 4C 0100 1100 4D 0100 1101 4E 0100 1110 4F 0100 1111 50 0101 0000 51 0101 0001 52 0101 0010
0 1 2 3 4 5 6 7 8 9 Space
F0 1111 0000 F1 1111 0001 F2 1111 0010 F3 1111 0011 F4 1111 0100 F5 1111 0101 F6 1111 0110 F7 1111 0111 F8 1111 1000 F9 1111 1001 40 0100 0000
30 0011 0000 31 0011 0001 32 0011 0010 33 0010 0110 34 0011 0100 35 0011 0101 36 0011 0110 37 0011 0111 38 0011 1000 39 0011 1001 20 0010 0000
Example: 46 (Decimal) = 101110 (Binary) = 2E (Hex) = 0100 0110 (BCD) = 34 36 (ASCII) = F4 F6 (EBCDIC)
License
This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)
http://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print
10/11
3/14/2014
http://www.codeproject.com/Articles/100084/Introduction-to-ISO?display=Print
11/11