ISO 8583 là một chuẩn ISO sử dụng làm chuẩn mã hóa trong các hệ thống trao đổi giao dịch điện tử. ISO 8583 đưa ra định dạng message và luồng giao tiếp để các hệ thống khác nhau có thể trao đổi các giao dịch. Mặc dù ISO 8583 đưa ra một chuẩn chung nhưng nó không được sử dụng trực tiếp cho một hệ thống hay một network nào. Thay vào đó mỗi network sẽ tùy biến những chuẩn này cho phù hợp với mục đích sử dụng của nó. Các phiên bản khác nhau của ISO 8583 có cách đặt các trường ở vị trí khác nhau. Trong đó ISO 8583:2003 được công nhận rộng rãi.
INTERNATIONAL STANDARD Second edition 1993-12-15 Financial transaction card originated messages - Interchange message specificatiorls Messages initie’s par carte de transaction d’khange de messages financi&re - Spkifications Reference number IS0 8583:1993(E) IS0 8583 : 1993 (E) Contents Page Foreword iv V Scope Introduction Normative references Definitions 1 Message structure 4.1 General 4.2 Bit maps 4.3 Data element directory 4.4 Requirements for data elements 3 13 28 36 Message and transaction flows 5.1 General 5.2 Message flow diagrams 5.3 Transaction flow diagrams 41 41 41 48 Message and transaction matching 6.1 General 6.2 Message matching 6.3 Transaction matching 50 50 50 50 Maintenance Agency and Registration Authority 7.1 Maintenance of codes 7.2 IS0 8583 Institution identification codes 7.3 All other IS0 8583 codes 50 50 50 51 Guidance on the use of this International Standard 8.1 Additional message types 8.2 Additional data elements 8.3 Mandatory and conditional data elements 8.4 Unintentional introduction of control characters 51 51 51 51 51 @ IS0 1993 All rights reserved No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the publisher International Organization for Standardization Case postale 56 CH-1211 Genbve 20 Switzerland Printed in Switzerland l ii l ISO8583:1993(E) Figures Bit maps Reconciliation example * 13 49 Tables Amounts in types of authorization Amounts in types of financial Amounts in reversal Financial transactions Amounts in chargeback Message type identifiers messages transaction messages messages messages 6 7A Bit maps (in numerical order) 15 7B Bit maps (by message type) 19 Conditions Data element 10 Usage of institution 11 Reconciliation * used in table 7B * directory identification calculation codes 27 29 37 39 Annexes A A.1 A.2 A.3 A.4 A.4.1 A.4.2 A.5 A.6 A.7 A.8 A.9 Code listings Action codes Amount type codes Authorization life cycle codes Card acceptor business codes Card acceptor business codes (numerically) Card acceptor business codes (alphabetically) Fee type codes Function codes Message reason codes 52 53 55 55 55 55 59 63 64 65 Point of service data code Processing codes 68 70 B guide I 72 B.l Conversion Introduction 8.2 Purpose 73 B.3 B.3.1 B.3.2 B.3.2.1 B.3.2.2 8.3.2.3 Differences between 1987 and 1993 editions of IS0 8583 General *.* , Definitions Additions I Changes Deletions 73 73 73 74 74 74 75 III IS0 8583 : 1993 (E) B.3.3 B.3.4 8.3.5 B.3.5.4 B.3.5.2 B.3.5.3 B.3.5.4 B.3.5.5 B.3.6 B.3.7 B.3.7.1 B.3.7.2 B.3.7.3 B.3.7.4 B.3.7.5 B.3.7.6 B.3.7.7 B.3.7.8 B.3.7.9 B.3.7.10 B.4 B.4.1 B.4.1.1 B.4.1.2 B.4.1.3 B.4.1.4 B.4.1.5 B.4.2 B.4.2.1 B.4.2.2 B.4.3 B.4.4 75 75 83 83 84 85 86 90 92 107 107 107 107 107 107 108 108 108 108 109 Message structure Message types Data elements Additions Changes Deletions Action, function and message reason code mapping Point of sevice data code mapping Usage of data elements Message flows Authorization messages Financial messages File action messages Reversal messages Chargeback messages Reconciliation messages Administrative messages Fee collection messages Network management messages Exception message flows Further advice Usage of amount data elements General Authorizations Financial transactions Reversals Chargebacks Reconciliation processing General Accumulation Fee collection Usage of fee amount data elements 109 110 110 110 111 111 111 112 112 112 113 116 Tables Comparison B.2 File update code (1987) mapped B.3 Network function B.4 B.5 of message classes B.l to function code (1993) , , management information code (1987) mapped code (1993) * * 76 86 to Response code (1987) mapped to message reason code and action code (1993) * * Settlement code (1987) mapped to action code (1993) , 87 88 90 Point of service PIN capture code (1987) mapped to point of service data (1993) 91 Point of service condition code (1987) mapped to point of service data (1993) 91 92 B.9 Point of service entry mode (1987) mapped to point of service data (1993) Data elements by message class B.10 Reconciliation C Forms for application B.6 B.7 B.8 processing examples for institution 11 ., ,.,.,., ,,.,, , , identifiers and codes 93 114 117 IS0 8583 : 1993 (E) IS0 (the International Organization for Standardization) is a worldwide federation of national standards bodies (IS0 member bodies) The work of preparing International Standards is normally carried out through IS0 technical committees Each member body interested in a subject for which a technical has the right to be represented on that committee has been established committee International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work IS0 collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization Draft International Standards adopted by the technical committees are circulated to the member bodies for voting Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote International Standard IS0 8583 was prepared by Technical Committee lSO/rC 68, Banking and related financial services, subcommittee SC 6, Financial transaction cards, related media and operations This second edition cancels and replaces the first edition (IS0 858319871, of which it constitutes a technical revision Annex A forms an integral part of this International Standard Annexes B and C are for information only V IS0 8583:1993(E) Introduction Services of the financial industry include the exchange of electronic messages 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 this or 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 Data representation used in individual systems is subject to the commercial 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 VI INTERNATIONAL IS0 8583 : 1993 (E) STANDARD Financial transaction card originated Interchange message specifications IS0 4909:1987, Bank cards content for track Scope This International a) Interchange Standard Message addresses the following: Specifications 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 Normative Magnetic IS0 7810:1985, characteristics Identification IS0 78 12: 1987, Identification system and registration identification cards stripe - cards procedure IS0 78 13: 1990, /den tification transaction cards Authority This International Standard specifies a numbering system for institution identification codes for financial institutions which not have an IS0 7812 institution identification number It also specifies used for the registration of the procedures institution identification codes c) Maintenance - data IS0 7372:1986, Trade data interchange - Trade data elements directory (Endorsement of UNECEFDED, sections 1,2,3,4 and 9) This International Standard specifies a common interface by which financial transaction card originated messages may be interchanged between acquirers and card issuers It specifies message structure, format and content, data elements and values for data elements The method by which settlement takes place is not within the scope of this standard b) Registration messages - cards IS0 8601:1988, Data elements formats - Information interchange of dates and times Physical Numbering for issuer - Financial and interchange - Representation IS0 9564-1:1991, Banking - Persona/ identification Number management and security - Part I: PIN protection principles and techniques IS0 9807: 199 1, Banking and related financial -Requirements for message authentication services (retail) IS0 1OZOZ- 1: 199 1, Financial transaction cards Security architectures of financial transaction systems using integrated circuit cards - Part I: Card life cycle references The following standards contain provisions which, through 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 IS0 maintain registers of currently valid International Standards IS0 3166: 1988, Codes for the representation of countries IS0 4217:1990, Codes currencies and funds for the of names representation of Definitions For the purpose of this International following definitions apply Standard, the 3.1 acquirer: Financial institution (or its agent) which 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 3.2 advice: A message where the sender notifies the receiver of an activity that has been taken, requiring no approval but requiring a response IS0 8583 : 1993 (E) The approval o r guarantee of funds 33 authorization: give n by the card issuer to the acq uirer (see 1.3.1) 3.4 authorizing agent: An institution that acts behalf of and with the authority of the card issuer on 3.5 bit map: A series of 64 bits used to identify the presence (denoted by 1) or absence (denoted by 0) of each data element in a message (see 4.2) 36 card acceptor: pie senting transacti Party accepting the on data to an acqu irer card and 3.7 cardholder: Customer associated with the primary account number requesting the transaction from the card acceptor 3.8 (card) issuer: Financial institution (or its agent) which issues the financial transaction card to the cardholder The card issuer remains unchanged throughout a transaction 3.9 chargeback: A transaction from the card issuer to the acquirer used to partially or completely reverse a previously completed financial transaction (see 4.1.3.5) 3.10 credit transaction: A claim for funds by the cardholder 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 3.11 debit transaction: An approval by the cardholder of 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 3.12 financial transaction: A transaction acquirer to the card issuer containing necessary data elements for authorization, and reconciliation (see 4.1.3.2) from the all the posting 3.18 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 3.19 message class: The set of messages describes the specific activit ies bein g performe which d 3.20 message function: The identification of purpose of a message and the activity involved 3.21 notification: A message where notifies the receiver of an activity taken, approval or response the the sender requiring no 3.22 payment: A movement of funds from a cardholder account to another party, e.g., a utility bill payment 3.23 point of service: Card acceptor locat ion wh ere the cardholder agrees the transaction takes place 3.24 receiving institution: Institution within transaction flow that receives a message before reaches the final destination (see 4.4.4) a it 3.25 reconciliation: An exchange of messages between two institutions (acquirer, card issuer or their agents) to reach agreement on financial totals (see 4.1.3.6) 3.26 registration authority: Entity under the authority of the IS0 Council designated to allocate institution identification codes and maintain the register of those codes 3.27 replacement authorization: An authorization used 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 4.1.3.1) 3.13 file action: A transaction used to add, change, delete or replace a file or a record (see 4.1.3.3) 3.28 representment: A financial transaction originated by an acquirer to partially or wholly recover funds charged back to the acquirer by a card issuer in a chargeback (see 4.1.3.2) 3.14 forwarding institution: Institution within a transaction flow that sends a message forward from the originating institution (see 4.4.4) 3.29 request: A message where the sender informs the receiver that a transaction is in progress and a response is required to complete the activity An 3.15 inquiry: requests information authorization transaction that 3.16 institution identification code: Unique number assigned to an institution participating in financial card originated message interchange (see 4.4.4and 4.4.16) 3.17 maintenance agency: Entity under the authority of the IS0 Council responsible for maintaining the list of codes within this International Standard 3.30 resubmission: The reentry of a request message which was previously denied or rejected (see 4.1.3.1 and 4.1.3.2) 3.31 reversal: A transaction from the acquirer to the card 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 4.1.3.4) IS0 8583 : 1993 (El 3.32 settlement: or more prior accounting A transfer transactions of funds to complete one made, subject to final 3.33 settlement institution: Financial institution (or its agent) at which the accounts are held by the parties settling This institution, acting on information provided by the parties, transfers the appropriate funds between the accounts 3.34 supplementary authorization: An authorization used when a previous authorization was approved and one or more subsequent authorizations are required for additional amounts (see 4.1.3.1) 3.35 transaction: One or more related messages within the same message class designed to complete (insofar as this is possible) the intention of the sender of the original message 3.36 transaction institution message destination transaction destination institution: The final receiving the request, advice or notification transaction The transaction in a remains unchanged throughout the 3.37 transaction originator institution: The institution initiating the request, advice or notification message in a transaction The transaction originator remains unchanged throughout the transaction, 3.38 transfer: The movement of funds by a cardholder from one of its accounts to another of the cardholder’s accounts both of which are held by the same financial institution ’ 3.39 version: A description of interchange message between different that distinguishes formats 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 4.1.1) Message structure 4.1 General identified in this International Each message Standard shall be constructed in the following sequence: message type identifier, (see 4.1.1), one or two bit maps (see 4.2) and a series of data elements in the order of the bit map representation (see 4.3) Clause shows the circumstances when a message shall (or may) be sent, and the relationship between messages 4.1 l Message r type identifier structure The message type identifier is a four-digit numeric field 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 2-7 89- -Version Number IS0 8583:1987 IS0 8583:1993 reserved for IS0 use reserved for national use reserved for private use is 1, the second Where the first position fourth posit ions shall be defined as follows: Second Position - Message through Class reserved for IS0 use Oauthorization l2 - financial - file action reversaI/chargeback 4reconciliation 5administrative 6collection -fee network management 89 - reserved for IS0 use Third Position - Message Function - request response -request advice 2advice response 3notification 45-9 - reserved for IS0 use Fourth Position -Transaction Originator - acquirer - acquirer repeat issuer -card -card issuer repeat other 4repeat -other 6-9 - reserved for IS0 use 4.1.2 Message Repeats In 4.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 date and time, if necessary, identifier and, transmission and the message authentication code data elements 4.1.3 Message Type Identifier 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 Descriptions Table.6 identifies the message types supported for each message class Each of the following message classes support a particular activity: 4.1.3.1 Authorization message class f) The function code data element shall be used to indicate the type of authorization required (see table 1) and whether the amount, transaction is accurate or estimated If the final 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 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 amount to the of the approved transaction cardholder’s account for billing or posting The following applies to all authorizations: g) The defined: 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) i) Original authorization authorization used authorizations - the first or in types of authorization messages messages: T Authorization I original 100,101 transaction replacement 102,103 new amount resubmission 104,105 transaction supplementary 106,107 Original amount, transaction Amount, transaction Function code type I additional ma amount originally authorized amount amount I amount I sum of previous approvals, available if I In response messages: L I Authorization type full approval a- transaction part;al approval we approved decline/reject , Original amount, transaction Amount, transaction Function code , I zero are only iv) authorization an Supplementary authorization used when one or more previous authorizations were approved and a further authorization is required for an additional amount (see table 1) d) An authorization advice response message shall be sent in response to an authorization advice An authorization advice response message message indicates if the card issuer accepts or rejects the transfer of financial liability In request, advice and notification of iii) Resubmission authorization an authorization used to reenter a previous authorization that was denied or rejected c) Authorization advice messages shall be used to inform the card issuer of an authorization transaction which has completed at the point of service Amounts types 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 b) An authorization request response message shall be sent in response to an authorization request message Itindicates the approval or guarantee of funds or the action to be taken as specified in the action code data element Table - following mm amount amount I originally requested amount originally requested amount I ISO8583:1993(E) B.3.7.6 Reconciliation B.3.7.8 messages Reconciliation messages can be generated by the acquirer as in (i) or by the card issuer as in (ii) Fee collection messages There are no fee collection request collection messages can be generated as in (i) or by the card issuer as in (ii) messages Fee by the acquirer request advice notification 1500 -> 1520 -> 1540 -> 1510 1542 -> (ii) 1512 (response mandatory) (response mandatory) 1732 1740 -> 1730 1624 -> 1644 -> 1614 1844 -> 1814 Card Issuer Acquirer Case : Acquirer does not receive stand in Full reversal 1110 response Card Issuer 1100 -> original request No 1420 -> reversal Case : Acquirer receives 1110 response Transaction partially completed at the point of service Partial reversal Card Issuer Acquirer original transaction 1100 -> advice Cases I and cover the situations where the transaction fails completely, either on the acquirer side (I), e.g., the customer went away, or the card issuer side (2), e.g., the card issuer host is unavailable reversal Acquirer < 1430 < 1130 Notes: < - 1110 1420 -00-0> < 1430 reversal 1120 -> original transaction loo -0 -> < Id&30 < 1110 If stand-in is provided by the acquirer in Case 2, the 1120 can be used to advise the card issuer of the stand-in authorization, the 1420 having nullified the original authorization request Case is the situation where the card issuer has approved the transaction but this completes only partially, e.g., the authorization request is for French Francs 2000 but the customer only receives French Francs 1500 worth of services Note that a partial reversal may be used only if the 1110 has been received from the card issuer Case occurs when the card issuer 1110 response is not received and the acquirer is allowed to stand-in for the card issuer The 1420 nullifies the original authorization request and the 1120 advises the card issuer of the stand-in authorization Technically the 1120 could additionally be used in Case as an advice of the result of the partial transaction The end result on the customer’s open-to-buy is the same There is, however, an issue of responsibility in that the 1120 is a separate transaction, and therefore strictly speaking not covered by the approval given by the card issuer in the 1110 B.4 Further advice Further advice is given with regard to: a) usage of amou nt data elements in auth orizat ion, fin ancial, reversal and chargeback transact ions; b) reconciliation 1420 -> processing; c) fee collections; < 1430 partial reversal of fee amount data elements d) usage authorization, financial, reversal, chargeback fee collection messages in and These are areas in IS0 8583:1993 which have been substantially changed or are completely new, 109 IS0 8583 : 1993 (E) B.4.1 Usage of amount B.4.1.3 authorized amount (US $100) becomes amount, transaction data elements General Amount data elements are used differently in IS0 8583:1993 The amount, transaction data element now contains the actual amount transaction in authorization and financial messages and the amount to be reversed or charged back in 14xx messages This was not always the case in IS0 8583:1987 In authorization and financial messages, the amount, transaction data element was formerly used to send the originally requested amount with declines or rejected advices Under the revised standard, the amount, transaction data element contains zero, with the originally requested amount sent in original amount, transaction (contained within a new data element, amounts, original) In reversal messages (both issuer and acquirer generated) the actual amount transaction was formerly sent in the replacement amount data element The originally approved amount was sent in the amount, transaction data element Under the revised standard, the amount to be reversed or charged back is now sent in the amount, transaction data element and the originally approved amount in amount, transaction The replacement original amounts data element has been deleted from the revised standard B.4.1.2 Authorizations The follow ing types defi ned: of authorization Authorization a) Original authorization only one amount used, namely amount, transaction transacti ons are For an original data element is (e.g., US $100) This could be an accurate amount or an estimated amount depending upon whether the function code appearing in the authorization request message is 100 or 101 If the final amount, transaction is available, the amount, transaction is always an accurate amount This applies to all types of authorization b) Replacement Authorization authorization is required (because amount is now different than authorized) the new amount (e.g., the amount, transaction and 110 the original If a replacement the transaction that previously US $80) becomes the previously The new amount (US $80) could be an accurate amount or an estimated amount depending upon whether the function code appearing in the authorization request message is 102 or 103 c) Re-submission if an authorization is re-submitted (because the previous authorization has been denied or rejected) the amount, transaction (US $100) remains the same This could be an accurate or an estimated amount depending on whether the function code appearing in the authorization request message is 104 or 105 d) Supplementary Authorization - If a supplementary authorization is required (because an additional amount needs to be approved) then the incremental amount (e.g US $50) is sent in the amount, transaction data element This could be an accurate or an estimated amount depending on whether the function code appearing in the authorization request message is 106 or 107 The previous approved amount (US $100) may be sent in the original amount, transaction data element If a further supplementary authorization is required (e.g US $70) the amount in the original amount, transaction data element will be the sum of the previous approved amounts (US $150) e) Partial Approval - Where the card issuer cannot approve the full amount contained in the authorization request message, two amount data elements are returned in the authorization response message The amount, transaction data element is used to indicate the amount which the Issuer is prepared to amount, approve (e.g US $60) The original transaction data element is used to indicate the originally requested amount (US $100) For a partial required approval, action code 002 or 006 are f) Declined or rejected authorizations -Where the card issuer declines an authorization request or rejects an authorization advice, two amount data elements are returned in the relevant response message The amount, transaction data element contain zero The original amount, transaction data element must contain the originally requested amount (US $100) IS0 8583 : 1993 (E) B.4.1.3 Financial The following defined: transactions types of financial transactions are a) Original financial transaction e- For an original financial request message, only ne data element is used, namely amount, transaction (e.g US $120) For an original financial Code 200 is used request message, Function b) Previously authorized financial transaction - For a previously authorized financial request message (where the amount is the same as that previously authorized - as indicated by Function Code 201) only one amount data element is required, namely original amount, transaction This contains the amount previously authorized (US $120) f) Declined or rejected financial transaction Where the card issuer declines the financial request or rejects the financial advice, two amount data elements are returned in the relevant response message The amount, transaction data element contains zero The original amount, transaction data element contains the originally requested amount (US $120) B.4.1.4 Reversals The following defined: types of reversal transactions are a) Full reversal - For a full reversal, only one amount data element is required, namely amount, transaction (e.g US $200) This contains the amount to be reversed A full reversal uses message reason codes 4000-4020 (except 4004) For a previously authorized financial request message (where the amount is not the same as indicated by Function Code 202), two amount data elements are used The amount, transaction data element is used to indicate the new amount (e.g US $90) The original amount, transaction data element is used to indicate the previously authorized amount (US $120) b) Partial reversal - For a partial reversal, two amount data elements are used The amount, transaction data element is used to indicate the amount to be reversed (e.g US $150) This amount is always less than the original amount The original amount, transaction data element is used to indicate the amount, originally approved (US $200) A partial reversal uses message reason code 4004 c) Re-submission If a financial request is re-submitted (because the previous request has been denied or rejected) the amount, transaction (US $120) remains the same For a resubmitted financial request, function code 203 is used A partial reversal should never be used for a full reversal Amount, transaction and original amount, transaction cannot be equal in that case d) Representment For a representment, two amount data elements are used The amount, transaction data element is used by the acquirer to indicate funds to be recovered from the card issuer The original amount, transaction data element is used by the acquirer to indicate the original chargeback amount Function codes 205,206 or 207 are used to indicate the first, second or subsequent representment e) Partial approval - Where the card issuer cannot approve the full amount contained in the financial request message, two amount data elements are returned in the financial request response message The amount, transaction data element is used to indicate the amount the card issuer is prepared to approve (e.g US $80) The original amount, transaction data element is used to indicate the originally requested amount (US $120) For partial approvals, action code 002 is required B.4.1.5 Chargebacks The following defined: types of chargeback transactions are a) Full chargeback - For a full chargeback, only one amount data element is required, namely amount, transaction (e.g US $200) This contains the amount to be charged back and is always equal to the amount originally approved (US $200) A full chargeback uses message reason codes 4500-4999 and function codes 450-452 b) Partial chargeback - For a partial chargeback, two amount data elements are required The amount, transaction data element is used to indicate the amount to be charged back (e.g US $150) This amount is always less than the original amount The original amount, transaction data element is used to indicate the amount originally approved (US $200) A partial chargeback uses message reason codes 4500-4999 and function codes 453-455 111 ISO8583:1993(E) B.4.2 Reconciliation B.4.2.1 d) For all reversal (14X0) messages with an original processing code of 20-29 and original MTI = 12Xx: processing General IS0 8583:1993 provides a simplified and consistent structure for performing reconciliation for both transactions and fees A summary of the main improvements standard is given below: Consolidation of fee-related and -A revised and more detailed description of the processes involved in calculating reconciliation amounts and counts B.4.2.2 for add to the credits, chargeback amount, transaction to the amount add to the debits, chargeback amount, transaction to the amount g) For all fee collection If the amount, performing (17Xx) If the amount, add the amount, fee to the (based on fee type) Several examples are given in Table B.10 to illustrate the revised structure in IS0 8583:1993 used for reconciliation processing If the amount, rules apply to the reconciliation a) For all financial (12Xx) messages, processing Code of 00-19 (debit): with with a and add the chargeback number debits, with an and add the chargeback messages: credits, fee amount dedits, fee with IXX, amount 12XX and fee X is C: add the amount, fee to the (based on fee type) credits, fee amount dedits, fee fee X is D: add the amount, fee to the (based on fee type) amount i) Reconciliation records are always to be in the same currency Multi-currency reconciliation necessitates different records for each currency a add to the credits, number and add the amount, transaction to the credits, amount c) For all reversal (14X0) messages, with an original processing code of 00-19 and original MTI = 12Xx: add to the credits, reversal number and add the amount, transaction to the credits, reversal amount 112 h) For all other fees associated 14XX messages : If the amount, add to the debits, number and add the amount, transaction to the debits, amount b) For all financial (12Xx) messages, processing code of 20-29 (credits): number credits, fee X is D: The acquirer and card issuer (or their agents) accumulate counts and amounts of transactions and/or fees during message processing A net amount is then calculated by each reconciliation entity for the reconciliation period general an fee X is C: add the amount, fee to the (based on fee type) Accumulation The following process: with f) For all chargeback (14X2) messages original processing code of 20-19: data elements - lncorportation of fee collections and payment transactions into the reconciliation process - Provision of a mechanism checkpoint reconciliation e) For all chargeback (14X2) messages original processing code of 00-19: in the revised - Clarification of the terms reconciliation settlement as used by the standard - add to the debits, reversal number and add the amount, transaction to the debits, reversal amount j) If the currency of reconciliation is different from the transaction currency, the amount, reconciliation is used instead of amount, transaction k) If the amounts, fees contains an amount, reconciliation fee sub-element (i.e the currency code, fee is different from the currency of reconciliation), this is used in reconciliation in place of the amount, fee I) Amounts, original and amounts, original not used in the reconciliation process fees are IS0 8583 : 1993 (E) B.4.3 Fee collection IS0 8583:1993 includes a new message for the collection of fees series (17Xx) Fee collection messages can be in either direction ; acquirer to card issuer or card issuer to acquirer A list of message types in the 17XX series can be found in Table B.9 A list of mandatory and conditional data elements associated with 17XX messages can be found in Table B.9 Fee collections have a financial impact and affect reconciliation (see table B.lO) Fee collections not affect the cardholder account For information on the usage of the amounts, fees data element, which is mandatory for fee collection messages, see B.4.4 Fee collection messages may contain multiple fees These fees may be due from the acquirer to the card issuer or from the card issuer to the acq uirer, inde penden t of ‘who sent the o lriginal message The types of fee supported by fee collection messages are denoted by the fee type code (contained within the amounts, fees data element) The list of fee type codes can be found in clause A.6 Fee collections cannot be denied or reversed However, an acquirer or a card issuer can send a subsequent fee collection message with a different X indicator (i.e C or D) associated with the amounts, fees data element A debit is a fee due to the acquirer A credit is a fee due from the acquirer is available A fee toll ection, number reconciliat ion cou nt of fee c ,011ections to provide a Fee collection messages can be used, if required, to consolidate fees for reconciliations separately from related transaction amounts 113 TOTALS partial chargeback of (4) financial advice, currency differs from reconciliation currency 1 1 D50 C 2450 D 2650 D 5125 5) 6) 7) 8) D 8925 D 3825 D 4825 D 4425 , 2500 2500 amt I400 100 25 amt fees 125 e- - amt 5ooo 1400 5ooo amt credits examples c r o e u v n#b t T I k # c h g A e amt debits LESS 6000 + 2500 t 3950 EQUALS D 4425 2500+5000+400+125 1000 full reversal of (3) including transaction fee fee collection by acquirer with mulitiple fees full chargeback of (2) by the issuer, with processing fee financial advice with transaction fee # n t h g b k # C 1) 2) 3) 4) 3ooo with transaction fees financial advice authorization v u e Amount net reconciliation is : 00 1200 5000 D1300 0500 -Cl00 C25 DlOO D50 comments I c T Reconciliation processing (Example 1) Online accumulation after each event is: 00 1420 O? 15 11 20 1422 1720 01 00 1220 2500 00 20 00 fee fee type amount 1220 5ooo amt, fecon 00 amt, txn 1100 proc code I Table B.10 - 2500 100 t-l3950 .L I 50 amt fees , 4 1 00 00 20 00 20 1220 1420 1722 1200 1420 1200 1200 1420 4509 8ooo 1000 2500 8000 amt, txn 2000 amt, recon TOTALS 1) 2) 3) 4) D 8075 D 5550 D5050 D 2150 5) 6) 7) 8) D 3050 D 5050 D 0450 D5050 - - # V r