Saturday, 7 June 2014

ISO8583 BitMap Explained To be Used with JPOS

The Bitmap in the message provides information on the presence of other fields in the message. While using jpos, one does not have to populate it, as this gets populated based on the fields added automatically.
Refer this wiki for more details.

The BitMap in the message can be represented either as a Binary BitMap (e.g IFB_BITMAP) or an Asci/Hex BitMap(e.g IFA_BITMAP). When the message is packed using a binary representation, the bitmap would occupy 16 bytes of the message, whereas in the ASCII representation it would occupy 32 charachters. It can be explained with the following Simple example. 

Assume a message containing the following fields 2,3,6,11,12, 17, 64, 101 (including 0 as this is usually sent in all messages)
There are 8 bitmaps available, each bitmap representing the 128 fields available(ie 0 to 127)
The first 64 fields are considered as the primary bitmap and the next 64 to be the secondary, representing fields from 64 to 127. In many a message where we do not have to send the fields above 64 we do not even have to form the secondary bitmap. 
8 * 16 = 128

So each byte in the bitmap can hold information of 8 fields. Lets arrive at the position for the fields selected.
The nearest multiple of 8 for 2 ,3, 6  is 8 and 8/8 = 1
The nearest multiple of 8 for 11 and 12 is 16 and 16/8 = 2
The nearest multiple of 8 for 17 is 24 and 24/8 = 3
The nearest multiple of 8 for 64 is 64 and 64/8 = 8
The nearest multiple of 8 for 101 is 104 and 104 = 13

The table below provides the Binary represenation of each byte for the above example. It can be noticed that there are a total of 128 0 and 1s which indicates the presence and absence of the field.

BitMap PositionBinary RepresentationHex Code

To visualize the representation of the filds in the bitmap, lets consider the first 16 fields and represent the value of field as 0 (not present) and 1 (present). The first two row in the table illustrates the first two bytes of the bitmap and an indicator whether the field exists or not. A byte contains 8 bits, thus 8 fields can be represented in a byte using either 0 or 1.

While the binary representation can go in as byte, the ASCII/Hex packaging of the bitmap will result in this using up 32 characters instead of 16 bytes in the message.

Consider a message packed using the byte representation having the above mentioned fields (assume for simplicity that all other fields contain char and not bytes). The bitmap usually falls outside the printable ASCII representation, hence have provided the hexadecimal equivalent of the field only for the BitMaps.


In the event that the same message is unpacked using an IFA_BITMAP instead of IFB_BITMAP, the parser expects 32 chars instead of 64 and for example would take the chars, in message 5 and 6 and take the byte equivalent, thus resulting in a parsing fields that would be totally different than what was actually passed, resulting in a failure on unpacking the message using JPOS.

Hope this helps someone looking at it in some way. Will be writing further on what needs to be done and care to be taken for packing and unpacking the ISO message using jpos.


  1. Could we get the pictures associated with this blog

    1. @Alto: Thanks for pointing out, have updated the visual representation.

  2. hello Ganarajz...I do like to ask this question..

    .after packing and unpacking my data...i.e iso8583 financial transaction...i am only seeing Length = 3280 at my server side...and i can see the data been packed and my own end. i.e. my console.