Thursday, February 12, 2009

ISO 8583

0 comments

ISO 8583 provides a framework for creating protocols for the exchange of financial transaction messages. Typically, these are messages that involve transactions originating from cards of some sort or the other, be they credit or debit cards. It's important to realize that 8583 itself is not a protocol, just as XML isn't a file format. XML can be considered a description of how to specify file formats for structured data according to a set of rules. ISO 8583 is a metaprotocol providing a set of rules for the definition of financial transaction protocols.

As such, a variety of ISO 8583 protocols exist, a famous example being Visa's BASE I protocol for transaction authorization. There's proprietary protocols POS terminals use to communicate with their hosts, and scores of other standards defined by equipment manufacturers, software vendors, banks or national standardization bodies. Chances are, if you swipe a plastic card through a machine, be it POS Terminal or ATM, the transaction will be transported by an 8583 family protocol somewhere en route to the bank. So remember, if a vendor promises you their product speaks ISO, make sure they speak the ISO 8583 flavor that you're looking for.

Back to the standard, unlike RFCs, ECMA standards, or a number of other standardization documents, the ISO 8583 standard is NOT freely available and there is no place on the Internet where it can be downloaded. This applies to most international standards published by ISO, by the way.

The standard can be purchased from ISO directly or in some cases from your country's standardization organization, e.g. ANSI in the US or DIN in Germany. Wherever you buy them, they'll end up costing around $150 for a PDF document.

The standard, officially titled "Financial transaction card originated messages -- Interchange message specifications" is comprised of three parts:

  • Part 1: Messages, data elements and code values
  • Part 2: Application and registration procedures for Institution Identification Codes (IIC)
  • Part 3: Maintenance procedures for messages, data elements and code values

For implementation issues, Part 1 is most likely what you are looking for. Implementations based on older version of the standard from 1987 or 1993 are still widely in use, but to my knowledge, these versions are no longer available for sale by ISO. The currently available 2003 edition of the standard is sufficient for implementation purposes, though.


ISO 8583 :: Message Structure

ISO 8583 messages consist of 3 parts. The MTI (Message Type Indicator), the bitmap and finally the actual message data, grouped into a number of elements.

  • The MTI is a four digit numeric code which, as the name suggests, contains information about the message type of the current message. This includes information about the ISO version, the message function and who's sending it.

  • The MTI is followed by the bitmap which indicated which elements are present in the body of the message. In typical implementations, the bitmap is really a vector of single bits, either 8 or 16 bytes in length and thus can indicate the presence or absence or 64 or 128 data elements in the body of the message.

  • The bitmap is followed by the a series of data elements or fields, some of which may be further subdivided into subfields. The specific mode of data encoding varies from field to field. ISO 8583 specifies the description and encoding information for a number of fields. Some of these definitions are more or less constant across all ISO 8583 implementations, for example the card number is nearly always contained in a field indicated by bit 2 and named "PAN". In general though, the meaning of the fields and their encoding is specific to the ISO 8583 dialect.


ISO 8583 :: MTI

As it's name suggests, the message type indicator provides information about the type of message we are dealing with. The MTI consists of four components describing version, class, function and originator of the message. Typically, the four MTI components are encoded as two bytes, with each half-byte or nibble representing one of the components. For example, a message beginning 0x01 0x00 has the version info set to 0, the class set to 1, and function and originator fields both set to 0.

Version

This is the first piece of information contained in the message, indicating the ISO standard version the message is based on. The following version values are defined:

Value Version
0 1987
1 1993
2 2003
3-9 Reserved for ISO use

Message Class

the next position of the MTI provides information about the message class that the message is categorized as:

Value Message Class
0 Reserved for ISO use
1 Authorization
2 Financial presentment
3 File action
4 Reversal/Chargeback
5 Reconciliation
6 Administrative
7 Fee collection
8 Network management
9 Reserved for ISO use

At this point, one could asked oneself naively, what exactly do these classes mean? How are 'Financial Presentment' and 'Financial Presentment' different? What about the difference between the 'Administrative' and 'Network management' classes? It turns out that those are very good questions and not everybody using 8583 to create a protocol came up with identical answers. A semantically identical message marked 'Authorization' in one protocol may be 'Financial Presentment' in another. So vaguely, the classes should mean roughly what you think they mean, but you need to check the description of the protocol you're talking about to be certain.

Message Function

The following table contains the possible values of the message function component of the MTI. Note that here again the precise meaning of these functions are dependent on the flavor of ISO you're using.

Value Message Function
0 Request
1 Request response
2 Advice
3 Advice response
4 Notification
5 Notification acknowledgment
6 Instruction
7 Instruction acknowledgment
8,9 Reserved for ISO use

Again, don't ask what the difference is between an 'Advice', a 'Notification' and an 'Instruction'. The answer is: it depends.

Transaction Originator

The final component is information about who initiated the transaction. The possible values are:

Value Message Function
0 Acquirer
1 Acquirer Repeat
2 Card Issuer
3 Card Issuer Repeat
4 Other Originator
5 Other Originator Repeat
6-9 Reserved for ISO

An important aspect to note is the existence of 'Repeat' messages. In case no response was received, it's usually possible to resend the identical message with the originator information set to 'Repeat'.

MTI example

