ISO/TC 68/SC 6
`
`DRAFT INTERNATIONAL STANDARD ISO/DIS 8583
`
`755%“?
`
`Secretariat: AFNOR
`
`Voting terminates on
`Voting begins on
`1992—10—23
`1992—04-23
`INTERNATIONAL ORGANIZATION FOR STANDARDIZATION~ MEMDYHAPOQHAH OPTAHMIBALIHH I’IO CTAHLIIAPTMIIALIMVI' ORGANISATION INTERNATIONALE DE NORMALISATION
`
`Financial transaction card originated messages -— Interchange
`message specifications
`[Revision of first edition (ISO 8583:1987)]
`
`Messages initie's par cartes de transactions flnanciéres.~ Specification des messages d'interchange
`
`UDC 336.722.242681.327.838 ,
`
`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 Council'Resolution 45/1983 this DIS is
`submitted in the English language'only.
`‘
`
`is circulated as received from the committee
`this document
`To expedite distribution,
`secretariat. ISO Central Secretariat work of editing and text composition will be undertaken at
`publication stage.
`
`tral de l’ISO au stade de publication.
`
`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 distribué tel qu’il est parvenudu secré-
`tariat du comité. La redaction et la composition de texte seront effectuées au Secretariat cen-
`
`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 TO THEIR 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
`
`MasterCard, Exh. 1012, p. 1
`
`

`

`lSO 8583 : 1992 (E)
`
`Contents
`
`>
`
`0 Introduction ......................................
`
`1 Scope and field of application .........................
`
`Page
`
`v
`
`1
`
`1
`2 Definitions .......................................
`- Normative references ....................... 2bis
`3 Message structure .................................
`3
`3.1 General......« ..............................
`3
`3.2 Bitmaps 17
`3.3 Data element directory .........................
`32
`3.4 Requirements for data elements ..................
`40
`
`.
`.
`.
`.
`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 ..........................
`
`45
`45
`45
`54
`
`56
`56
`56
`56
`
`56
`.
`6 Codes Maintenance agency and registration authority ..... ’.
`56
`6.1 Maintenance of codes .........................
`56
`6.2 lSO 8583 institution identification codes ............
`6.3 All other lSO 8583 codes ...............- .......... 56
`
`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 .......
`
`57
`57
`57
`57
`57
`
`ii
`
`MasterCard, Exh. 1012, p. 2
`
`MasterCard, Exh. 1012, p. 2
`
`

`

`tso 8583 : 1992 (E)
`
`Figures
`
`- Bit map ........................................
`Figure 1
`Figure 2 - Reconciliation example ........................... ..
`.
`
`17
`55
`
`Tables
`
`4
`5
`
`667
`
`9
`t9
`23
`3t
`33
`4t
`4 3 ,
`
`- 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 ...............................
`Table 5 - Amounts in chargeback me'ssages ......................
`Table 6 - Message type identifiers .............................
`Table 7A » Bit maps (in numerical order) ........................
`Table 7B — Bit maps (by message type) .........................
`Table 8 - Conditions used in table 78 ..................... ‘ .....
`Table 9 Data element directory ...............................
`Table 10 - Usage of institution identification codes .................
`Table ti - Reconciliation calculation ............' ...............
`
`Annexes
`
`A Code listings (normative) .................................... 58
`
`A1 Action codes .......................................... 59
`A2 Amount type codes ..................................... 61
`A3 Authorization life cycle code ................ g ............... 61
`AA Card acceptor business codes (numerically) ................... 62
`A5 Card acceptor business codes (alphabetically) ................. 66
`A6 Functioncodes
`.......... 70
`
`A7 Message reason codes ........................ _.......... 73
`A8 Point of service datacodes ............................... 76
`A.9 Processing codes .' ..................................... 78
`
`B Conversion guide (informative) ............................... ~30
`
`C Forms for application for institution identifiers and codes (informative)
`
`.
`
`r
`
`i 126
`
`iii
`
`MasterCard, Exh. 1012, p. 3
`
`MasterCard, Exh. 1012, p. 3
`
`

`

`130 8583 : 1992 (E)
`
`Foreword
`
`is a worldwide
`iSO (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 lSO procedures requiring at
`least 75% approval by the
`member bodies voting
`
`international Standard lSO 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 allvlnternational 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
`
`MasterCard, Exh. 1012, p. 4
`
`

`

`lSO 8583 ; 1992 (E)
`
`O 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 oi 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. 5
`
`

`

`MasterCard, Exh. 1012, p. 6
`
`MasterCard, Exh. 1012, p. 6
`
`

`

`transaction card originated messages
`Financial
`specifications
`'
`
`—
`
`Interchange message
`
`lSO 8583 : 1992 (E)
`
`1 Scope
`
`This standard addresses the following:
`
`. 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
`. 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 lSO 7812 institution identification
`
`it also specifies the procedures used for the
`number.
`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:
`21
`acquires from the'card 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:
`22
`receiver of an activity that has been taken, requiring no
`approval but requiring a response.
`
`authorization: ' 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:
`25
`presence (denoted by 1) or absence (denoted by 0) 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 prev10usly
`completed financial transaction.
`(See 3.1.8.5.)
`
`codes management group: entity under the authority
`2.10
`of the lSO Council. responsible for assigning new code
`values and maintaining listings of lSO 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
`2.13
`the card issuer containing all the necessary data elements for
`authorization. posting and reconciliation. (See 3.1.3.2),
`
`MasterCard, Exh. 1012, p. 7
`
`MasterCard, Exh. 1012, p. 7
`
`

