ISO 8583
ISO 8583 is an international standard for financial transaction card originated interchange messaging. It is the International Organization for Standardization standard for systems that exchange electronic transactions initiated by cardholders using payment cards.
ISO 8583 defines a message format and a communication flow so that different systems can exchange these transaction requests and responses. The vast majority of transactions made when a customer uses a card to make a payment in a store use ISO 8583 at some point in the communication chain, as do transactions made at ATMs. In particular, the Mastercard, Visa and Verve networks base their authorization communications on the ISO 8583 standard, as do many other institutions and networks.
Although ISO 8583 defines a common standard, it is not typically used directly by systems or networks. It defines many standard fields which remain the same in all systems or networks, and leaves a few additional fields for passing network-specific details. These fields are used by each network to adapt the standard for its own use with custom fields and custom usages like Proximity Cards.
Introduction
The ISO 8583 specification has three parts:- Part 1: Messages, data elements, and code values
- Part 2: Application and registration procedures for Institution Identification Codes
- Part 3: Maintenance procedures for the aforementioned messages, data elements and code values
Message format
A card-based transaction typically travels from a transaction-acquiring device, such as a point-of-sale terminal or an automated teller machine, through a series of networks, to a card issuing system for authorization against the card holder's account. The transaction data contains information derived from the card, the terminal, the transaction, together with other data which may be generated dynamically or added by intervening systems. Based on this information, the card issuing system will either authorize or decline the transaction and generate a response message which must be delivered back to the terminal within a predefined time period.An ISO 8583 message is made of the following parts:
- Message type indicator
- One or more bitmaps, indicating which data elements are present. It consists of primary bitmap and secondary bitmap. The first bit of the primary bitmap indicates whether the secondary bitmap is present or not.
- Data elements, the actual information fields of the message
Cardholder-originated transactions include purchase, withdrawal, deposit, refund, reversal, balance inquiry, payments and inter-account transfers. ISO 8583 also defines system-to-system messages for secure key exchanges, reconciliation of totals, and other administrative purposes.
Message type indicator
The message type indicator is a four-digit numeric field which indicates the overall function of the message. A message type indicator includes the ISO 8583 version, the Message Class, the Message Function and the Message Origin, as described below.ISO 8583 version
The first digit of the MTI indicates the ISO 8583 version in which the message is encoded.| Code | Meaning |
| ISO 8583:1987 | |
| ISO 8583:1993 | |
| ISO 8583:2003 | |
| Reserved by ISO | |
| Reserved by ISO | |
| Reserved by ISO | |
| Reserved by ISO | |
| Reserved by ISO | |
| National use | |
| Private use |
Message class
Position two of the MTI specifies the overall purpose of the message.| Code | Meaning | Usage |
| Reserved by ISO | ||
| Authorization message | Determine if funds are available, get an approval but do not post to account for reconciliation. Dual message system, awaits file exchange for posting to the account. | |
| Financial messages | Determine if funds are available, get an approval and post directly to the account. Single message system, no file exchange after this. | |
| File actions message | Used for hot-card, TMS and other exchanges | |
| Reversal and charge-back messages | Reversal : Reverses the action of a previous authorization. Charge-back : Charges back a previously cleared financial message. | |
| Reconciliation message | Transmits settlement information message. | |
| Administrative message | Transmits administrative advice. Often used for failure messages. | |
| Fee collection messages | ||
| Network management message | Used for secure key exchange, logon, echo test and other network functions. | |
| Reserved by ISO |
Message function
Position three of the MTI specifies the messages function which defines how the message should flow within the system. Requests are end-to-end messages, while advices are point-to-point messages.| Code | Meaning | Notes |
| Request | Request from acquirer to issuer to carry out an action; issuer may accept or reject | |
| Request response | Response to a request | |
| Advice | Advice that an action has taken place; receiver can only accept, not reject | |
| Advice response | Response to an advice | |
| Notification | Notification that an event has taken place; receiver can only accept, not reject | |
| Notification acknowledgement | Response to a notification | |
| Instruction | ISO 8583:2003 | |
| Instruction acknowledgement | ISO 8583:2003 | |
| Reserved for ISO use | Some implementations use for positive acknowledgment. | |
| Reserved for ISO use | Some implementations use for negative acknowledgement. |
Message origin
Position four of the MTI defines the location of the message source within the payment chain.| Code | Meaning |
| Acquirer | |
| Acquirer repeat | |
| Issuer | |
| Issuer repeat | |
| Other | |
| Reserved by ISO | |
| Reserved by ISO | |
| Reserved by ISO |
Examples
Given an MTI value of, the following example lists what each position indicates:- → version of ISO 8583
- → class of the message
- → function of the message
- → who began the communication
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. Unfortunately, not all ISO 8583 implementations interpret the meaning of an MTI in the same way. However, a few MTIs are relatively standard:
| MTI | Meaning | Usage |
| Authorization Request | Request from a point-of-sale terminal for authorization for a cardholder purchase | |
| Authorization Response | Request response to a point-of-sale terminal for authorization for a cardholder purchase | |
| Authorization Advice | When the point-of-sale device breaks down and you have to sign a voucher | |
| Authorization Advice Repeat | If the advice times out | |
| Acquirer Response to Authorization Advice | Confirmation of receipt of authorization advice | |
| Acquirer Financial Request | Request for funds, typically from an ATM or pinned point-of-sale device | |
| Acquirer Response to Financial Request | Issuer response to request for funds | |
| Acquirer Financial Advice | e.g. Checkout at a hotel. Used to complete transaction initiated with authorization request | |
| Acquirer Financial Advice Repeat | If the advice times out | |
| Acquirer Response to Financial Advice | Confirmation of receipt of financial advice | |
| Batch Upload | File update/transfer advice | |
| Batch Upload Response | File update/transfer advice response | |
| Acquirer Reversal Request | Reverses a transaction | |
| Acquirer Reversal Advice | - | |
| Acquirer Reversal Advice Response | - | |
| Batch Settlement Response | Card acceptor reconciliation request response | |
| Network Management Request | Hypercom terminals initialize request. Echo test, logon, logoff etc. | |
| Network Management Response | Hypercom terminals initialize response. Echo test, logon, logoff etc. | |
| Network Management Advice | Key change |
Bitmaps
In ISO 8583, a bitmap is a field or subfield within a message, which indicates whether other data elements or data element subfields are present elsewhere in the message.A field is considered to be present only when the corresponding bit in the bitmap is set. For example, a hex with value is binary, which means fields and are present in the message and fields 2, 3, 4, 5, 6 and 8 are not.
The bitmap may be represented as 8 bytes of binary data or as 16 hexadecimal characters in the ASCII or EBCDIC character sets.
A message will contain at least one bitmap, called the primary bitmap, which indicates data whether elements 1 to 64 are present. The presence of an optional secondary bitmap is also indicated by the first bit in the primary bitmap. If present, the secondary bitmap indicates whether data elements 65 to 128 are present. Similarly, a tertiary bitmap can be used to indicate the presence of fields 129 to 192, although these data elements are rarely used.
Examples
Given a bitmap value of,| nth bit | 0 | 10 | 20 | 30 | 40 | 50 | 60 |
| nth bit | |||||||
| Bitmap |
Therefore, the given bitmap defines the following fields present in the message::
2, 3, 4, 12, 28, 32, 39, 41, 42, 50, 53, 62.
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 and the field length, according to the following table:
| Abbreviation | Meaning |
| a | Alpha, including blanks |
| n | Numeric values only |
| x+n | Numeric values, where the first byte is either 'C' to indicate a positive or Credit value, or 'D' to indicate a negative or Debit value, followed by the numeric value |
| s | Special characters only |
| an | Alphanumeric |
| as | Alpha & special characters only |
| ns | Numeric and special characters only |
| ans | Alphabetic, numeric and special characters. |
| anp | Alphabetic, numeric and pad characters. |
| b | Binary data |
| p | Pad character, space |
| 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.
| Type | Meaning |
| Fixed | no field length used |
| LLVAR or | Where 0 < LL < 100, means two leading digits LL specify the field length of field VAR |
| LLLVAR or | Where 0 < LLL < 1000, means three leading digits LLL specify the field length of field VAR |
| LL and LLL are hex or ASCII. A VAR field can be compressed or ASCII depending on the data element type. | LL can be one or two 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. Three-digit field length LLL uses two bytes with a leading '0' nibble if compressed, or three 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 three hex bytes '087456x. If ASCII then one byte for each digit or character is used, e.g. '38x, '37x, '34x, '35x, '36x. |
Examples
| Field Definition | Meaning |
| n 6 | Fixed length field of six digits |
| n.6 | LVAR numeric field of up to 6 digits in length |
| a..11 | LLVAR alpha field of up to 11 characters in length |
| b...999 | LLLVAR binary field of up to 999 bytes in length |
Processing code
The following is a table specifying the type of messages and processing code for each transaction type.| Transaction | Message type | Processing code |
| Authorization | ||
| Balance inquiry | ||
| Sale | ||
| Cash | ||
| Credit Voucher | ||
| Void | ||
| Mobile topup | - |
Response code
Ver 1987
The following table shows response codes and their meanings for ISO 8583-1987, later versions uses 3 and 4 digit response codes.| Code | Description |
| 00 | Approved or completed successfully |
| 01 | Refer to card issuer |
| 02 | Refer to card issuer's special conditions |
| 03 | Invalid merchant |
| 04 | Pick-up |
| 05 | Do not honor |
| 06 | Error |
| 07 | Pick-up card, special condition |
| 08 | Honour with identification |
| 09 | Request in progress |
| 10 | Approved for partial amount |
| 11 | Approved |
| 12 | Invalid transaction |
| 13 | Invalid amount |
| 14 | Invalid card number |
| 15 | No such issuer |
| 16 | Approved, update track 3 |
| 17 | Customer cancellation |
| 18 | Customer dispute |
| 19 | Re-enter transaction |
| 20 | Invalid response |
| 21 | No action taken |
| 22 | Suspected malfunction |
| 23 | Unacceptable transaction fee |
| 24 | File update not supported by receiver |
| 25 | Unable to locate record on file |
| 26 | Duplicate file update record, old record replaced |
| 27 | File update field edit error |
| 28 | File update file locked out |
| 29 | File update not successful, contact acquirer |
| 30 | Format error |
| 31 | Bank not supported by switch |
| 32 | Completed partially |
| 33 | Expired card |
| 34 | Suspected fraud |
| 35 | Card acceptor contact acquirer |
| 36 | Restricted card |
| 37 | Card acceptor call acquirer security |
| 38 | Allowable PIN tries exceeded |
| 39 | No credit account |
| 40 | Requested function not supported |
| 41 | Lost card |
| 42 | No universal account |
| 43 | Stolen card, pick-up |
| 44 | No investment account |
| 45-50 | Reserved for ISO use |
| 51 | Not sufficient funds |
| 52 | No checking account |
| 53 | No savings account |
| 54 | Expired card |
| 55 | Incorrect personal identification number |
| 56 | No card record |
| 57 | Transaction not permitted to cardholder |
| 58 | Transaction not permitted to terminal |
| 59 | Suspected fraud |
| 60 | Card acceptor contact acquirer |
| 61 | Exceeds withdrawal amount limit |
| 62 | Restricted card |
| 63 | Security violation |
| 64 | Original amount incorrect |
| 65 | Exceeds withdrawal frequency limit |
| 66 | Card acceptor call acquirer's security department |
| 67 | Hard capture |
| 68 | Response received too late |
| 69-74 | Reserved for ISO use |
| 75 | Allowable number of PIN tries exceeded |
| 78 | Card not activated |
| 80 | Visa transactions: credit issuer unavailable |
| 82 | Invalid card expiration date |
| 82 | CVN Mismatch: Negative CAM, dCVV, iCVV, or CVV results |
| 85 | Success: address verification |
| 76-89 | Reserved for private use |
| 90 | Cutoff is in process |
| 91 | Issuer or switch is inoperative |
| 92 | Financial institution or intermediate network facility cannot be found for routing |
| 93 | Transaction cannot be completed. Violation of law |
| 94 | Duplicate transmission |
| 95 | Reconcile error |
| 96 | System malfunction |
| 97-99 | Reserved for national use |
| Zero A-9Z | Reserved for ISO use |
| A Zero-MZ | Reserved for national use |
| N Zero-ZZ | Reserved for private use |
Ver 1993
Point of service entry modes (Field 22)
The point of service mode field state what conditions the card has been read under, which type of authentication has been made, and depending on the version of the specification, what the capabilities of the terminal are.Ver 2003
For the 2003 specification the POS code consists of 16 binary characters split into four parts:- Card reading method used
- Cardholder verification method used
- POS environment
- Security characteristics
Ver 1993
- The terminal input capabilities
- * Card Data Input Capability
- * Cardholder Authentication Capability
- * Card capture capability
- The operating environment
- * Operating Environment / Terminal placement
- * Cardholder Present indicator
- *Card Present indicator
- Authentication and verification done
- *Card Data Input Method
- *Cardholder Verification Method
- *Cardholder Authentication Entity
- The terminal's output capabilities
- *Card data output capability - can the terminal write to the magnetic stripe, or to the chip
- *Terminal output capability - can the terminal display or print something to the cardholder.
- PIN capture capability indicates if the terminal can capture a pin code, and if so, the maximum length it can capture.
Ver 1987
- PAN entry mode, the first two digits
- PIN entry capability, the third digit
| PAN Entry Mode | Meaning |
| 00 | Unknown |
| 01 | Manual |
| 02 | Magnetic stripe |
| 03 | Bar code |
| 04 | OCR |
| 05 | Integrated circuit card. CVV can be checked. |
| 07 | Auto entry via contactless EMV. |
| 10 | Merchant has Cardholder Credentials on File. |
| 80 | Fallback from integrated circuit card to magnetic stripe |
| 90 | Magnetic stripe as read from track 2. CVV can be checked. |
| 91 | Auto entry via contactless magnetic stripe |
| 95 | Integrated circuit card. CVV may not be checked. |
| 99 | Same as original transaction. |
The following table shows PIN entry capabilities and their meanings.
| PIN Entry Capability | Meaning |
| 0 | Unknown |
| 1 | Terminal can accept PINs |
| 2 | Terminal cannot accept PINs |
| 3 | mPOS software-based PIN-entry capability |
| 8 | Terminal has PIN-entry capability but the PIN pad is not currently operative |