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)**
| Bit | Name | Format | Representation |
| 1 | Continuation bit | b8 | |
| 2 | Primary account number (PAN) | LLVAR | n..19 |
| 3 | Processing code | an 6 | |
| (Constructed Element) | |||
| 4 | Amount transaction | n 16 | |
| (Constructed Element) | |||
| 5 | Amount reconciliation | n 16 | |
| (Constructed Element) | |||
| 6 | Amount cardholder billing | n 16 | |
| (Constructed Element) | |||
| 7 | Date and time transmission | MMDDhhmmss | n 10 |
| 8 | Amount cardholder billing fee | n 12 | |
| (Constructed Element) | |||
| 9 | Conversion rate reconciliation | n8 | |
| 10 | Conversion rate cardholder billing | n8 | |
| 11 | Systems trace audit number | n 12 | |
| 12 | Date and time local transaction | CCYYMMDDhhmmss | n 14 |
| (Constructed Element) | |||
| 13 | Date effective | CCYYMM | n6 |
| 14 | Date expiration | YYMM | n4 |
| 15 | Date settlement | CCYYMMDD | n8 |
| 16 | Date conversion | MMDD | n4 |
| 17 | Date capture | MMDD | n4 |
| 18 | Message error indicator | LLLVAR | ansb..140 |
| (Constructed Element) | |||
| 19 | Country code acquiring institution | n3 | |
| 20 | Country code primary account number (PAN) | n3 | |
| 21 | Transaction life cycle identification data | ans 22 | |
| (Constructed Element) | |||
| 22 | Point of service data code | b 12 | |
| (Constructed Element) | |||
| 23 | Card sequence number | n3 | |
| 24 | Function code | n3 | |
| 25 | Message reason code | n4 | |
| 26 | Merchant category code | n4 | |
| 27 | Point of service capability | anb 25 | |
| (Constructed Element) | |||
| 28 | Date reconciliation | CCYYMMDD | n8 |
| 29 | Reconciliation indicator | n3 | |
| 30 | Amounts original | n 32 | |
| (Constructed Element) | |||
| 31 | Acquirer reference number | n 23 | |
| (Constructed Element) | |||
| 32 | Acquiring institution identification code | LLVAR | n..11 |
| 33 | Forwarding institution identification code | LLVAR | n..11 |
| 34 | Electronic commerce data | LLLLVAR | b..9999 |
| (Composite Element) | |||
| 35 | Track 2 data | LLVAR | z..37 |
| 36 | Track 3 data | LLLVAR | z..104 |
| 37 | Retrieval reference number | anp 12 | |
| 38 | Approval code | anp 6 | |
| 39 | Action code | n4 | |
| 40 | Service code | n3 | |
| 41 | Card acceptor terminal identification | ans 16 | |
| 42 | Card acceptor identification code | LLVAR | ans..35 |
| 43 | Card acceptor name/location | LLLLVAR | ansb..9999 |
| (Composite Element) | |||
| 44 | Additional response data | LLLLVAR | ansb..9999 |
| (Composite Element) | |||
| 45 | Track 1 data | LLVAR | ans..76 |
| 46 | Amounts fees | LLLVAR | ans..216 |
| (Constructed Element) | |||
| 47 | Additional data national | LLLVAR | ans..999 |
| 48 | Additional data private | LLLVAR | ans..999 |
| 49 | Verification data | LLLVAR | ans..999 |
| (Composite Element) | |||
| 50-51 | Reserved for ISO | ||
| 52 | Personal identification number (PIN) data | b8 | |
| 53 | Security related control information | LLVAR | b..48 |
| 54 | Amounts additional | LLLVAR | ans..126 |
| (Constructed Element) | |||
| 55 | Integrated circuit card (ICC) system related data | LLLLVAR | b..9999 |
| 56 | Original data elements | LLVAR | n..41 |
| (Constructed Element) | |||
| 57 | Authorisation life cycle code | n3 | |
| 58 | Authorising agent institution identification code | LLVAR | n..11 |
| 59 | Transport data | LLLVAR | ans..999 |
| 60-61 | Reserved for national use | LLLVAR | ans..999 |
| 62-63 | Reserved for private use | LLLVAR | ans..999 |
| 64 or 128 | Message authentication code (MAC) field | b4 | |
| 65 | Reserved for ISO use | ||
| 66 | Amounts original fees | LLLVAR | ans..216 |
| (Constructed Element) | |||
| 67 | Extended payment data | n2 | |
| 68 | Batch/file transfer message control | an 9 | |
| (Constructed Element) | |||
| 69 | Batch/file transfer control data | ans 40 | |
| (Constructed Element) | |||
| 70 | File transfer description data | n 18 | |
| (Constructed Element) | |||
| 71 | Reserved for ISO use | ||
| 72 | Data record | LLLLVAR | ansb..9999 |
| 73 | Date action | CCYYMMDD | n8 |
| 74 | Reconciliation data primary | n 156 | |
| (Constructed Element) | |||
| 75 | Reconciliation data secondary | n 90 | |
| (Constructed Element) | |||
| 76-92 | Reserved for ISO use | ||
| 93 | Transaction destination institution identification code | LLVAR | n..11 |
| 94 | Transaction originator institution identification code | LLVAR | n..11 |
| 95 | Card card issuer reference data | LLVAR | ans..99 |
| 96 | Key management data | LLLVAR | b..999 |
| 97 | Amount net reconciliation | xn 21 | |
| (Constructed Element) | |||
| 98 | Payee | ans 25 | |
| 99 | Settlement institution identification code | LLVAR | an..11 |
| 100 | Receiving institution identification code | LLVAR | n..11 |
| 101 | File name | LLVAR | ans..99 |
| 102 | Account identification 1 | LLVAR | ans..28 |
| 103 | Account identification 2 | LLVAR | ans..28 |
| 104 | Transaction specific data | LLLLVAR | ansb..9999 |
| (Composite Element) | |||
| 105-108 | Reserved for ISO use | ||
| 109 | Reconciliation fee amounts credit | LLLVAR | ans..144 |
| (Constructed Element) | |||
| 110 | Reconciliation fee amounts debit | LLLVAR | ans..144 |
| (Constructed Element) | |||
| 111-115 | Reserved for private use | ||
| 116-122 | Reserved for national use | LLLVAR | ANS..999 |
| 123-127 | Reserved for private use | LLLVAR | ANS..999 |
| 128 or 64 | Message authentication code (MAC) field | b4 | |













0 comments:
Post a Comment