A typical message a new terminal sends out when first connected might be an 0800 message. Looking up the information above, we see the terminals protocol is old'ish (1987). The message class is 'Network Management', the message's function is a 'Request' and it's being sent by the 'Acquirer'. You could argue about the sense of claiming the acquirer sent the message when in fact it's being sent by a terminal at the merchant.

If the host the terminal is trying to communicate with answers, it would send back a 08100801 message, indicating the message to be a repeat. message. The message type is identical, apart from being a 'response' and not a 'request'. But, if the terminal doesn't receive an answer from the host, the terminal may try to resend the message, this time as a

When the answer from the host finally arrives, the terminal will be able to tell apart delayed answers to the first (0810) message and answers to the repeat (0811).

Bitmaps

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 fields 129 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 when the specific bit in the bitmap is true, i.e. byte '82x is binary '1000 0010' which means fields 1 and 7 are present in the message

Data Elements

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)**


BitNameFormatRepresentation
1Continuation bit
b8
2Primary account number (PAN)LLVARn..19
3Processing code
an 6
(Constructed Element)
4Amount transaction
n 16
(Constructed Element)
5Amount reconciliation
n 16
(Constructed Element)
6Amount cardholder billing
n 16
(Constructed Element)
7Date and time transmissionMMDDhhmmssn 10
8Amount cardholder billing fee
n 12
(Constructed Element)
9Conversion rate reconciliation
n8
10Conversion rate cardholder billing
n8
11Systems trace audit number
n 12
12Date and time local transactionCCYYMMDDhhmmssn 14
(Constructed Element)
13Date effectiveCCYYMMn6
14Date expirationYYMMn4
15Date settlementCCYYMMDDn8
16Date conversionMMDDn4
17Date captureMMDDn4
18Message error indicatorLLLVARansb..140
(Constructed Element)
19Country code acquiring institution
n3
20Country code primary account number (PAN)
n3
21Transaction life cycle identification data
ans 22
(Constructed Element)
22Point of service data code
b 12
(Constructed Element)
23Card sequence number
n3
24Function code
n3
25Message reason code
n4
26Merchant category code
n4
27Point of service capability
anb 25
(Constructed Element)
28Date reconciliationCCYYMMDDn8
29Reconciliation indicator
n3
30Amounts original
n 32
(Constructed Element)
31Acquirer reference number
n 23
(Constructed Element)
32Acquiring institution identification codeLLVARn..11
33Forwarding institution identification codeLLVARn..11
34Electronic commerce dataLLLLVARb..9999
(Composite Element)
35Track 2 dataLLVARz..37
36Track 3 dataLLLVARz..104
37Retrieval reference number
anp 12
38Approval code
anp 6
39Action code
n4
40Service code
n3
41Card acceptor terminal identification
ans 16
42Card acceptor identification codeLLVARans..35
43Card acceptor name/locationLLLLVARansb..9999
(Composite Element)
44Additional response dataLLLLVARansb..9999
(Composite Element)
45Track 1 dataLLVARans..76
46Amounts feesLLLVARans..216
(Constructed Element)
47Additional data nationalLLLVARans..999
48Additional data privateLLLVARans..999
49Verification dataLLLVARans..999
(Composite Element)
50-51Reserved for ISO

52Personal identification number (PIN) data
b8
53Security related control informationLLVARb..48
54Amounts additionalLLLVARans..126
(Constructed Element)
55Integrated circuit card (ICC) system related dataLLLLVARb..9999
56Original data elementsLLVARn..41
(Constructed Element)
57Authorisation life cycle code
n3
58Authorising agent institution identification codeLLVARn..11
59Transport dataLLLVARans..999
60-61Reserved for national useLLLVARans..999
62-63Reserved for private useLLLVARans..999
64 or 128Message authentication code (MAC) field
b4
65Reserved for ISO use

66Amounts original feesLLLVARans..216
(Constructed Element)
67Extended payment data
n2
68Batch/file transfer message control
an 9
(Constructed Element)
69Batch/file transfer control data
ans 40
(Constructed Element)
70File transfer description data
n 18
(Constructed Element)
71Reserved for ISO use

72Data recordLLLLVARansb..9999
73Date actionCCYYMMDDn8
74Reconciliation data primary
n 156
(Constructed Element)
75Reconciliation data secondary
n 90
(Constructed Element)
76-92Reserved for ISO use

93Transaction destination institution identification codeLLVARn..11
94Transaction originator institution identification codeLLVARn..11
95Card card issuer reference dataLLVARans..99
96Key management dataLLLVARb..999
97Amount net reconciliation
xn 21
(Constructed Element)
98Payee
ans 25
99Settlement institution identification codeLLVARan..11
100Receiving institution identification codeLLVARn..11
101File nameLLVARans..99
102Account identification 1LLVARans..28
103Account identification 2LLVARans..28
104Transaction specific dataLLLLVARansb..9999
(Composite Element)
105-108Reserved for ISO use

109Reconciliation fee amounts creditLLLVARans..144
(Constructed Element)
110Reconciliation fee amounts debitLLLVARans..144
(Constructed Element)
111-115Reserved for private use

116-122Reserved for national useLLLVARANS..999
123-127Reserved for private useLLLVARANS..999
128 or 64Message authentication code (MAC) field
b4



0 comments: