`
`IIIIllmnmnI|IIIII
`
`DRAFT INTERNATIONAL STANDARD ISO/DIS 8583
`
`iD‘i€*7
`
`ISO/TC 68/SC 6
`
`Secretariat: AFNOR
`
`Voting terminates on
`Voting begins on
`1992-10-23
`1992-04-23
`INTERNATIONAL ORGANIZATION FOR STANDARDIZATION» MEXKUYHAPOQHAH OPT/\HVI3Al.IW1 I'lO CTAHLl:APTI'I3Al.IMI/I- ORGANISATION INTERNATIONALE DE NORMALISATION
`
`Financial transaction card originated messages —— Interchange
`message specifications
`[Revision of first edition (ISO 8583:1987)]
`
`Messages initiés par cartes de transactions flnancieres.~ Specification des messages d'interchange
`
`UDC 336.T22.24:681.327.838 7
`
`information
`identity cards, credit cards,
`financial documents,
`Descriptors: banking, banking documents,
`interchange, data processing, data storage devices, magnetic recording, messages,
`specifications,
`‘
`structures,
`formats, data, coded representation.
`4
`
`In accordance with the provisions of Counc'iI'ResoIution 45/.1983 this DIS is
`submitted in the English Ianguageonly.
`‘
`
`is circulated as received from the committee I
`this document
`To expedite distribution,
`secretariat. ISO Central Secretariat work of editing and text composition will be undertaken at
`publication stage.
`
`Conformément aux dispositions de la Résolution du Conseil 45/1983 ce DIS
`est distribué en version anglaise seulement.
`
`Pour accélérer la distribution, Ie présent document est dlstribué tel qu’il est parvenudu secre-
`tariat du comité. La rédaction et la composition de texte seront effectuées au Secrétariat cen-
`tral de I’ISO au stade de publication.
`
`IT IS THEREFORE SUBJECT TO CHANGE AND MAY NOT
`THIS DOCUMENT IS A DRAFT CIRCULATED FOR COMMENT AND APPROVAL.
`BE REFERRED TO AS AN INTERNATIONAL STANDARD UNTIL PUBLISHED AS SUCH.
`
`IN ADDITION TOITHEIR EVALUATION AS BEING ACCEPTABLE FOR INDUSTRIAL, TECHNOLOGICAL, COMMERCIAL AND USER PUR-
`POSES, DRAFT INTERNATIONAL STANDARDS MAY ON OCCASION HAVE TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL TO
`BECOME STANDARDS TO WHICH REFERENCE MAY BE MADE IN NATIONAL REGULATIONS.
`_
`
`© International Organization for Standardization. 1992
`
`MasterCard, Exh. 1012, p. 1
`
`
`
`iso 8588 : 1992 (E)
`
`Contents
`
`0 introduction‘ .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`1 Scope and field of application .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`2 Definitions
`- Normative references
`3 Message structure
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.«
`.
`.
`3.1 General .
`.
`.
`,
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`3.2 Bitmaps....' .
`.
`.
`.
`.
`.
`.
`.
`3.3 Data element directory .
`3.4 Requirements for data elements ,
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`
`.
`
`.
`
`.
`.
`
`~.
`.
`.
`
`.
`
`.
`
`.
`
`.
`.
`
`.
`.
`.
`
`.
`
`.
`
`.
`
`.
`.
`
`.
`
`.
`
`.
`
`.
`.
`
`.
`
`.
`
`.
`
`.
`.
`
`.
`.
`.
`. ..
`.
`.
`.
`
`.
`4. Message and transaction flows .
`.
`4.1 General .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`4.2 Message flow diagrams .
`.
`4.3 Transaction flow diagrams .
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`5 Message and transaction matching .
`5.1 General .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`,
`.
`52 Message matching
`5.3 Transaction matching .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`1
`.
`
`.
`
`.
`,
`.
`.
`
`.
`.
`
`.
`
`.
`.
`.
`
`.
`.
`
`.
`
`.
`.
`.
`
`.
`.
`.
`
`._,
`.
`.
`
`.
`
`.
`
`.
`.
`.
`
`.
`.
`
`.
`
`.
`.
`.
`
`.
`.
`
`.
`
`.
`.
`.
`
`.
`.
`;
`
`._.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`
`.
`.
`
`.
`
`.
`.
`.
`
`.
`.
`
`.
`
`.
`.
`.
`
`.
`.
`
`.
`
`,
`.
`
`.
`
`6 Codes Maintenance‘ agency and registration authority .
`6.1 Maintenance of codes .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`6.2 ISO 8583 institution identification codes
`6.3 All other ISO 8583 codes .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`
`.-
`
`.
`
`.
`
`.
`
`.
`
`7 Guidance on the use of this international standard .
`7.1 Additional message types
`7.2 Additional data elements
`.
`,
`.
`.
`7.3 Mandatory and conditional data elements .
`7.4 Unintentional introduction of control characters .
`
`.
`
`.
`
`45
`45
`54
`
`56
`56
`56
`56
`
`56
`56
`56
`, 56
`
`.
`
`57
`57
`57
`57
`57
`
`.
`
`.
`
`.
`.
`
`.
`
`.
`
`.
`.
`
`.
`
`.
`
`.
`.
`
`.
`
`.
`
`.
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`
`.
`.
`
`.
`.
`.
`. ..
`
`. ..
`
`.
`.
`
`.
`
`.
`
`.
`.
`
`.
`
`.
`
`.
`
`.
`.
`
`.
`
`.
`
`.
`
`.
`.
`
`MasterCard, Exh. 1012, p. 2
`
`
`
`Figures
`
`- Bit map
`Figure 1
`Figure 2 - Reconciliation example
`
`Tables
`
`lSO 8583 ; 1992 (E)
`
`.
`.
`.
`_
`.
`.
`
`.
`
`C
`_
`
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`_
`
`.
`.
`A
`.
`.
`.
`
`.
`
`.
`_
`
`*
`
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`_
`
`.
`.
`.
`.
`.
`.
`
`A
`
`.
`_
`
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`
`.
`
`.
`_
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`_
`
`.
`
`.
`_
`
`t
`
`.
`.
`
`.
`
`.
`.
`
`'
`
`.
`.
`.
`.
`.
`- Amounts in types of authorization messages .
`"able 1
`‘able 2 - Amounts in types of financial transaction messages .
`Table 3 - Amounts in reversal messages .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Table 4 — Financial transactions .
`.
`.
`.
`.
`,
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`r
`.
`Table 5 - Amounts in chargeback messages _
`.
`.
`.
`.
`.
`r
`.
`.
`.
`_
`.
`.
`.
`Table 6 - Message type identifiers r
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Table 7A ~ Bit maps (in numerical order)
`Table 7B - Bit maps (by message type)
`Table 8 - Conditions used in table 7B
`.
`,
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Table 9 Data element directory .
`.
`.
`.
`Table 10 - Usage of institution identification codes .
`Table 11 - Reconciliation calculation
`
`Annexes
`
`A Code listings (normative)
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`,
`.
`.
`.
`
`.
`
`.
`.
`r
`.
`.
`I
`
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`r
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`,
`
`.
`
`.
`.
`.
`.
`.
`.
`
`. 58
`
`. 59
`. 61
`, 61
`. 62
`. 68
`. 70
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`A1 Action codes .
`.
`.
`.
`,
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`A.2 Amount type codes .
`.
`.
`.
`.
`,
`.
`.
`.
`.
`.
`.
`A.3 Authorization life cycle code .
`.
`AA Card acceptor business codes (numerically)
`A.5 Card acceptor business codes (alphabetically)
`A.6 Function codes .
`.
`.
`.
`,
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`A.7 Message reason codes .
`A.8 Point of service data codes ,
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`. _ ,
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`
`.
`.
`
`,
`
`,
`.
`
`.
`
`__
`.
`
`r
`
`.
`.
`
`t
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`_
`.
`
`.
`
`. 73
`. 76
`
`. 78
`
`A9 Processing codes
`
`.
`
`.
`
`.
`
`.
`
`.
`
`B Conversion guide (informative)
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`,
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`r
`
`.
`
`.
`
`C Forms for application for institution identifiers and codes (informative)
`
`.
`
`.
`
`.
`
`7
`
`. ~30
`
`. 126
`
`MasterCard, Exh. 1012, p. 3
`
`
`
`ISO 8583 ; 1992 (E)
`
`Foreword
`
`is a worldwide
`lSO (the International Organization for Standardization)
`federation of national standards bodies (ISO member bodies). The work of
`preparing international Standards is normally carried out
`through lSO
`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.
`
`International Standards adopted by the technical committees are
`Draft
`circulated to the member bodies for approval before their acceptance as
`international Standards by the ISO Council.
`They are approved in
`accordance with ISO procedures requiring at
`least 75% approval by the
`member bodies voting.
`
`international Standard ISO 8583 was prepared by Technical Committee’
`lSO/TC 68, Banking and "Related Financial Services.
`in addition to defining
`requirements for message interchange, informative annexes have been added
`to assist the user of the standard in utilizing this edition and codes are listed
`in a normative annex.
`
`Users should note that alllnternational Standards undergo revision from time
`to time and that any reference made herein to any other international
`Standard implies its latest edition, unless otherwise stated.
`
`MasterCard, Exh. 1012, p. 4
`
`
`
`lso 8583 ; 1992 (E)
`
`0 Introduction
`
`industry include the exchangeof electronic messages
`Services of the financial
`relating to financial transactions. Agreements on application specifications are
`generally at a private level. This international Standard is designed as an interface
`specification enabling messages to be exchanged between systems adopting a
`variety of application specifications. The application specification may remain at the
`private level. Designers of such applications have complete design freedom within
`the overall constraint that messages shall be convertible to this interface format in
`order that international interchange may take place.
`
`This International Standard introduces the concept of a message version number to-
`distinguish between messages which comply with thisfor subsequent editions of the
`Standard, and those complying with the 1987 edition.
`
`This international Standard uses a concept called bit map, whereby each data
`element is assigned a position indicator in a control field, or bit map. The presence
`of a data element in a specific message is indicated by a one in the assigned
`position; the absence of a data element is indicated by a zero in the assigned
`position.
`'
`
`to the commercial
`Data representation used in individual systems is subject
`relationships between the parties contracting to each system. The message formats
`specified in this international Standard are designed to ensure that compatibility
`between systems conforming to this international Standard is always feasible.
`
`MasterCard, Exh. 1012, p. 5
`
`
`
`MasterCard, Exh. 1012, p. 6
`
`
`
`transaction card originated messages
`Financial
`specifications
`
`—
`
`Interchange message
`
`lSO 8583 : 1992 (E)
`
`1 Scope
`
`This standard addresses the following:
`
`J a)
`
`interchange Message Specifications
`
`This international Standard specifies a common interface
`by which financial transaction card originated messages
`may be interchanged between acquirers and card issuers.
`lt specifies message structure. format and content, data
`7 elements and values for data elements. The method by
`which settlementtakes place is not within the scope ofthis
`standard.
`’
`
`b) Registration Authority
`
`This International Standard specifies a numbering system
`for institution identification codes for financial institutions
`which do not have an ISO 7812 institution identification
`number.
`it also specifies the procedures used for the
`registration of institution identification codes.
`
`c) Maintenance Agency of Codes _
`
`This International Standard establishes procedures for a
`Maintenance Agency for codes used in this standard, the
`method of applying for codes and the method of obtaining
`lists of codes.
`
`2 Definitions
`
`For the purpose of this international Standard the following
`definitions apply:
`
`its agent) which
`institution (or
`financial
`acquirer:
`2.1
`acquires from thecard acceptor the data relating to the
`transaction and initiates that data into an interchange system.
`The acquirer remains unchanged throughout the transaction.
`
`a message where the sender notifies the
`advice:
`2.2
`receiver of an activity that has been taken, requiring no
`approval but requiring a response.
`
`authorization: i the approval or guarantee of funds
`2.3
`given by the card issuer to the acquirer (See 3.1.3.1.)
`
`authorizing agem: an institution that acts on behalf of
`2.4_
`and with the authority of the card issuer.
`
`a series of 64 bits used to identify the
`bit map:
`2.5
`presence (denoted by 1) or absence (denoted by O) of each
`data element in a message.
`(See 32.)
`
`party accepting the card and
`card acceptor:
`2.6 '
`presenting transaction data to an acquirer.
`
`customer associated with the primary
`cardholder:
`2.7
`account number requesting the transaction from the card ‘
`acceptor.
`
`(card) issuer: financial institution (or its agent) which
`2.8
`issues the financial transaction card to the cardholder. The
`card issuer remains unchanged throughout a transaction.
`
`chargeback: a transaction from the card issuer to the
`2.9
`acquirer used to partially or completely reverse a previously
`completed financial transaction.
`(See 3.1.8.5.)
`
`codes management group: entity under the authority
`2.10
`of the ISO Council. responsible for assigning‘ new code
`values and maintaining listings of ISO 8583 codes.
`
`credit transaction: a claim forfunds by the cardholder
`2.11
`for the credit of his account. At the same time it provides
`details of funds acknowledged as payable by the acquirer
`(and/or the card acceptor) to the card issuer.
`
`debit transaction: an approval by the cardholder of
`2.12
`the debit to his account. At the same time it provides a claim
`of funds made by the acquirer (and/or the card acceptor)
`against the card issuer.
`
`financial transaction: atransaction from the acquirerto
`213
`the card issuer containing all the necessary data elements for
`authorization, posting and reconciliation. (See 3.1.3.2).
`
`MasterCard, Exh. 1012, p. 7
`
`
`
`iso 8583 : 1992 (E)
`
`file action: a transaction used to add, change, delete
`214
`or replace a file or a record. (See 3.1.3.3.)
`
`toythe acquirer by a card issuer in a chargeback.
`3.1.3.2.)
`
`(See
`
`institution within a transaction
`forwarding institution:
`2.15
`flow that sends a message forward from the originating
`institution.
`(See 3.4.4.)
`
`2.30-y request: a message where the sender informs the
`receiver that a transaction is in progress and a response is
`required tocomplete the activity.
`
`inquiry:
`2.16
`information.
`
`an authorization transaction that requests
`
`unique number
`identification code:
`institution
`2.17
`assigned to an institution participating in-financial card
`originated message interchange.
`(See 34.4 and 3.4.16)
`
`218 maintenance agency: entity underthe authority of the
`ISO Council responsible for maintaining the list of codes
`within this International Standard.
`
`» 2.19 message: a set of data elements used to exchange
`information between institutions
`(or
`their agents).
`No
`communications (header/trailer, protocol, or character code)
`or security implications are assumed or identified,
`
`2.20 message class: the set of messages which describes
`the specific activities being performed.
`’
`
`2.21 message function: the identification of the purpose of
`a message and the activity involved.
`
`2.2 notification: a message where the sender notifies the
`receiver of an activity taken,
`requiring no approval or
`response.
`
`a‘ movement of funds from a cardholder
`payment:
`2.23
`account to another party, eg, a utility bill payment.
`
`card acceptor location where the
`point of service:
`2.24
`cardholder agrees the transaction takes place.
`
`the reentry of a request message
`resubmission:
`2.31
`which was previously denied or rejected.
`(See 3.1.3.1 and
`3.1.3.2.)
`
`reversal: a transaction from the acquirer to the card
`2.32
`issuer informing the card issuer that the previously initiated
`transaction cannot be processed ,as instructed,
`ie.,
`is
`undeliverable, unprocessed or cancelled by the receiver.
`(See 3.1.3.4.)
`
`settlement: a transfer of funds to complete one or
`_2.33
`more prior transactions made, subject to final accounting.
`
`settlement institution: financial institution (or its agent)
`2.34
`at which the accounts are held by the parties settling. This
`institution, acting on information providedby the parties,
`transfers the appropriate funds between the accounts.
`
`supplementary authorization: an authorization used
`2.35
`when a previous authorization was approved and one or
`more subsequent authorizations are required for additional
`amounts,
`(See 3.1.3.1.)
`
`transaction: one or more related messages within the
`2.36
`same message class designed to complete (insofar as this is
`possible) the intention of the sender of the original message.
`
`transaction destination institution: the final institution
`2.37
`receiving the request, advice or notification message in a
`transaction. The transaction destination remains unchanged
`throughout the transaction.
`‘
`
`institution within a transaction
`receiving institution:
`2.25
`flow that receives, a message before it reaches the final
`destination.
`(See 3.4.4.)
`
`transaction originatorinstitution: the institution initiating
`2.38
`the request, advice or notification message in a transaction.
`The transaction originator remains unchanged throughout the
`transaction.
`
`‘
`
`reconciliation: an exchange of messages between two
`2.26 .
`institutions (acquirer, card issuer or their agents) to reach
`agreement on financial totals.
`(See 3.1.3.6.)
`
`registration authority: entity under the authority of the
`2.27
`ISO Council designated to allocate institution identification
`codes and maintain the register of those codes.
`
`an authorization used
`replacement authorization:
`2.28
`when a previous
`authorization was approved and a
`subsequent authorization is required because the amount,
`transaction is now different from the originally approved
`amount.
`(See 3.1.3.1.)
`
`representmem: a financial transaction originated by
`2.29
`an acquirer to partially or wholly recover funds charged back
`
`transfer: the movement of funds by a.cardholder from
`2.39
`one of its accounts to another of the cardholder's accounts
`_ both of which are held by the same financial institution.
`
`version: a description of interchange message formats
`2.40
`that distinguishes between different arrangements of data
`elements within bit maps (i.e., where the data elements are
`added, deleted or their meaning, position or format changes
`or the message flows are modified) resulting from revisions
`of this standard. (See 3.1.1.)
`
`MasterCard, Exh. 1012, p. 8
`
`
`
`Normative references
`
`through
`The following standards contain provisions which,
`reference in this text, constitute provisions of this International
`Standard. At the time of publication, the editions indicated were
`valid. All standards are subject
`to revision, and parties to
`agreements based on this International Standard are encouraged
`to investigate the possibility of applying the most recent editions _
`of the standards indicated below. Members of IEC and ISO main—
`tain registers of currently valid International Standards.
`
`ISO 3166, Codes for the representation of names of countries.
`
`ISO 4217, Codes for the representation of currencies and funds.
`ISO 4909, Bank cards Magnetic stripe data content for track 3.
`
`ISO 7372, Trade data interchange - Trade data dictionary.
`
`ISO 7810, identification cards - Physical characteristics.
`
`ISO 7812, Identification cards - Numbering system and registration
`procedure for issuer identification.
`
`"ISO 7813, Identification cards - Financial transaction cards.
`
`ISO 8601, Specifications for representation of dates and times in information interchange.
`
`ISO TC68 DIS 8908, Vocabulary and Data Elements.
`
`ISO 9564-1, Personal identification Number Management and Security —
`Part 1: PIN Protection Principles and Techniques.
`
`ISO 9807 - Fiequirements for Message Authentication (retail).
`
`_
`
`ISO 10202-1, Security Architectures of Financial Transaction Systems
`using Integrated Circuit Cards: Part 1 - Card Life Cycle.
`
`MasterCard, Exh. 1012, p. 9
`
`
`
`MasterCard, Exh. 1012, p. 10
`
`
`
`3 Message structure
`
`3.1 General
`
`Each message identified in this international Standard shall
`be constructed in the following sequence: message type
`identifier, (see 3.1.1), one or two bit maps (see 3.2) and a
`series of data elements
`in the order of
`the bit map
`representation (see 3.3). Clause_'4 shows the circumstances
`when a message shall (or may) be sent, and the relationship
`between messages.
`
`3.1.1 Message type identifier structure _
`
`is a four digit numeric field
`.The message type identifier
`identifying each message version number, message class,
`message function and transaction originator. Every message
`shall begin with a message type identifier. Version numbers
`shall not be assigned as the result of editorial or code list
`changes.
`
`' First Position — Version Number
`
`0 - ISO 8583: 1987
`1
`- ISO 8583: 1992
`2-7 - reserved for ISO use
`8 - reserved for national use
`9 - reserved for private use
`
`the second through fourth
`Where the first position is 1,
`positions shall be defined as follows:
`
`Second Position ~ Message Class
`
`O - reserved for ISO use
`1
`- authorization
`2 - financial
`3 - file action
`
`4 - reversal/chargeback
`5 - reconciliation
`6 — administrative
`7 — fee collection
`8 - network management
`9 - reserved for ISO use
`
`Third Position - Message Function
`
`0 - request
`1
`- request response
`2 - advice
`
`3 - advice response
`4 - notification
`,
`5-9 - reserved for ISO use
`
`Fourth Position - Transaction Originator
`
`O — acquirer
`1
`- acquirer repeat
`2 - card issuer
`
`iso 8583 : 1992 (E)
`
`3 - card issuer repeat
`4 - other
`5 - other repeat
`8-9 - reserved for ISO use
`
`3.1.2 Message Repeats
`
`In 3.1.3 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.
`'
`
`3.1.3 Message Type identifier Descriptions
`
`Table 6 identifies the message types supported for each
`message class. Each of the following message classes
`support a particular activity:
`
`3.1.3.1 Authorization message class
`
`An authorization is an approval or guarantee of funds given
`by the card issuer to the acquirer. Authorization messages
`are not intended to permit the application of the approved
`transaction amount to the cardholder's account for billing or
`posting.
`'
`
`The following applies to all authorizations:
`
`a) Authorization request messages shall be used when the
`transaction cannot complete at the point of service until the
`response message is received indicating the action to be
`taken. The use of an authorization request message does
`not imply that the cardholder is present (e.g. telephone or
`mail order).
`
`b) An authorization request response message shall be
`sent in response to an authorization request message.
`it
`indicates the approval or guarantee of funds or the action
`to be taken as specified in the action code data element.
`
`c) Authorization advice messages shall be used to inform
`the card issuer of an authorization transaction which has
`completed at the point of service.
`'
`
`d) An authorization advice response message shall be
`sent in response to an authorization advice message.’ An
`authorization advice response message indicates if the
`card issuer accepts or rejects the transfer of financial
`liability.
`'
`
`e) Authorization notification messages shall be used to
`inform the card issuer of an authorization transaction which
`has completed at
`the point of service.
`There is no
`= response message
`to
`an
`authorization
`notification
`message.
`
`f) The function code data element shall be used to indicate
`thetype of authorization required (see table 1) and whether
`
`MasterCard, Exh. 1012, p. 11
`
`
`
`lso 8583 : 1992 (E)
`
`If the final
`the amount, transaction is accurate or estimated.
`amount, transaction is available the amount, transaction
`shall be an accurate amount.
`if
`the final amount,
`transaction cannot be determined until
`later, the amount,
`transaction shall be an estimated amount.
`
`.
`
`g) The following types of authorizations are defined:
`
`i) Original authorization - the first or only authorization
`used.
`
`ii) Replacement authorization - an ‘authorization used
`when a previous authorization was approved and a
`subsequent authorization is
`required to replace the
`. previously authorized amount because the amount of
`the transaction is now greater or less.
`
`iii) Resubmission authorization - an authorization used
`to reenter a previous’ authorization that was denied or
`rejected.
`
`iv) Supplementary authorization - an authorization used
`when one or more previous authorizations were
`
`approved and a further authorization is required for an
`additional amount (see table 1).
`
`The following types of authorization decisions are
`defined:
`
`l) Full approval — an authorization where the response
`from the card issuer indicates approval of the requested
`amount.
`
`- an authorization where the
`Partial approval
`ii)
`response from the card issuer indicates approval of an
`amount less than the originally requested amount (see
`table 1).
`-
`
`iii) Declined or rejected - an authorization where the
`request for approval
`is declined or the authorization
`request or advice message is rejected (see table i).
`
`transaction and
`identifies the usage of amount,
`Table 1
`transaction within
`these authorization
`amount,
`original
`message types.
`
`Table 1
`
`— Amounts in types of authorization messages
`
`In request, advice and notification messages:
`
`Authorization type
`
`Amount, transaction
`
`Original amount, transaction
`
`transaction amount
`
`new amount
`
`originally authorized amount
`
`supplementary
`
`106,107
`
`additional amount
`
`sum of previous approvals, if
`available
`
`in response messages:
`
`Authorization type
`
`code
`
`Amount, transaction
`
`Original amount, transaction
`
`,
`
`’
`
`transaction amount
`full approval
`partial approval H approved amount 4
`decline/reject
`
`originally requested amount
`
`V
`
`MasterCard, Exh. 1012, p. 12
`
`
`
`3.1.3.2 Financial message class
`
`A financial transaction permits the application ofthe approved
`transaction amount to the cardholder’s account for billing or
`posting.
`
`The following applies to all financial transactions:
`
`a) Financial request messages shall be used when the
`transaction cannot complete at the point of service until the
`response message is received indicating the action to be
`taken. The use of a financial request message does not
`imply that the cardholder is present, (e.g. telephone or mail
`order).
`
`b) A financial request response message shall be sent in
`response to a financial request message.
`A financial
`request
`response message indicates the approval or
`guarantee of funds or the action to be taken as specified in
`the action code data element.
`
`‘c) Financial advice messages shall be used to inform the
`card issuer of a financial transaction which has completed
`, at the point of service.
`
`d) A financial advice response message shall be sent in
`response to a financial advice message. Afinancial advice
`response message indicates if the card issuer accepts or
`rejects the transfer of financial liability.
`
`ISO 8583 : 1992 (E)
`
`e) Financial notification messages shall be used to inform
`the card issuer of a financial
`transaction which has
`completed at the point of service. There is no response
`message to a financial notification message.
`
`f) The function code shall be used to indicate the type of
`financial transaction and whether the amount, transaction
`is the same or different from any previously authorized
`amount (see table 2).
`
`g) The following types of financial transactions are defined:
`
`i) Original - first or only financial transaction used.
`
`ii) Previously authorized « a financial transaction used
`when an authorization was previously approved (see
`table 2).
`'
`
`transaction used to
`iii) Resubmission - a financial
`reenter a previous financial transaction that was denied
`or rejected (see table 2).
`
`iv) Representment — afinancial transaction originated by
`an acquirer to partially or wholly recover funds charged
`back to the acquirer by a card issuer in a chargeback
`(see table 2).
`v
`'
`
`Table 2 - Amounts in types of financial transaction messages
`
`lnfrequest, advice and notification messages:
`
`Financial type
`
`code
`
`Amount, transaction
`
`Original amount, transaction
`
`— p
`
`originally authorized amount
`
`reviously
`authorized
`
`201.202
`
`new amount
`'
`
`orcharseback
`
`In response messages:
`
`Financial type
`
`Function
`code
`
`Amount, transaction
`
`Original amount, transaction
`
`;
`
`-
`
`full approval
`‘
`partial approval - approved amount
`decline/reject
`
`originally requested amount
`originany requested amount
`
`MasterCard, Exh. 1012, p. 13
`
`
`
`lso 8583 : 1992 (E)
`
`h) The following types of financial transaction decisions
`are defined:
`'
`
`if the original
`was a debit, the reversal also indicates debit;
`transaction was a credit, the reversal also indicates a credit.
`
`transaction where the
`- a‘ financial
`i) Full approval
`response from the card issuer indicates approval of the
`originally requested amount (see table 2).
`
`- a financial transaction where the
`ii) Partial approval
`response from the card issuer indicates approval of an
`amount less than the originally requested amount (see
`table 2).
`»
`
`iii) Declined or rejected - a financial transaction where
`the request for approval
`is declined or the financial
`request or advice message is rejected (see table 2).
`
`transaction and
`Table 2 identifies the usage of amount,
`original amount, transaction within these financial message
`types.
`
`3.1.3.3 File action message class
`
`A file action message shall be used to add, change, delete or
`replace a file or record.
`in addition, file action messages may
`be used to inquire into a file or perform card administration
`(e.g.,
`report
`lost or stolen cards). The data record data
`element shall be used to convey specific file action record or
`file information.
`'
`
`3.1.3.4 Reversal message class
`
`A reversal shall be used to partially or completely nullify the
`effects of a previous financial or authorization transaction. All
`reversals shall use the 14xx message series. A reversal shall
`use the advice or notification messages since the activity has
`already occurred. The following applies to all reversals:
`
`Table 3 shows the use of amounts in reversal messages:
`
`Table 3'- Amounts in reversal messages
`
`Type of
`reversal
`
`Amount,
`transaction
`
`.
`
`amount
`reversed
`
`amount
`reversed
`
`Original
`amount.
`transaction
`
`original
`transaction
`amount
`
`g) Only tixx or 12xx transactions shall be reversed.
`
`h) Table 4 shows 12xx financial transactions that are not
`reversals:
`-
`
`‘Table 4 - Financial transactions
`
`Processing
`code
`
`Function
`code
`
`adjustment
`
`02,22
`
`,
`
`«A reversal shall be initiated by an acquirer. Message
`a)
`reason codes are used to indicate the reason for the
`reversal (see clause A.7 of Annex A).
`
`representment
`
`200
`
`205. 206, 207
`
`b) The amount, transaction dataelement in a reversal shall
`contain the amount‘ to be reversed and shall be less than
`or equal to the original amount as shown in table 3.
`
`c) Wheneverthe acquirer times out waiting for a response
`to an authorization or financial
`transaction request or
`advice, a reversal of the transaction shall be sent (see
`4.2.12).
`
`d) A reversal advice shall not be declined by the card
`issuer, except for specific reasons as defined in A.i of
`Annex A.
`
`e) A reversal shall not be reversed.
`
`f) The processing code in a reversal shall be the same as
`presented in the original message. lfthe original transaction
`
`3.1.3.5 Chargeback message class
`
`A chargeback shall be used to partially or completely nullify
`a previous 12xx financial transaction. ‘All chargebacks shall
`use the 14xx message series. A chargeback shall be an
`advice or notification as the activity has already occurred.
`
`The following applies to all chargebacks:
`
`a) A chargeback shall only be initiated by the card issuer.
`It shall be used when the card issuer determines that a
`
`customer dispute exists, or that an error or a violation of
`rules hasibeen committed. Message reason codes are
`used to indicate the reason for the chargeback (see clause
`A.7 of Annex A).
`
`MasterCard, Exh. 1012, p. 14
`
`
`
`b) A chargeback shall be generated only if the original
`transaction had financial
`impact on the cardholder’s net
`position.
`A chargeback shall not-be used to cancel a
`balance inquiry, account
`transfer or an authorization
`transaction. -
`
`c) Achargeback shall not be declined by the receiver
`excepttor specific reasons as defined in clause A1 of
`Annex A although the original
`transaction may be.
`represented by the acquirer.
`
`d) g The amount, transaction data element in a chargeback
`V shall be the amount to be charged back and shall be less
`than or equal to the original amount, transaction as shown
`in table 5 following:
`
`Table 5 - Amounts in chargeback messages
`
`Type of
`chargeback
`
`Amount,
`transaction
`
`‘
`
`Original amount,
`transaction
`
`full
`
`amount charged
`back
`
`amount charged
`back
`
`original
`transaction
`amount
`
`/
`
`e) The processing code in a chargeback may be used to
`indicate an adjustment where the card issuer corrects a
`chargeback, partially or completely, that was submitted in
`error. All card issuer initiated adjustments are chargeback
`(i4xx) transactions. The processing code in a chargeback
`may differ from the value in the original transaction.The
`processing code used in a chargeback shall be selected as
`follows:
`'
`
`the
`transaction,
`to charge back a 12xx financial
`i)
`chargeback shall contain the same processing code
`value as the transaction that is being charged back.
`If
`the original transaction was a debit, the chargeback
`shall also indicate a debit.
`‘If the original transaction
`was a credit,
`the chargeback shall also indicate a
`credit.
`
`ii) to cancel, either partially or completely, a previous
`chargeback that was submitted in error, the card issuer
`shall initiate a subsequent chargeback containing one
`of the two adjustment processing codes.
`lfthe original
`transaction was a debit, this subsequent chargeback
`shall indicate a credit.
`If the original transaction was a
`credit,
`this subsequent chargeback shall
`indi