ISO 8583:2023
(Main)Financial-transaction-card-originated messages — Interchange message specifications
Financial-transaction-card-originated messages — Interchange message specifications
This document specifies a common interface by which financial-transaction-card-originated messages can be interchanged between acquirers and card issuers. It specifies message structure and format, including normalized data types. Message, field, value definitions and supporting information are provided by the ISO 8583 maintenance agency (MA). Contact and web page information for the ISO 8583 MA can be found at: https://www.iso.org/maintenance_agencies.html. The method by which messages are transported or settlement takes place is not within the scope of this document. NOTE With the proliferation of technology available to financial institutions to offer services to customers, a range of tokens now exist for identifying account relationships (e.g. financial transaction cards). In order to maintain clarity, this document will continue to use card terminology that applies to tokens and cards, unless the element is specific to tokens or cards, in which case it will be identified as such. However, the actual token numeric issued by a financial institution can be different from the associated card numeric.
Messages initiés par cartes de transaction financière — Spécifications d'échange de messages
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 8583
Third edition
2023-07
Financial-transaction-card-originated
messages — Interchange message
specifications
Messages initiés par cartes de transaction financière — Spécifications
d'échange de messages
Reference number
ISO 8583:2023(E)
© ISO 2023
---------------------- Page: 1 ----------------------
ISO 8583:2023(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
© ISO 2023 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 8583:2023(E)
Contents Page
Foreword .iv
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Message structure . 5
4.1 Message components . 5
4.1.1 Sequence . 5
4.1.2 Message type . 5
4.2 Message repeats . 6
4.3 Message bitmaps . 6
4.4 Data element types . 6
4.4.1 General . 6
4.4.2 Primitive data elements . 6
4.4.3 Constructed data element . 7
4.4.4 Composite data elements . 7
5 Data elements . 9
5.1 General . 9
5.2 General requirements for data elements . 9
5.2.1 Variable length data elements . 9
5.2.2 Binary data . 10
5.2.3 Expression of amounts . . 10
5.2.4 Conversion rates . 10
5.2.5 Identification of institutions and routing . 10
5.2.6 Identification of account numbers . 13
5.2.7 Tag length value (TLV) data . 13
6 Messages and transactions .13
6.1 General .13
6.2 Message protocol . 14
6.3 Message errors . 14
6.4 Transaction relationships . 14
7 Maintenance .15
7.1 General . 15
7.2 Allocation of institution identification codes . 15
Annex A (informative) Summary of changes made to the ISO 8583 series .16
Bibliography .18
iii
© ISO 2023 – All rights reserved
---------------------- Page: 3 ----------------------
ISO 8583:2023(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use
of (a) patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO had not received
notice of (a) patent(s) which may be required to implement this document. However, implementers are
cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents. ISO shall not be held responsible for identifying any or all
such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 68, Financial services, Subcommittee SC 9,
Information exchange for financial services.
This third edition cancels and replaces ISO 8583-1:2003, ISO 8583-2:1998 and ISO 8583-3:2003, which
have been technically revised.
The main changes are as follows:
— ISO 8583-1 has been restructured to facilitate maintenance of the messages, data elements and code
values by a new ISO 8583 maintenance agency (MA). Parts of Clauses 5, 6, 7, 8 and 9 and Annexes
A, B, C, D, E and F from that document are now available at https://standards.iso.org/iso/8583 (see
A.2.3).
— Corrections and message, element and data code enhancements approved by the ISO 8583
registration and maintenance management group (RMMG) (see A.2.3) since the publication of
ISO 8583-1 have been included.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iv
© ISO 2023 – All rights reserved
---------------------- Page: 4 ----------------------
INTERNATIONAL STANDARD ISO 8583:2023(E)
Financial-transaction-card-originated messages —
Interchange message specifications
1 Scope
This document specifies a common interface by which financial-transaction-card-originated messages
can be interchanged between acquirers and card issuers.
It specifies message structure and format, including normalized data types. Message, field, value
definitions and supporting information are provided by the ISO 8583 maintenance agency (MA). Contact
and web page information for the ISO 8583 MA can be found at: https:// www .iso .org/ maintenance
_agencies .html.
The method by which messages are transported or settlement takes place is not within the scope of this
document.
NOTE With the proliferation of technology available to financial institutions to offer services to customers,
a range of tokens now exist for identifying account relationships (e.g. financial transaction cards). In order to
maintain clarity, this document will continue to use card terminology that applies to tokens and cards, unless
the element is specific to tokens or cards, in which case it will be identified as such. However, the actual token
numeric issued by a financial institution can be different from the associated card numeric.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 7812-1, Identification cards — Identification of issuers — Part 1: Numbering system
ISO/IEC 7816-6, Identification cards — Integrated circuit cards — Part 6: Interindustry data elements for
interchange
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
account identification
identification of a customer account or relationship, e.g. for the “from” or “to” account
3.2
acquirer
financial institution (or its agent) which acquires from the card acceptor (3.6) the data relating to the
transaction (3.30) and initiates that data into an interchange system
Note 1 to entry: The acquirer remains unchanged throughout a transaction.
1
© ISO 2023 – All rights reserved
---------------------- Page: 5 ----------------------
ISO 8583:2023(E)
3.3
advice
message (3.16) in which the sender notifies the receiver of an action that has been taken, requiring no
approval but requiring a response (3.27)
3.4
authentication
action of proving that someone or something is genuine
3.5
authorizing agent
institution that acts on behalf of and with the authority of the card issuer (3.8)
3.6
card acceptor
party accepting the card and presenting transaction (3.30) data to an acquirer (3.2)
3.7
cardholder
customer associated with the primary account number (3.23) requesting the transaction (3.30) from the
card acceptor (3.6)
3.8
card issuer
financial institution (or its agent) which issues the financial transaction card to the cardholder (3.7)
Note 1 to entry: The card issuer remains unchanged throughout a transaction (3.30).
3.9
dataset
group of related sub-elements within a composite data element
Note 1 to entry: See 4.4.3.
3.10
dataset bitmap
DBM
bitmap used to identify the presence (denoted by 1) or absence (denoted by 0) of sub-elements within a
dataset (3.9)
Note 1 to entry: See 4.4.4.4.
3.11
forwarding institution
institution within a transaction (3.30) flow that sends a message (3.16) forward from the originating
institution
Note 1 to entry: See 5.2.5.
3.12
institution identification code
unique number assigned to an institution participating in financial card-originated message (3.16)
interchange
Note 1 to entry: See 5.2.5.
3.13
instruction
message (3.16) where the sender notifies the receiver of an action to be taken
Note 1 to entry: An instruction acknowledgement (3.14) is not sent unless the receiver specifically requests one.
2
© ISO 2023 – All rights reserved
---------------------- Page: 6 ----------------------
ISO 8583:2023(E)
3.14
instruction acknowledgement
message (3.16) in which the receiver notifies the sender that one or more instruction (3.13) messages
have been received
Note 1 to entry: No financial liability is implied in sending the instruction acknowledgement message.
3.15
maintenance agency
MA
group responsible for the administrative duties related to the maintenance of messages (3.16), data
elements and code values related to this document, excluding the institution identification codes (3.12)
Note 1 to entry: See Clause 7.
3.16
message
set of data elements used to exchange information between institutions (or their agents)
Note 1 to entry: No communications (header or trailer, protocol or character code) or security implications are
assumed or identified.
3.17
message bitmap
series of bits used to identify the presence (denoted by 1) or absence (denoted by 0) of each data element
in a message (3.16)
Note 1 to entry: See 4.3.
3.18
message class
set of messages (3.16) which supports the specific activities being performed
3.19
message function
identification of the purpose of a message (3.16) and the activity involved
3.20
notification
message (3.16) in which the sender notifies the receiver of an activity taken
Note 1 to entry: A notification acknowledgement (3.21) is not sent unless the receiver specifically requests one.
3.21
notification acknowledgement
message (3.16) in which the receiver notifies the sender that one or more notification (3.20) messages
have been received
Note 1 to entry: No financial liability is implied in sending the notification acknowledgement.
3.22
point of service
POS
card acceptor (3.6) location where the cardholder (3.7) agrees the transaction (3.30) takes place
3.23
primary account number
PAN
series of digits used to identify a customer account or relationship
Note 1 to entry: See 5.2.6 and ISO/IEC 7812-1.
3
© ISO 2023 – All rights reserved
---------------------- Page: 7 ----------------------
ISO 8583:2023(E)
3.24
receiving institution
institution within a transaction (3.30) flow that receives a message (3.16) before it reaches the final
destination
Note 1 to entry: See 5.2.5.
3.25
repeat
resending of a request (3.26) or advice (3.3) message (3.16) for which no response (3.27) was received
within the expected time
3.26
request
message (3.16) in which the sender informs the receiver that a transaction (3.30) is in progress
Note 1 to entry: A response (3.27) is required to complete the activity.
3.27
response
message (3.16) in which the sender informs the receiver that a request (3.26) or advice (3.3) message
was received
Note 1 to entry: The response instructs the receiver on what action to take to complete the original request or
advice.
3.28
settlement
transfer (3.33) of funds to complete one or more prior transactions (3.30) made, subject to final
accounting
3.29
tag-length-value/basic encoding rules
TLV/BER
method of encoding data
Note 1 to entry: This is specified in ISO/IEC 8825-1, ISO/IEC 8825-2 and ISO/IEC 8825-3.
3.30
transaction
one or more related messages (3.16) within the same message class (3.18) designed to complete (insofar
as this is possible) the intention of the sender of the original message
3.31
transaction destination
final institution receiving the request (3.26), advice (3.3), notification (3.20) or instruction (3.13)
message (3.16) in a transaction (3.30)
Note 1 to entry: The transaction destination remains unchanged throughout the transaction.
3.32
transaction originator
institution initiating the request (3.26), advice (3.3), notification (3.20) or instruction (3.13) message
(3.16) in a transaction (3.30)
Note 1 to entry: The transaction originator remains unchanged throughout the transaction.
3.33
transfer
movement of funds by a cardholder (3.7) from one of its accounts to another of its accounts
Note 1 to entry: Both accounts are held by the same financial institution and linked to the same card.
4
© ISO 2023 – All rights reserved
---------------------- Page: 8 ----------------------
ISO 8583:2023(E)
3.34
version
description of interchange message (3.16) formats that distinguishes between different arrangements
of data elements within message bitmaps (3.17) resulting from revisions of this document
Note 1 to entry: See 4.1.2.2.
4 Message structure
4.1 Message components
4.1.1 Sequence
Each message identified in this document shall be constructed in the following sequence:
a) message type (see 4.1.2);
b) one or two message bitmaps (see 4.3);
c) a series of data elements in the order of the message bitmap representation (see 4.4).
4.1.2 Message type
4.1.2.1 General
The first component is the message type and is composed of two elements: a version number (see
4.1.2.2) and a message type identifier (see 4.1.2.3). Every message shall begin with a message type.
4.1.2.2 Version number
A version number shall be assigned when sufficient changes have been made in a revision of this
document such that it is necessary to know which version was used to construct a message in order
to properly process the message (see Table 1). Version numbers shall not be assigned as the result of
editorial or any changes that are managed by the ISO 8583 MA.
Table 1 — Version identification
Code no. International Standard Year of publication Other
0 ISO 8583 1987 —
1 ISO 8583 1993 —
2 ISO 8583-1 2003 —
a ISO 8583 2023 —
2
3 to 7 — — Reserved for ISO use
8 — — Reserved for national use
9 — — Reserved for private use
a
Code no. 2 is reused for this edition since no changes have been incorporated into this document that would
necessitate a new version to properly construct or parse a message for processing (see Annex A).
4.1.2.3 Message type identifier
The message type identifier is a three-digit numeric field identifying the message class, message
function and transaction originator. The complete list of allocated codes are specified at https://
standards .iso .org/ iso/ 8583.
5
© ISO 2023 – All rights reserved
---------------------- Page: 9 ----------------------
ISO 8583:2023(E)
4.2 Message repeats
Whenever a repeat message is identified, that repeat message shall be identical to its original message,
with the exception of the message type identifier and, if necessary, date and time transmission and the
message authentication code data elements.
4.3 Message bitmaps
The second message component is one or two message bitmaps, each consisting of 64 bits. Each bit
signifies the presence (1) or the absence (0) in the message of the data element associated with that
particular bit.
The primary message bitmap (bits 1-64) shall always be present and the most frequently used data
elements are indexed from these bit positions. Infrequently used data elements are indexed from the
secondary message bitmap (bits 65-128). The presence of the secondary message bitmap shall be
signified by a “1” in bit 01 of the primary message bitmap (see Figure 1). Bitmap positions for all data
elements are defined in a separate document provided at: https:// standards .iso .org/ iso/ 8583.
Figure 1 — Message bitmaps
4.4 Data element types
4.4.1 General
The third message component is made up of a series of data elements. Messages are constructed using
the message bitmap as an index of data elements that are present. Some data elements are of fixed
length and some are of variable length. The actual length of any given variable length data element shall
be provided in its fixed-length prefix.
There are three types of data elements:
a) primitive data element (see 4.4.2);
b) constructed data element (see 4.4.3);
c) composite data element (see 4.4.4).
The message structure does not preclude the use of additional data elements in a message as required
for national or private use.
4.4.2 Primitive data elements
A primitive data element is a data element where the content has no further part or sub-elements, e.g.
approval code.
6
© ISO 2023 – All rights reserved
---------------------- Page: 10 ----------------------
ISO 8583:2023(E)
4.4.3 Constructed data element
A constructed data element is a data element where the content consists of a fixed number of sub-
elements, all of which shall be present, e.g. amounts original. If there is no data for a particular sub-
element it shall contain the relevant default values, e.g. blank or zeroes.
Only the last sub-element may be a variable length sub-element, e.g. original data element. In this case,
the last sub-element does not have any preceding length attribute. The actual length of the last sub-
element is calculated from the overall length of the constructed data element of which it is a part.
In some cases, the structure of a constructed data element allows for a number of repetitions of the
fixed structure, e.g. amounts additional. Although the sub-elements of each repetition are fixed, they
are not always sent, for example the number of repetitions is optional within the limits set. Where a
repetition is sent, it shall contain all the defined sub-elements.
4.4.4 Composite data elements
4.4.4.1 Structure
A composite data element is a data element where the content consists of a large number of sub-
elements. Most of these sub-elements fall into natural categories, e.g. purchase card data, auto rental
data, airline data. In practice, any one transaction is likely to require data from only one, or at most a
limited number, of these categories.
In order to identify these categories, the concept of a “dataset” has been defined. All the sub-elements
that can be included in a particular composite data element are therefore divided into a number of sets
of related data (a dataset) and each dataset is given a “dataset identifier”.
The structure of a dataset is based on the message structure defined in this document and consists of a
second level of bitmap (DBM) which indicates which sub-elements are present in a particular dataset.
In addition, provision is made for identifying sub-elements using the tag-length-value/basic encoding
rules (TLV/BER) method as specified in ISO/IEC 8825-1, ISO/IEC 8825-2 and ISO/IEC 8825-3 as an
alternative to using the second-level bitmap.
Each composite data element can therefore contain a variable number of different datasets and can
include both TLV and bitmap formats.
To assist processing, each dataset has a two-digit binary length component immediately following
the dataset identifier (see 4.4.4.3). Figure 2 shows the structure of a composite data element within a
message.
This definition does not apply to the integrated circuit card (ICC)-related data element, as the linking of
related sub-elements shall be accomplished in accordance with the definitions given in ISO/IEC 7816-6.
The result is that the dataset identifier is replaced by the T element of the TLV, the dataset length by the
L element and the sub-elements by the V element. The TLV can be a constructed data object and/or a
series of individual data objects that shall conform with ISO/IEC 7816-6.
Figure 2 — Structure of a composite data element
7
© ISO 2023 – All rights reserved
---------------------- Page: 11 ----------------------
ISO 8583:2023(E)
4.4.4.2 Dataset identifiers
4.4.4.2.1 General
Each dataset is given a one-digit binary identifier, allowing up to 256 possible datasets per composite
data element. The dataset identifier is the first component of the dataset. Dataset identifiers can have a
value between 00 and FF (hexadecimal).
a) The values of 00 and FF are reserved for ISO use.
b) The values (01 to 70) shall only be used for the transmission of TLV sub-elements (see 4.4.4.2.2).
c) The values (71 to FE) shall only be used with DBMs (see 4.4.4.2.3).
The full range of dataset identifiers (01 to FE) is available for allocation within each composite data
element that is defined. Thus, there may be more than one instance of any specific dataset identifier
value. Unique identification of a specific dataset requires knowing the dataset identifier and the
associated composite data element bit position.
4.4.4.2.2 Dataset identifiers 01-70 (TLV format)
These identifiers indicate that all the sub-elements in the dataset are described using TLV encoding.
This format allows the transmission of a number of individual, otherwise unrelated, sub-elements. The
format of the composite data element is shown in Figure 3.
Figure 3 — Dataset identifiers 01-70
4.4.4.2.3 Dataset identifiers 71-FE (bitmap format)
These identifiers indicate that all the sub-elements in the dataset are described using a DBM, which is,
in turn, followed by the sub-elements, as indicated in the bitmap. The format is shown in Figure 4. The
pattern can be repeated a variable number of times, e.g. for purchasing card line item detail.
Figure 4 — Dataset identifiers 71-FE
4.4.4.2.4 Dataset identifier FF
This identifier is reserved for possible extension to a future two-digit identifier in case more than 255
identifiers per composite data element are required.
4.4.4.3 Dataset length
The dataset length is a two-digit number where each number is made up of 8 bits. The total length is
determined by treating the two digits as a single binary integer, giving a length from 1 to 65 535. This
gives the length of the sub-elements and any DBM that follows.
8
© ISO 2023 – All rights reserved
---------------------- Page: 12 ----------------------
ISO 8583:2023(E)
4.4.4.4 Dataset bitmaps (DBMs)
If the dataset identifier is between 71 and FE, the third dataset component is a DBM. The DBM indicates
the presence or absence of each of the possible sub-elements within the dataset in the same way as the
message bitmaps indicate the presence or absence of data elements in a message (see Figure 5).
The final bit in each DBM is for TLV sub-elements, to allow rarely used sub-elements to be included.
The initial DBM has a length of 16 bits (2 bytes) and is designed to cope with most dataset requirements.
Additional (continuation) DBMs may be added and have a length of 8 bits (1 byte) each. These bitmaps
are chained together using the initial bit of each bitmap. The length of all DBMs is measured as an
integral number of bytes.
The presence of a “1” in the first position of any bitmap indicates that another bitmap follows. The
presence of a “0” in the first position of a bitmap indicates that it is the last bitmap. This means that bits
0
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.