`

`180 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.)
`
`tohthe 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.303 request: a message where the sender informs the
`receiver that a transaction is in progress and a response is
`required to'complete 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 3.4.4 and 3.4.16.)
`
`218 maintenance agency: entity underthe authority of the
`lSO 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.
`
`notification: a message where the sender notifies the
`222
`receiver of an activity taken,
`requiring no approval or
`response.
`
`a' movement of funds from a cardholder
`payment:
`2.23
`account to another party, e.g., a utility bill payment.
`
`card acceptor location where the
`point of service:
`2.24
`cardholder agrees the transaction takes place.
`
`institution within a transaction
`receiving institution:
`2.25
`flow that receives. a message before it reaches the final
`destination.
`(See 3.4.4.)
`
`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
`lSO 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
`
`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,
`i.e.,
`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.
`‘
`
`transaction originatorinstitution: the institution initiating
`2.38
`the request, advice or notification message in a transaction.
`The transaction originator remains unchanged throughout the
`transaction.
`’
`
`‘
`
`transfer: the movement of funds by acardholder 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
`
`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. AII 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 T068 DIS 8908, Vocabulary and Data Elements.
`
`ISO 9564—1. Personal identification Number Management and Security —
`Part 1: PIN Protection Principles and Techniques.
`
`ISO 9807‘ - Requirements 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. 9
`
`

`

`MasterCard, EXh. 1012, p. 10
`
`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 nLImbers
`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
`
`ted 8588 : 1992 (E)
`
`3 - card issuer repeat
`4 - other
`5 - other repeat
`6-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
`
`MasterCard, Exh. 1012, p. 11
`
`

`

`[SO 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 amountp
`transaction cannot be determined until
`later. the amount,
`transaction shall be an estimated amount.
`
`approved and a further authorization is required for an
`additional amount (see table 1).
`
`The following types of authorization decisions are
`defined:
`
`9) 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
`
`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 1).
`
`transaction and
`identifies the usage of amount,
`Table 1
`amount,
`transaction within
`these authorization
`original
`message types.
`
`Table 1
`
`— Amounts in types of authorization messages
`
`Authorization type
`
`
`
`Original amount, transaction
`
`originally authorized amount
`
`In request, advice and notification messages:
`
` Amount, transaction
`‘Function
`
`code
`
`
`
`
`transaction amount
`
`
`
`
`
`new amount
`
`
`supplementary
`
`
`
`106,107
`
`additional amount
`
`sum of previous approvals. if
`available
`
`
`
`in response messages:
`
`
`
`
`
`
`
`
`'
`
`Authorization type
`
`
`
`Function
`code
`
`
`
`Amount transaction
`
`
`
`Original amount, transaction
`
`aaaravat ——_
`partial approval — approved amount
`originally requested amount
`aaaaiaarawa __ iva
`
`
`
`
`
`
`
`
`
`
`
`MasterCard, EXh. 1012, p. 12
`
`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, (eg. 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
`
`in request, advice and notification messages:
`
`Financtal type
`
`Function
`code
`
`
`
`Amount, transaction
`
`Original amount, transaction
`
`
`
`
`
`
`
`—-——
`
`prevrously
`201 202
`new amount
`originally authorized amount
`authorized
`V
`
`
`amounofchargeback
`
`Amount, transaction
`
`Original amount. transaction
`
`
`
`In response messages:
`
`
`FinanCIal type
`Function
`code
`
`
`
`
`
`
`
`
`
`
`‘ __—
`full approval
`partial approval — approved amount
`originally requested amount
`decline/reject
`
`
`
`;
`
`
`
`
`
`MasterCard, EXh. 1012, p. 13
`
`MasterCard, Exh. 1012, p. 13
`
`

`

`Iso 8583 : 1992 (E)
`
`h) The following types of financial transaction decisions
`are defined:
`V
`
`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).
`
`Table 3 shows the use of amounts in reversal messages:
`
`Table 3'- Amounts in reversal messages
`
`- 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
`
`3.1.3.3 File action message class
`
`Type of
`reversal
`
`Amount.
`transaction
`
`.
`
`Original
`amount.
`transaction
`
`
`amount
`reversed
`amount
`revméd
`
`types.
`
`original
`transaction
`amount
`
`.
`
`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 inqLiire into a file or perform card administration
`(eg,
`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:
`
`‘A reversal shall be initiated by an acquirer. Message
`a)
`reason codes are used to indicate the reason for the
`reversal (see clause A7 of Annex A).
`
`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.t 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. Ifthe original transaction
`
`g) Only lixx or 12xx transactions shall be reversed.
`
`h) Table 4 shows t2xx financial transactions that are not
`reversals:
`'
`
`Table 4 - Financial transactions
`
`
`
`Processing
`code
`
`Function
`code
`
` Function
`
`,
`02,22
`adjustment
`200
`
`representment
`
`205. 206, 207
`
`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 has'been committed. Message reason codes are
`used to indicate the reason for the chargeback (see clause
`A] of Annex A).
`
`MasterCard, EXh. 1012, p. 14
`
`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) A'chargeback shall not be declined by the receiver
`exceptvfor specific reasons as defined in clause A1 of
`Annex A although the original
`transaction may be,
`represented by the acquirer.
`
`d) The amount, transaction data element in a chargeback
`. 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
`
`Original amount,
`Amount,
`Type of
`
`chargeback transaction ‘ 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 transactionThe
`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. Ifthe original
`transaction was a debit, this subsequent chargeback
`shall indicate a credit.
`If the original transaction was a
`credit,
`this subsequent chargeback shall
`indicate a
`debit.
`
`iSO 8583 ; 1992 (E)-
`
`if the transaction that is being charged back requires a
`f)
`response, this response message shall be sent before the
`chargeback is generated.
`
`'A card issuer may charge back an original transaction
`9)
`plus any subsequent representment(s) submitted by the
`acquirer. A separate chargeback message shall be used
`for each.
`
`h) This standard specifies no limits on