Of course, it is one of the many financial transaction standards describing how to pack certain data fields such that it could reliably be unpacked as well. However, the distinguishing factors that the standard possesses are :
- It uses web sockets for communication which is very efficient.
- This standard helps the electronic system which reads the card number, the transaction amount and other relevant data fields to pack it all up so that it could be transmitted electronically to a transaction processing system where it could then be unpacked back into individual data components and then processed.
……………………………………………………………………………………………………
Where do the Others Lack?
There exist numerous methods for packing and unpacking data. It could be as simple as comma separated fields. Eg: I could choose to send the transaction information as simple comma separated values as:
“1234123412341234,1000, INR,987” (Card Number, Amount, Currency, Merchant ID).
The issue with such a simplistic model of data packing is that it lacks meta information i.e. the message itself does not contain any information on what exactly is being packed in it. Not that it could not have been overcome even with a comma-separated version- just that it could get cumbersome
……………………………………………………………………………………………………
Principles that drive this Standard
The ISO 8583 message is based on the principles that:
– In a transaction message, you only get to pick the number of fields from a predefined set of fields. So, if you need a field called ‘My girlfriend’s phone number’, sorry, ain’t possible.
– The meta information of which fields are present in the message is also a part of the message payload in a data structure called the ‘bitmap’.
Structure
– Most implementations contain a few bytes dedicated to a fixed header (eg: ^A^TISO016000010) after which the actual ISO 8583 message starts.
– In one of our projects, the header we used was of 14 bytes
MTI – The Message Type Indicator.
The first 4 bytes describe the message type.
Eg: 02 00, which tells that the message is actually a financial transaction request. (The response to this request would also be in ISO 8583 and would carry an MTI: 02 10). Various MTIs exist and can be found on the web.
Bitmap
It is almost a visual representation of which fields are actually present in this message and which fields are not.
Eg: F2 38 80 01 08 E0 80 0F
11110010 00111000 10000000 00000001 00001000 11100000 10000000 00001111
(all the bit positions that are 1 implies the corresponding fields are present)
Hex Binary (Positions that have 1)
F2= 11110010 -> (1,2,3,4,7)
38= 00111000 -> (11,12,13)
80= 10000000 -> (17)
01= 00000001 -> (32)
08= 00001000 -> (37)
E0= 11100000 -> (41,42,43)
80= 10000000 -> (49)
0F= 00001111 -> (61,62,63,64)
We’ve just read the map! Therefore the fields that will be present in this message are field numbers: (1,2,3,4,7,11,12,13,17,32,37,41,42,43,49,61,62,63,64)
Note the first bit. Field 1 is a special field which indicates the presence of an extended bitmap. Since this sample message contains 1 on the 1st position, it means that this message contains another bitmap with another 64 bits.
Extended bitmap, Binary 64 bits
80 00 00 00 00 00 00 00
(=hex .extended bitmap field)
(80)10000000 -> (position 64+1=65)
This extended bitmap shows that field number 65 is also present in this message.
Data Elements
Immediately after the bitmap, the data elements start serially. From the bitmap, we know that fields 2,3,4,7 are present one after the other. All that we need to do is to read them one by one. Each field number has a predefined type in the ISO 8583 definition and has a predefined length. Some fields have a variable length in which case the first N bytes provide the length of the field.
Example:
Data Element 2. Length 16. Value : 0000011319353459 = Primary account number
Data Element 3. Length 6. Value : 011000 =Processing code. 011000 = cash withdrawal
Data Element 4. Length 12. Value : 000000020000 =Amount 200.00
Data Element 7. Length 10. Value : 0804030013 =DateTime DDMMhhmmss
Data Element 11. Length 6. Value : 051028 =Systems Trace number
Data Element 12. Length 6. Value : 083013 =Time, hhmmss
Data Element 13. Length 4. Value : 0804 =Date, MMDD
Data Element 17. Length 4. Value : 0804 =CaptureDate, MMDD
Data Element 32. Length 6. Value : 123456 =Acquiring institution ID code 123456
Data Element 37. Length 12. Value : 192165102801 =Retrieval Ref. No.
……………………………………………………………………………………………………
Isn’t ISO 20022 the new standard?
ISO 8583 will be a difficult one to get rid of anytime soon and hence one way or the other, in the financial industry ISO-8583 is here to stay.
……………………………………………………………………………………………………
The views and opinions expressed in this article are those of the author.
To know more about our company, please click on Mindfire Solutions.