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.

Introduction

The ISO 8583 specification has three parts:
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:
The placements of fields in different versions of the standard varies; for example, the currency elements of the 1987 and 1993 versions of the standard are no longer used in the 2003 version, which holds currency as a sub-element of any financial amount element. As of June 2017, however ISO 8583:2003 has yet to achieve wide acceptance. ISO 8583 messaging has no routing information, so is sometimes used with a TPDU header.
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 (MTI)

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.
CodeMeaning
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.
CodeMeaningUsage
Reserved by ISO
Authorization messageDetermine 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 messagesDetermine if funds are available, get an approval and post directly to the account. Single message system, no file exchange after this.
File actions messageUsed for hot-card, TMS and other exchanges
Reversal and chargeback messagesReversal : Reverses the action of a previous authorization.
Chargeback : Charges back a previously cleared financial message.
Reconciliation messageTransmits settlement information message.
Administrative messageTransmits administrative advice. Often used for failure messages.
Fee collection messages
Network management messageUsed for secure key exchange, logon, echo test and other network functions.
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, while advices are point-to-point messages.
CodeMeaningNotes
RequestRequest from acquirer to issuer to carry out an action; issuer may accept or reject
Request responseIssuer response to a request
AdviceAdvice that an action has taken place; receiver can only accept, not reject
Advice responseResponse to an advice
NotificationNotification that an event has taken place; receiver can only accept, not reject
Notification acknowledgementResponse to a notification
InstructionISO 8583:2003
Instruction acknowledgementISO 8583:2003
Reserved for ISO useSome implementations use for positive acknowledgment.
Reserved for ISO useSome implementations use for negative acknowledgement.

Message origin

Position four of the MTI defines the location of the message source within the payment chain.
CodeMeaning
Acquirer
Acquirer repeat
Issuer
Issuer repeat
Other
Other repeat
Reserved by ISO
Reserved by ISO
Reserved by ISO
Reserved by ISO

Examples

Given an MTI value of, the following example lists what each position indicates:
Therefore, MTI is an authorization response message where actual transaction was originated by the acquirer.
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:
MTIMeaningUsage
Authorization RequestRequest from a point-of-sale terminal for authorization for a cardholder purchase
Authorization ResponseRequest response to a point-of-sale terminal for authorization for a cardholder purchase
Authorization AdviceWhen the point-of-sale device breaks down and you have to sign a voucher
Authorization Advice RepeatIf the advice times out
Issuer Response to Authorization AdviceConfirmation of receipt of authorization advice
Acquirer Financial RequestRequest for funds, typically from an ATM or pinned point-of-sale device
Issuer Response to Financial RequestIssuer response to request for funds
Acquirer Financial Advicee.g. Checkout at a hotel. Used to complete transaction initiated with authorization request
Acquirer Financial Advice RepeatIf the advice times out
Issuer Response to Financial AdviceConfirmation of receipt of financial advice
Batch UploadFile update/transfer advice
Batch Upload ResponseFile update/transfer advice response
Acquirer Reversal RequestReverses a transaction
Acquirer Reversal Advice-
Acquirer Reversal Advice Response-
Batch Settlement ResponseCard acceptor reconciliation request response
Network Management RequestHypercom terminals initialize request. Echo test, logon, logoff etc.
Network Management ResponseHypercom terminals initialize response. Echo test, logon, logoff etc.
Network Management AdviceKey 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 which of data 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 bit0102030405060
nth bit
Bitmap

Therefore, the given bitmap defines the following fields present in the message:

3, 7, 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:
AbbreviationMeaning
aAlpha, including blanks
nNumeric values only
x+nNumeric 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
sSpecial characters only
anAlphanumeric
asAlpha & special characters only
nsNumeric and special characters only
ansAlphabetic, numeric and special characters.
bBinary data
zTracks 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 xxxfixed 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.
TypeMeaning
Fixedno 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 of 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 DefinitionMeaning
n 6Fixed length field of six digits
n.6LVAR numeric field of up to 6 digits in length
a..11LLVAR alpha field of up to 11 characters in length
b...999LLLVAR binary field of up to 999 bits in length

