Showing posts with label ISO-8583. Show all posts
Showing posts with label ISO-8583. Show all posts

Saturday, 23 April 2016

What is ISO-8583 and how many its parts are there ?


ISO 8583
 : Financial transaction card originated messages

Interchange message specifications is the International Organization for Standardization standard for systems that exchange electronic transactions made by cardholders using payment cards.

It has three parts :
1. Messages, data elements and code values.
2. Application and registration procedures for Institution Identification Codes (IIC)
3. Maintenance procedures for messages, data elements and code values.

A card-based transaction typically travels from a transaction acquiring device, such as a point-of-sale terminal or an ATM, through a series of networks, to a card issuing system for authorization against the card holder's account.
The card issuing system will either authorize or decline the transaction and generate a response message which must be delivered back to the terminal in a timely manner.

ISO 8583 defines a message format and a communication flow so that different systems can exchange these transactions. The vast majority of transactions made at ATMs use ISO 8583.
Cardholder-originated transactions include purchase, withdrawal,deposit, refund, reversal, balance inquiry, payments and inter-account transfers.

What is MTI (Message type indicator) in ISO-8583 message ?


An ISO 8583 message is made of the following parts :
 1. Message type indicator (MTI)
 2. One or more bitmaps, indicating which data elements are present.
 3. Data elements, the fields of the message


MTI (Message type indicator)
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, the Message Function and the Message Origin.
0xxx  Version of ISO 8583 (1987 version)
x1xx  Class of the message (Authorization Message)
xx1x  Function of the message (Request Response)
xxx0  who began the communication (Acquirer)


MTI version
Position one of the MTI specifies the versions of the ISO 8583 standard which is being used to transmit the message.
0xxx  ISO 8583-1:1987 version
1xxx  ISO 8583-2:1993 version
2xxx  ISO 8583-1:2003 version
9xxx  Private usage

Message class
Position two of the MTI specifies the overall purpose of the message.
x1xx  Authorization message
x2xx  Financial message
x3xx  File Actions message (used for hot-card, TMS and other exchanges)
x4xx  Reversal message (Reverses the action of a previous authorization)
x5xx  Reconciliation Message (Transmits settlement information)
x6xx  Administrative Message (Transmits administrative advice. Often used for message reject or failure to apply)
x7xx  Fee Collection Message
x8xx  Network Management Message (used for secure key exchange, logon, echo test and other network functions)
x9xx  Reserved by ISO

Message function
Position three of the MTI specifies the message function which defines how the message should flow within the system.
Requests are end-to-end messages (e.g., from acquirer to issuer and back with timeouts and automatic reversals in place)
Advices are point-to-point messages (e.g., from terminal to acquirer, from acquirer to network, from network to issuer.
xx0x  Request
xx1x  Request Response
xx2x  Advice
xx3x  Advice Response
xx4x  Notification
xx8x  Response acknowledgment
xx9x  Negative acknowledgment

Message origin
Position four of the MTI defines the location of the message source within the payment chain.
xxx0  Acquirer
xxx1  Acquirer Repeat
xxx2  Issuer
xxx3  Issuer Repeat
xxx4  Other
xxx5  Other Repeat

Bearing each of the above four positions in mind, an MTI will completely specify what a message should do, and how it is to be transmitted around the network.

What is Bitmap in ISO-8583 message ?


Within ISO 8583, a bitmap is a field or subfield within a message which indicates which other data elements or data element subfields may be present elsewhere in a message.
A message will contain at least one bitmap, called the Primary Bitmap which indicates which of Data Elements 1 to 64 are present.

A secondary bitmap may also be present, generally as data element one and indicates which of data elements 65 to 128 are present. Similarly, a tertiary, or third, bitmap can be used to indicate the presence or absence of fields129 to 192, although these data elements are rarely used.

The bitmap may be transmitted as 8 bytes of binary data, or as 16 hexadecimal characters 0-9, A-F in the ASCII or EBCDIC character sets.
A field is present only when the specific bit in the bitmap is true.
For example : byte 82x (Hexadecimal) is binary '1000 0010' which means fields 1 and 7are present in the message and fields 2, 3, 4, 5, 6, and 8 are not present.


For more Bitmap examples: Click here

How to provide data in Data elements of ISO-8583 message ?


Data elements are the individual fields carrying the transaction information. There are up to 128 data elements specified in the original ISO 8583:1987 standard, and up to 192 data elements in later releases.
The 1993 revision added new definitions, deleted some, while leaving the message format itself unchanged.

While each data element has a specified meaning and format, the standard also includes some general purpose data elements and system-or country-specific data elements which vary enormously in use and form from implementation to implementation.

Each data element is described in a standard format which defines the permitted content of the field (numeric, binary, etc.) and the field length (variable or fixed)

a   Alpha, including blanks
n   Numeric values only
s   Special characters only
an   Alphanumeric
as   Alpha & special characters only
ns   Numeric and special characters only
ans   Alphabetic, numeric and special characters.
b   Binary data
z   Tracks 2 and 3 code set as defined in ISO/IEC 7813 and ISO/IEC 4909 respectively
. or .. or ...   Variable field length indicator, each . indicating a digit.
x or xx or xxx   Fixed length of field or maximum length in the case of variable length fields.

Additionally, each field may be either fixed or variable length. If variable, the length of the field will be preceded by a length indicator.
Fixed
no field length used

LLVAR or (..xx)
Where LL < 100, means two leading digits LL specify the field length of field

VARLLLVAR or (...xxx)
Where LLL < 1000, means three leading digits LLL specify the field length of field

VARLL and LLL are hex or ASCII.
A VAR field can be compressed or ASCII depending of the data element type.
LL can be 1 or 2 bytes.
For example, if compressed as one hex byte,'27x means there are 27 VAR bytes to follow.

If ASCII, the two bytes '32x, '37x mean there are 27 bytes to follow.
3 digit field length LLL uses 2 bytes with a leading '0' nibble if compressed, or 3 bytes if ASCII.
The format of a VAR data element depends on the data element type.
If numeric it will be compressed, e.g. 87456 will be represented by 3 hex bytes '087456x.
If ASCII then one byte for each digit or character is used, e.g. '38x, '37x, '34x, '35x, '36x.