This article has multiple issues. Please helpimprove it or discuss these issues on thetalk page.(Learn how and when to remove these messages) This articlerelies excessively onreferences toprimary sources. Please improve this article by addingsecondary or tertiary sources. Find sources: "ISO 8583" – news ·newspapers ·books ·scholar ·JSTOR(February 2011) (Learn how and when to remove this message) This articleneeds additional citations forverification. Please helpimprove this article byadding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "ISO 8583" – news ·newspapers ·books ·scholar ·JSTOR(June 2023) (Learn how and when to remove this message) (Learn how and when to remove this message)

ISO 8583 is an international standard forfinancial transaction card originated interchange messaging. It is theInternational Organization for Standardization standard for systems that exchange electronic transactions initiated by cardholders usingpayment 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 (EFTPOS) use ISO 8583 at some point in the communication chain, as do transactions made at ATMs. In particular, theMastercard,Visa andVerve 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 (data elements) 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 likeProximity Cards.

The ISO 8583 specification has three parts:

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

A card-based transaction typically travels from a transaction-acquiring device, such as apoint-of-sale terminal (POS) or anautomated teller machine (ATM), 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 (e.g., the card number or card holder details), the terminal (e.g., the terminal number, the merchant number), the transaction (e.g., the amount), 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 (MTI)
• 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

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 aTPDU 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.

The message type indicator (MTI) 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.

The first digit of the MTI indicates the ISO 8583 version in which the message is encoded.

Position two of the MTI specifies the overall purpose of the message.

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 (e.g., from acquirer to issuer and back with time-outs and automatic reversals in place), while advices are point-to-point messages (e.g., from terminal to acquirer, from acquirer to network, from network to issuer, with transmission guaranteed over each link, but not necessarily immediately).

Position four of the MTI defines the location of the message source within the payment chain.

Given an MTI value of0110, the following example lists what each position indicates:

• 0xxx → version of ISO 8583 (0 = 1987 version)
• x1xx → class of the message (1 = authorization message)
• xx1x → function of the message (1 = response)
• xxx0 → who began the communication (0 = acquirer)

Therefore, MTI0110 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:

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 value0x82 (decimal 130) is binary1000 0010, which means fields1 and7 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 16hexadecimal characters (0–9, A–F) in theASCII orEBCDIC character sets.A message will contain at least one bitmap, called theprimary 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.

Given a bitmap value of70 10 00 11 02 C0 48 04,

0x70 =0111 0000 (counting from the left, the second, third and fourth bits are 1, indicating that fields 2, 3 and 4 are present)

0x10 =0001 0000 (the first bit corresponds to field 9, so the fourth bit here indicates field 12 is present)

0x00 =0000 0000 (no fields present)

0x11 =0001 0001 (fields 28 and 32 are present)

0x02 =0000 0010 (field 39 is present)

0xC0 =1100 0000 (fields 41 and 42 are present)

0x48 =0100 1000 (fields 50 and 53 are present)

0x04 =0000 0100 (field 62 is present)

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 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), according to the following table:

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

The following is a table specifying the type of messages and processing code for each transaction type.

The following table shows response codes and their meanings for ISO 8583-1987, later versions uses 3 and 4 digit response codes.

The point of service (POS) 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.

For the 2003 specification the POS code consists of 16 binary characters split into four parts:

1. Card reading method used
2. Cardholder verification method used
3. POS environment
4. Security characteristics

For the 1993^[6] version it is a 12-character field consisting of 5 parts:

1. The terminal input capabilities (1st to 3rd character)
   • Card Data Input Capability
   • Cardholder Authentication Capability
   • Card capture capability
2. The operating environment (4th to 6th character)
   • Operating Environment / Terminal placement
   • Cardholder Present indicator
   • Card Present indicator
3. Authentication and verification done (7th to 9th character)
   • Card Data Input Method
   • Cardholder Verification Method
   • Cardholder Authentication Entity
4. The terminal's output capabilities (10th and 11th character)
   • 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.
5. PIN capture capability (12th character) indicates if the terminal can capture a pin code, and if so, the maximum length it can capture.

The point of service entry mode value consists of two parts:

1. PAN entry mode, the first two digits
2. PIN entry capability, the third digit

The following table shows PAN entry modes and their meanings.

The following table shows PIN entry capabilities and their meanings.

The Australian standard AS 2805 incorporates ISO 8583 and also covers a large number of other payments topics.^[7]

• Magnetic stripe card
• NCR Corporation
• Itautec
• Diebold
• ISO 20022

A simple and free ISO8583 Editor

• ISO 8583
• ISO standards
• Payment interchange standards
• Online payments

• Articles with short description
• Short description matches Wikidata
• Articles lacking reliable references from February 2011
• All articles lacking reliable references
• Articles needing additional references from June 2023
• All articles needing additional references
• Articles with multiple maintenance issues