ISO-defined data elements (ver 1987)

Processing code

The following is a table specifying the message type and processing code for each transaction type.
TransactionMessage typeProcessing code
Authorization
Balance inquiry
Sale
Cash
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.
CodeMeaning
00Successful approval/completion or that VIP PIN verification is valid
01Refer to card issuer
02Refer to card issuer, special condition
03Invalid merchant or service provider
04Pickup
05Do not honor
06General error
07Pickup card, special condition
08Honor with identification
09Request in progress
10Partial approval
11VIP approval
12Invalid transaction
13Invalid amount or amount exceeds maximum for card program
14Invalid account number
15No such issuer
16Insufficient funds
17Customer cancellation
18Customer dispute
19Re-enter transaction
20Invalid response
21No action taken
22Suspected Malfunction
23unacceptable transaction fee
24File update not supported by receiver
25Unable to locate record in file, or account number is missing from the inquiry
26Duplicate file update record, old record replaced
27File update field edit error
28File is temporarily unavailable
29File update not successful, contact acquirer
30Format error
31Bank not supported
32Completed partially
33Expired card
34Suspected fraud
35Card acceptor contact acquirer
36Restricted card
37Card acceptor call acquirer security
38Allowed PIN tries exceeded
39No credit account
40Requested function not supported
41Merchant should retain card
42No universal account
43Merchant should retain card
51Insufficient funds
52No checking account
53No savings account
54Expired card
55Incorrect PIN
56No Card Record
57Transaction not permitted to cardholder
58Transaction not allowed at terminal
59Suspected fraud
61Activity amount limit exceeded
62Restricted card
63Security violation
65Activity count limit exceeded
68Response received too late
75Allowable number of PIN-entry tries exceeded
76Unable to locate previous message
77Previous message located for a repeat or reversal, but repeat or reversal data are inconsistent with original message
78’Blocked, first used’—The transaction is from a new cardholder, and the card has not been properly unblocked.
80Visa transactions: credit issuer unavailable. Private label and check acceptance: Invalid date
81PIN cryptographic error found
82Negative CAM, dCVV, iCVV, or CVV results
83Unable to verify PIN
85No reason to decline a request for account number verification, address verification, CVV2 verification; or a credit voucher or merchandise return
91Issuer unavailable or switch inoperative
92Destination cannot be found for routing
93Transaction cannot be completed, violation of law
94Duplicate transmission
95Reconcile error
96System malfunction, System malfunction or certain field error conditions
B1Surcharge amount not permitted on Visa cards
N0Force STIP
N3Cash service not available
N4Cashback request exceeds issuer limit
N7Decline for CVV2 failure
P2Invalid biller information
P5PIN change/unblock request declined
P6Unsafe PIN
Q1Card authentication failed
R0Stop payment order
R1Revocation of authorization order
R3Revocation of all authorizations order
XAForward to issuer
XDForward to issuer
Z3Unable to go online
Ver 1993

Point of service entry modes

The point of service entry mode value consists of 2 parts:
1. PAN entry mode, the first 2 digits
2. PIN entry capability, the third digit
The following table shows PAN entry modes and their meanings.
PAN Entry ModeMeaning
00Unknown
01Manual
02Magnetic stripe
03Bar code
04OCR
05Integrated circuit card. CVV can be checked.
07Auto entry via contactless EMV.
10Merchant has Cardholder Credentials on File.
80Fallback from integrated circuit card to magnetic stripe
90Magnetic stripe as read from track 2. CVV can be checked.
91Auto entry via contactless magnetic stripe
95Integrated circuit card. CVV may not be checked.
99Same as original transaction.

The following table shows PIN entry capabilities and their meanings.
PIN Entry CapabilityMeaning
0Unknown
1Terminal can accept PINs
2Terminal cannot accept PINs