€¦ · Web viewScope and Functionality Background This Message Definition Report covers a set of...

ISO 20022

Acquirer to Issuer Card Messages (ATICA)For evaluation by the Cards and Related Retail Financial Services SEG

Message Definition Report - Part 1

Edition: 25 February 2019

Card Payment Exchanges – Acquirer to Issuer Card messages (ATICA) Edition: 25 February 2019

Table of contents1. Introduction...................................................................................................................................... 6

1.1 Terms and definitions..................................................................................................61.2 Glossary......................................................................................................................71.3 Document Scope and Objectives................................................................................81.4 References..................................................................................................................8

2. Scope and Functionality................................................................................................................. 92.1 Background.................................................................................................................92.2 Scope..........................................................................................................................92.3 Groups of Message Definitions and Functionality.......................................................9

3. BusinessRoles and Participants..................................................................................................124. BusinessProcess Description......................................................................................................13

4.1 BusinessProcess Diagram........................................................................................13

5. Description of BusinessActivities................................................................................................175.1 Acquirer To Issuer Card Transactions......................................................................18

5.1.1 BusinessProcess – Example of Card Payment and Cash Withdrawal Process under a Dual Message implementation..................................................................................18

5.1.2 BusinessProcess – Addendum Process...................................................................205.1.3 BusinessProcess – Amendment Process.................................................................225.1.4 BusinessProcess – Retrieval and retrieval fulfillment Process..................................235.1.5 BusinessProcess – Chargeback Process.................................................................245.1.6 BusinessProcess – Inquiry Process..........................................................................245.1.7 BusinessProcess – Verification Process...................................................................255.1.8 BusinessProcess – Card management Process.......................................................26

5.2 Administrative............................................................................................................275.2.1 BusinessProcess – Error Process.............................................................................275.2.2 BusinessProcess – Batch Management Process.....................................................285.2.3 BusinessProcess – Batch Transfer Process.............................................................295.2.4 BusinessProcess – Reconciliation Process..............................................................29

5.3 Fee collection............................................................................................................305.3.1 BusinessProcess – Fee Process..............................................................................30

5.4 Card Network management......................................................................................315.4.1 BusinessProcess – Card Network Management Processes.....................................31

5.5 File management......................................................................................................355.5.1 BusinessProcess – File action Process....................................................................35

5.6 Settlement reporting collection..................................................................................365.6.1 BusinessProcess – Settlement Reporting Processes...............................................36

5.7 Fraud reporting collection..........................................................................................375.7.1 BusinessProcess – Fraud Reporting and Disposition Process.................................37

6. BusinessTransactions.................................................................................................................. 386.1 Introduction...............................................................................................................386.2 Authorisation and Financial Exchanges....................................................................39

6.2.1 Successful Authorisation...........................................................................................39

Message Definition Report – Part 1


6.2.2 Unsuccessful Authorisation.......................................................................................416.2.3 Authorisation in an Agent Stand-in Process..............................................................426.2.4 Authorisation for an estimated Amount.....................................................................436.2.5 PreAuthorisation for a maximum Amount.................................................................446.2.6 Maximum amount authorisation followed by real-time update..................................466.2.7 Maximum amount authorisation followed by real-time financial................................476.2.8 Maximum amount authorisation followed by real-time reversal................................496.2.9 Authorisation for an incremental Amount..................................................................506.2.10 Authorisation for a maximum Amount.......................................................................536.2.11 Single to Dual message conversion..........................................................................546.2.12 Bilateral Authorisation...............................................................................................556.2.13 Credit Adjustment.....................................................................................................576.2.14 Debit Adjustment.......................................................................................................586.2.15 Acquirer Capture.......................................................................................................596.2.16 Funds Transfers........................................................................................................626.2.17 Instant Posting..........................................................................................................656.2.18 Bill Payment..............................................................................................................696.2.19 Electronic Purse........................................................................................................706.2.20 Addendum Message.................................................................................................75

6.3 Reversals..................................................................................................................776.3.1 Financial reversed by an Agent................................................................................776.3.2 Authorisation reversed by an Acquirer......................................................................786.3.3 Financial reversed by an Acquirer through an Agent................................................786.3.4 Authorisation reversed through a Request by an Agent............................................80

6.4 Reconciliation............................................................................................................816.4.1 Inquire for reconciliation totals..................................................................................816.4.2 Convey reconciliation totals......................................................................................82

6.5 Network Management and Control...........................................................................836.5.1 Establishing a communication session.....................................................................836.5.2 Echo Test after an Inactivity Period..........................................................................84

6.6 Key Exchange...........................................................................................................856.6.1 Delivery of keys for a Cardholder’s card...................................................................856.6.2 Update of keys for a Cardholder’s card.....................................................................86

6.7 Error..........................................................................................................................876.7.1 Issuer initiated rejection............................................................................................876.7.2 Agent initiated Rejection with reversal......................................................................886.7.3 Agent initiated Rejection with financial advice..........................................................89

6.8 Amendment...............................................................................................................906.8.1 Amendment of Notification by an Agent....................................................................90

6.9 Batch Management...................................................................................................916.9.1 Message by message without intermediate acknowledgements..............................916.9.2 Message by message with intermediate acknowledgements...................................926.9.1 Collection of batches...............................................................................................100

6.10 Batch Transfer.........................................................................................................1026.10.1 Miscellaneous types of messages in a single batch................................................102

6.11 Chargebacks...........................................................................................................104



6.11.1 Chargeback Advice.................................................................................................1046.11.2 Chargeback Notification..........................................................................................1056.11.3 Chargeback requiring Review.................................................................................106

6.12 File Action...............................................................................................................1076.12.1 File Action Request.................................................................................................1076.12.2 File Action Advice...................................................................................................107

6.13 Retrieval..................................................................................................................1096.13.1 Retrieval of a transaction........................................................................................1096.13.2 Retrieval Status Advice...........................................................................................109

6.14 Fee Collection.........................................................................................................1116.14.1 Fee Collection Advice.............................................................................................1116.14.2 Fee Collection Notification......................................................................................112

6.15 Settlement Reporting..............................................................................................1126.16 Fraud Reporting and Disposition.............................................................................114

6.16.1 Issuer Reported Fraud............................................................................................1146.16.2 Acquirer Reported Fraud........................................................................................115

6.17 Verification..............................................................................................................1166.17.1 Verification Request................................................................................................1166.17.2 Verification Notification...........................................................................................117

6.18 Card management..................................................................................................1186.18.1 Card management..................................................................................................118

6.19 Inquiry 1196.19.1 Available balance inquiry........................................................................................1196.19.2 Requesting of fees prior to a transaction................................................................119

7. Examples...................................................................................................................................... 1218. Revision Record.......................................................................................................................... 121



Preliminary note:The Message Definition Report (MDR) is made of three parts:

MDR - Part 1 describes the contextual background required to understand the functionality of the proposed message set. Part 1 is produced by the submitting organisation that developed or maintained the message set in line with a MDR Part1 template provided by the ISO 20022 Registration Authority (RA) on www.iso20022.org

MDR – Part 2 is the detailed description of each message definition of the message set. Part 2 is produced by the RA using the model developed by the submitting organisation.

MDR – Part 3 is an extract of the ISO 20022 Business Model describing the business concepts used in the message set. Part 3 is an Excel document produced by the RA.


http://www.iso20022.org/

1. Introduction

1.1 Terms and definitionsThe following terms are reserved words defined in ISO 20022 – Part1. When used in this document, they will follow the UpperCamelCase notation.

Term Definition

AdviceMessage where the sender advises the receiver of an activity already taken or to be taken and a response is required. The result of the activity may be conveyed in a separate message exchange.

BusinessArea Business activities as defined in ISO 20022-1

BusinessProcess

Unrealized definition of the business activities undertaken by BusinessRoles within a BusinessArea whereby each BusinessProcess fulfils one type of business activity and whereby a BusinessProcess may include and extend other BusinessProcesses

BusinessRole Functional role played by a business actor in a particular BusinessProcess or BusinessTransaction

BusinessTransaction Particular solution that meets the communication requirements and the interaction requirements of a particular BusinessProcess and BusinessArea

MessageDefinition Formal description of the structure of a MessageInstance

NotificationMessage where the sender notifies the receiver of an activity already taken or to be taken and no response is required. The result of the activity may be conveyed in a separate message exchange.

Participant Involvement of a BusinessRole in a BusinessTransaction

Request Message where the sender informs the receiver that a transaction is in progress. A response is required to complete the activity

Response A response to an Advice or Request as part of the message exchange



1.2 GlossaryAcronyms

Acronym Definition

AES Advanced Encryption Standard

ASN.1 Abstract Syntax Notation 1

cain ISO 20022 Acquirer to Issuer messages (ATICA)

CAPE Card Payment Exchanges

DES Data Encryption Standard

DUKPT Derived Unique Key Per Transaction

EMV Europay, Mastercard, Visa

FIPS Federal Information Processing Standard

FTP File Transfer Protocol

ICC Integrated Circuit Card

IP Internet Protocol

ISO International Organization for Standardization

KEK Key Encryption Key

MAC Message Authentication Code

MDR Message Definition Report

MOTO Mail Order, Telephone Order

PAN Primary Account Number

PED PIN Entry Device

PIN Personal Identification Number

PKI Public Key Infrastructure

POI Point Of Interaction

POS Point Of Sale

PSP Payment Service Provider

RFID Radio Frequency Identification

RSA Rivest, Shamir, and Adleman. (Coinventors of the RSA public key encryption algorithm)

SC2 TC 68/SC2 Financial Services, Security

SHA Secure Hash Algorithm

STIP STand-In Processing

TMS Terminal Management System

UKPT Unique Key Per Transaction

UML Unified Modelling Language

XML eXtensible Mark-up Language



1.3 Document Scope and ObjectivesThis document is the first part of the ISO 20022 Message Definition Report (MDR) that describes the BusinessTransactions and underlying message set. For the sake of completeness, the document may also describe BusinessActivities that are not in the scope of the project.

This document sets:

The BusinessProcess scope (business processes addressed or impacted by the project)

The BusinessRoles involved in these BusinessProcesses

The main objectives of this document are:

To explain what BusinessProcesses and BusinessActivities these candidate MessageDefinitions have addressed

To give a high level description of BusinessProcesses and the associated BusinessRoles

To document the BusinessTransactions and their Participants (sequence diagrams)

To list the candidate MessageDefinitions

1.4 References

Document Version Date Author

ISO 20022 Business Justification – Acquirer to Issuer Card Messages (ATICA)

13 Oct. 2009 2009-10-06

ISO TC68/SC7/TG1 (now ISO TC68/SC9/TG1)

Card Payment Protocols Security1 2.0 2014 EPASOrg (now nexo)

1 Available on http://www.nexo-standards.org/



2. Scope and Functionality

2.1 BackgroundThis Message Definition Report covers a set of ISO 20022 MessageDefinitions developed by ISO TC68/SC7/TG1 (now ISO TC68/SC9/TG1) and submitted to the approval of the Cards and Related Retail Financial Services Standards Evaluation Group (SEG). These candidate messages are specifically designed to support card payment business services between an acquirer and an issuer.

.

2.2 ScopeThe messages can be used for exchanges between an acquirer and an issuer, and may also involve intermediary agents as well.

2.3 Groups of Message Definitions and FunctionalityThe following are messages exchanged between Acquirers and Issuers supporting card based financial and non-financial services

Authorisation messages AuthorisationInitiation (cain.001): The AuthorisationInitiation message is used to request

authorisation or to convey information about an authorisation.

AuthorisationResponse (cain.002): The AuthorisationResponse message is used to reply to an AuthorisationInitiation message.

Reversal messages ReversalInitiation (cain.005): The ReversalInitiation message is used to partially or completely

nullify the effects of a previous authorisation or financial transaction.

ReversalResponse (cain.006): The ReversalResponse message is used to reply to a ReversalInitiation message.

Financial messages FinancialInitiation (cain.003): The FinancialInitiation message is used to request processing of a

financial instruction or to convey information about a financial instruction.

FinancialResponse (cain.004): The FinancialResponse message is used to reply to a FinancialInitiation message.

Addendum messages AddendumInitiation (cain.025): The AddendumInitiation message is used to provide

supplemental data in addition to that which is required to complete an authorization initiation or financial initiation. The supplemental data is associated with an authorization or financial message.



AddendumResponse (cain.026): The AddendumResponse message is used to reply an AddendumInitiation message

Amendment message Amendment (cain.020): The Amendment message is used to make an amendment to a

message.

Retrieval messages RetrievalInitiation (cain.021): The RetrievalInitiation message is used to request retrieval of the

original transaction information. RetrievalResponse (cain.022): The RetrievalResponse message is used to reply to a

RetrievalInitiation message.

RetrievalFulfillmentInitiation (cain.014): The RetrievalFulfillmentInitiation is used for the actual fulfillment of transaction information.

RetrievalFulfillmentResponse (cain.015): The RetrievalFulfillmentResponse is used to reply to a RetrievalFulfillmentInitiation message.

Chargeback messages ChargeBackInitiation (cain.027): The ChargeBackInitiation message is used to fully or partially

nullify a previous financial transaction when the card issuer determines that a customer dispute exists, or that an error or a violation of rules has been committed.

ChargeBackResponse (cain.028): The ChargeBackResponse message is used to reply to a ChargeBackInitiation message.

Inquiry messages InquiryInitiation (cain.016): The InquiryInitiation message is used from point of service to request

information related to the card.

InquiryResponse (cain.017): The InquiryResponse message is used to reply to an InquiryInitiation message.

Verification messages VerificationInitiation (cain.018): The VerificationInitiation message is used to request verification

or convey the information about a verification.

VerificationResponse (cain.019): The VerificationResponse message is used to reply to a VerificationInitiation message.

Card Management messages CardManagementInitiation (cain.023): The CardManagementInitiation message is used by the

acquirer to fulfil a request initiated by the cardholder at the point of service for an operation on the card account.

CardManagementResponse (caad.024): The CardManagementResponse message is used to reply to a CardManagementInitiation message.

Error Message



Error (caad.008): The Error message is used by any party (acquirer, agent or issuer) to indicate a message error.

Batch management messages BatchManagementInitiation (caad.002): The BatchManagementInitiation message is used to

provide flow control information enabling a series of messages in batches and/or a grouping of batches to start, end, or require checkpoints during the flow.

BatchManagementResponse (caad.003): The BatchManagementResponse message is used to reply to a BatchManagementInitiation message.

Batch transfer messages BatchTransferInitiation (caad.004): The BatchTransferInitiation message is used to transfer a

series of transactions or administrative information in a single exchange.

BatchTransferResponse (caad.005): The BatchTransferResponse message is used to reply to a BatchTransferInitiation message.

Reconciliation messages ReconciliationInitiation (caad.006): The ReconciliationInitiation message is used to exchange the

totals of activities between two parties. ReconciliationResponse (caad.007): The ReconciliationResponse message is used to reply to a

ReconciliationInitiation message.

Fee Collection messages FeeCollectionInitiation (cafc.001): The FeeCollectionInitiation message is used to claim or pay

for miscellaneous service fees between two parties. FeeCollectionResponse (cafc.002): The FeeCollectionResponse message is used to reply to a

FeeCollectionInitiation message.

Network Management messages NetworkManagementInitiation (canm.001): The NetworkManagementInitiation message is used

to control the system security and the operating conditions of the network.

NetworkManagementResponse (canm.002): The NetworkManagementlResponse message is used to reply to a NetworkManagementlInitiation message.

Key Exchange messages KeyExchangeInitiation (canm.003): The KeyExchangeInitiation message is used to request or

exchange information regarding cryptographic keys.

KeyExchangeResponse (canm.004): The KeyExchangeResponse message is used to reply to a KeyExchangeInitiation message.

File Action messages FileActionInitiation (cafm.001): The FileActionInitiation message is used to inquire, add, change,

delete, or replace a file or a record.

FileActionResponse (cafm.002): The FileActionResponse message is used to reply to a FileActionInitiation message.



Settlement Report messages SettlementReportingInitiation (casr.001): A SettlementReportingInitiation message is used to

convey settlement totals.

SettlementReportingResponse (casr.002): The SettlementReportingResponse message is used to reply to a SettlementReportingInitiation message.

Fraud Reporting and Disposition messages FraudReportingInitiation (cafr.001): A FraudReportingInitiation message is used to inform about

a confirmed fraudulent transaction.

FraudReportingResponse (cafr.002): The FraudReportingResponse message is used to reply to a FraudReportingInitiation message.

FraudDispositionInitiation (cafr.003): A FraudDispositionInitiation message is used to convey the validation result of a previously reported fraudulent transaction.

FraudDispositionResponse (cafr.004): The FraudDispositionResponse message is used to reply to a FraudDispositionInitiation message.

3. BusinessRoles and ParticipantsA BusinessRole represents an entity (or a class of entities) of the real world, physical or legal, a person, a group of persons, a corporation. Examples of BusinessRoles: “Acquirer”, “Issuer”, etc.

A Participant is a functional role performed by a BusinessRole in a particular BusinessProcess or BusinessTransaction: for example the “Financial Institution”, “Processor”, “Card Scheme”.

The relationship between BusinessRoles and Participants is many-to-many. One BusinessRole can be involved as different Participants at different moments in time or at the same time: "Financial Institution", etc. Different BusinessRoles can be involved as the same Participant.

In the context of card payments, the high-level BusinessRoles and typical Participants can be represented as follows.

Participants and BusinessRoles definitionsDescription DefinitionBusinessRolesAcquirer An entity acquiring payment card transactions.



Participants and BusinessRoles definitionsDescription DefinitionIssuer An entity issuing a payment card.Agent An entity acting as an intermediary between an acquirer and an issuer ParticipantsFinancial Institution A financial or related institution acquiring card payment transactions or

issuing cards, and performing the settlement for acceptor and cardholder accounts, when relevant.

Processor An entity providing payment card processing services.Card Scheme An entity defining rules and procedures for card payment transactions.

BusinessRoles/Participants Matrix Table

BusinessRoleParticipants

Financial Institution Processor Card SchemeAcquirer X XAgent X XIssuer X X

4. BusinessProcess Description

4.1 BusinessProcess DiagramThis diagram shows the high level BusinessProcess covered by card payment business.



Acquirer to Issuer Card Transaction

Definition: The process of performing and conveying a transaction between an acquirer and issuer for a function being requested or performed at a point of service. The process starts with the acceptance of the payment instrument, involves the authorisation of the transaction, and when necessary, the transfer of financial information (capture/clearing) from the acquirer to the issuer. In some situations, it is necessary to reverse or adjust the transaction

Trigger: For original transaction, the submission of a transaction by the acquirer initiated at the point of service.

Pre-conditions: The capture of information related to the payment instrument (e.g. physical cards but also tokens, virtual card on file and other form factors) by the acquirer at the point of service and submission of the transaction request to the relevant entity.

Post-conditions: Based on the disposition of the transaction function, various processes may be performed after the completion of the transaction. Role: acquirer, agent and issuer.

Administrative Definition: Administrative processes that support the business and technical infrastructure between

financial institutions and their agents.

Trigger: The decision of the actors of the exchange to perform an administrative action or function.

Pre-conditions: Varies between the action or function that needs to be performed.

Post-conditions: Information received is recorded or the requested administrative action is performed.

Role: acquirer, agent and issuer.

Fee Collection

Definition: The process covers the range of activities required to collect or disburse fees between financial institutions and/or agents.

Trigger: The decision of the actors of the exchange to collect or disburse fees. For example, after the acquirer has performed an action on request of an issuer.

Pre-conditions: Varies by need of the fee collection or disbursement. The message indicates the reason for the fee.

Post-conditions: Adjustments are performed by the appropriate Financial Institution to their account. Instructions are sent to settle the amounts between the appropriate parties.


Card Network Management

Definition: The range of activities carried out to control the system security and operating condition of the network (as for example session, network and key management). It may be initiated by any exchanging party.



Trigger: Varies by function being performed.

Pre-conditions: Varies by function being performed.

Post-conditions: Varies by function being performed.


File Management

Definition: This process is used to inquire, add, change, delete, or replace a file or a record (e.g. report lost or stolen cards).


Pre-conditions: Data to be requested or updated is identified.

Post-conditions: Information is conveyed and/or updated, as appropriate per the function requested.


Settlement reporting

Definition: This process is used to inform about financial totals already settled or to be settled.


Pre-conditions: Settlement has occurred or needs to occur.



Fraud reporting

Definition: This process is used to report about confirmed fraud.

Trigger: Fraud information needs to be conveyed.

Pre-conditions: Fraud has been confirmed.





5. Description of BusinessActivitiesThis section presents the different BusinessActivities within each BusinessProcess. BusinessActivities of a process are described in swim lane diagrams and are referred in this document as activity diagrams. The development of activity diagrams is part of the ISO 20022 modelling process to provide a visual representation of the requirements.

The activity diagrams provide a zoom-in on the BusinessActivities taking place during each of the BusinessProcesses described in Section 4. The diagrams also show the BusinessActivities that are triggered when another BusinessActivity has a negative result.

What type of information is provided by an activity diagram?

A representation of the ‘common lifecycle’ of a BusinessProcess

A start point that shows where the lifecycle of the BusinessProcess commences and end points that show where the lifecycle may possibly end

A lozenge that means that a choice between several actions can be made

A bar that means several actions are initiated in parallel

The flow of activities between the involved Participants (parties)

BusinessActivities may result in different actions, that is, information is conveyed from one party to another party.

Both in-scope and out-of-scope activities are included, with a different level of detail. There are no information requirements for out-of-scope activities, except that they should be clearly identified in the diagram.

Activity diagrams are always accompanied with a text describing the BusinessActivities and their interactions.



5.1 Acquirer To Issuer Card Transactions

5.1.1 BusinessProcess – Example of Card Payment and Cash Withdrawal Process under a Dual Message implementation



Description of the BusinessActivities

Initiator

Process Acceptor Request : The acquirer processes an authorisation request (or a financial request) for a payment transaction or a cash withdrawal transaction. The acquirer sends an AuthorisationInitiation message to the agent, to obtain the issuer authorisation.

Acquirer

Process Acquirer Request : The agent processes the authorisation by sending an AuthorisationInitiation message to the issuer.

Agent

Perform Authorisation : The authorisation of a payment or a cash withdrawal transaction is performed by the issuer. The issuer sends the outcome of the authorisation to the agent through an AuthorisationResponse message.

Issuer

Send Response : The agent sends an AuthorisationResponse message to the acquirer either to:

- provide the outcome of the issuer authorisation received from the issuer in the AuthorisationResponse message, or

- decline the authorisation when the agent didn't receive a response from the issuer (timeout).

Agent

Process Agent Response : The acquirer sends a response to the acceptor either to:

- provide the outcome of the issuer authorisation received from the agent in the AuthorisationResponse message, or

- decline the authorisation when the acquirer didn't receive a response from the agent (timeout).

Acquirer

Process Acquirer Reversal : In case of timeout on the authorisation response from the agent, the acquirer reverses the authorisation, sending a ReversalInitiation message to the agent.

Acquirer

Process Agent Reversal : The agent reverses the authorisation sending a ReversalInitiation message to the issuer when:

- The agent receives a ReversalInitiation message from the acquirer and the transaction has not been previously reversed by the agent. The agent then acknowledges the reversal by sending a ReversalResponse message to the acquirer.

- A timeout occurs on the authorisation response from the issuer.

Agent

Perform Reversal : When the issuer receives a ReversalInitiation message from the agent, the issuer then reverses the delivered authorisation, and acknowledges the reversal by sending a ReversalResponse message to the agent.

Issuer

Process Reversal Response : When the agent or the acquirer receives a ReversalResponse message from respectively the issuer or the agent, the transaction ends without success.

AgentAcquirer

Process Acquirer Financial : If the authorisation was approved by the issuer, the acquirer performs the clearing of the transaction by sending a FinancialInitiation notification message to the agent.

Acquirer




Process Agent Financial : The acquirer sends a FinancialInitiation notification message to the agent. The agent performs the issuer clearing of the transaction by sending a FinancialInitiation notification message to the issuer.

Agent

Process Issuer Financial : The agent sends a FinancialInitiation notification message to the issuer. The issuer performs the clearing of the transaction.

Issuer

Perform Acquirer Reconciliation : The agent performs the reconciliation of the period for the acquirer. The agent notifies the reconciliation to the acquirer sending the totals of the period in a ReconciliationInitiation notification message.

Agent

Perform Issuer Reconciliation : The agent performs the reconciliation of the period for the issuer. The agent notifies the reconciliation to the issuer sending the totals of the period in a ReconciliationInitiation notification message.

Agent

Process Reconciliation : When the acquirer (or the issuer) receives the notification of the reconciliation by the agent, the acquirer (or the issuer) verifies the totals of the reconciliation period from the agent received in the ReconciliationInitiation notification message.

AcquirerIssuer

5.1.2 BusinessProcess – Addendum Process




Initiator

Initiate authorisation : The acquirer processes an authorisation request for a payment transaction. The acquirer sends an AuthorisationInitiation message to the agent, to obtain the issuer authorisation.

Acquirer

Process Acquirer Request : The agent processes the authorisation by sending an AuthorisationInitiation message to the issuer.

Agent

Perform Authorisation : The authorisation of a payment is performed by the issuer. The issuer sends the outcome of the authorisation to the agent through an AuthorisationResponse message.

Issuer

Process issuer Response : The agent sends an AuthorisationResponse message to the acquirer.

Agent

Process Agent Response : The acquirer sends a response to the acceptor.

Acquirer

Process Acquirer Financial : If the authorisation was approved by the issuer, the acquirer performs the clearing of the transaction by sending a FinancialInitiation notification message to the agent.

Acquirer

Process Agent Financial : The acquirer sends a FinancialInitiation notification message to the agent. The agent performs the issuer clearing of the transaction by sending a FinancialInitiation notification message to the issuer.

Agent

Process Issuer Financial : The agent sends a FinancialInitiation notification message to the issuer. The issuer performs the clearing of the transaction.

Issuer

Initiate addendum : The acquirer collects addendum data and sends an AddendumInitiation notification message.

Acquirer

Perform Addendum data : The agent forwards the AddendumInitiation notification message to the issuer.

Agent

Process Addendum data : When the issuer receives the AddendumInitiation notification message, the issuer processes addendum data.

Issuer



5.1.3 BusinessProcess – Amendment Process

Descriptions of the BusinessActivities

Initiator

Initiate Financial Initiation : The Acquirer sends a FinancialInitiation message to an agent.

Acquirer

Perform Amendment: The Agent detects one or several errors in the FinancialInitiation message he is in a position to correct. He corrects the errors in the message prior to forwarding an amended FinancialInitiation message to the Issuer.

Agent

Process (Amended) Financial Initiation: The issuer receives an amended FinancialInitiation from the agent which is processed as any other FinancialInitiation message.

Issuer

Advise Amendment: The agent advises the acquirer of the FinancialInitiation amended messages sent to the issuer by sending an Amendment message.

Agent

Advised Amended Financial Initiation: The acquirer is advised with the Amendment message he received from the agent that the FinancialInitiation message was amended and sent amended to the issuer after having been modified.

Acquirer



5.1.4 BusinessProcess – Retrieval and retrieval fulfillment Process


InitiatorInitiate Retrieval : The issuer initiates a retrieval notification by sending a RetrievalInitiation message to an acquirer.

Issuer

Process Retrieval Initiation : The acquirer locates the original transaction details.

Acquirer

Notify Retrieval Status : The acquirer sends a RetrievalFulfillmentInitiation message to notify the issuer about the status of the retrieval fulfillment.

Acquirer

Process Retrieval Fulfillment: The issuer processes the retrieval fulfilment after having been notified with the RetrievalFulfillmentInitiation message about the status of the Retrieval Fulfillment.

Issuer



5.1.5 BusinessProcess – Chargeback Process


InitiatorInitiate ChargeBack : The issuer initiates a chargeback by sending a ChargeBackInitiation message to an acquirer.

Issuer

Process ChargeBack : The acquirer completes and clears the transaction on his side after the chargeback and sends back a ChargeBackResponse to the issuer.

Acquirer

5.1.6 BusinessProcess – Inquiry Process


Initiator

Initiate Inquiry : The acquirer sends an InquiryRequest message to the issuer to query about some information related to a transaction.

Acquirer

Process Inquiry: The issuer processes the inquiry and sends back an InquiryResponse to the acquirer with the information requested.

Issuer



5.1.7 BusinessProcess – Verification Process


Initiator

Initiate Verification: The acquirer sends a VerificationInitiation message to request verification or authentication to an issuer.

Acquirer

Process Verification: The issuer processes the verification request and sends back a VerificationResponse to the acquirer to convey the results of the verification or the authentication.

Issuer



5.1.8 BusinessProcess – Card management Process


Initiator

Initiate Card Management: The acquirer sends a CardManagementInitiation message to the issuer to request an operation on the cardholder payment card.

Acquirer

Process Card Management: The issuer sends back a CardManagementResponse message to the acquirer with the outcome of the card management process.

Issuer



5.2 Administrative

5.2.1 BusinessProcess – Error Process


InitiatorProcess Acceptor Request : The acquirer processes an authorisation request for a payment transaction or a cash withdrawal transaction. The acquirer sends an AuthorisationInitiation message to the agent, to obtain an authorisation.

Acquirer

Process Acquirer Request : The agent processes the authorisation by processing and forwarding the AuthorisationInitiation message to the issuer.

Agent

Initiate Error : The issuer detects an error condition in the message received from the agent. It rejects the entire message by sending an Error message to the agent:

Issuer

Process Error: The agent receives an Error message from the issuer and sends an AuthorisationResponse or an Error message to the Acquirer.

Agent

Process Agent Response : The acquirer processes the response from the agent.

Acquirer

This example can apply to any type of message exchange.



5.2.2 BusinessProcess – Batch Management Process


Initiator

Initiate Batch Management: The acquirer (Originator) initiates a batch management session vis-à-vis the issuer (Destination).

Acquirer

Initiate Batch Management: The issuer (Destination) initiates a batch management session vis-à-vis the acquirer (Originator)

Issuer

Perform Batch Management: The acquirer (Originator) performs a batch management session by sending messages to the issuer (Destination)

Acquirer

Perform Batch Management: The issuer (Destination) performs a batch management session by receiving and processing messages from the acquirer (Originator)

Issuer

End Batch Management: The acquirer (Originator) ends a batch management session vis-à-vis the issuer (Destination).

Acquirer

End Batch Management: The issuer (Destination) ends a batch management session vis-à-vis the acquirer (Originator).

Issuer



5.2.3 BusinessProcess – Batch Transfer Process


InitiatorInitiate Batch Transfer : The acquirer initiates a batch transfer by sending a BatchTransferInitiation message to the agent.

Acquirer

Process Batch Transfer : The agent performs the records received and sends a BatchTransferResponse message to acknowledge the transfer.

Agent

5.2.4 BusinessProcess – Reconciliation Process


InitiatorInquire reconciliation : The originator sends a ReconciliationInitiation message to a Destination to request for totals and/or counts.

Originator

Provide reconciliation : The destination validates the request and if valid, provides the totals in a ReconciliationResponse message.

Destination



5.3 Fee collection

5.3.1 BusinessProcess – Fee Process


InitiatorInitiate Fee Collection : The acquirer initiates either a fee collection or a funds disbursement by sending a FeeCollectionInitiation message to an issuer.

Acquirer

Process Fee Collection : The issuer processes the fee collection or funds disbursement and sends a FeeCollectionResponse message to acknowledge the request.

Issuer



5.4 Card Network management

5.4.1 BusinessProcess – Card Network Management Processes




Initiator

Agent Network Management : When the agent initiates a network management process with an acquirer or an issuer, the agent then:

- Sends a NetworkManagementInitiation message to that party, waiting for the response, and

- Receives a NetworkManagementResponse message from that party.

When a party initiates a network management process with an agent, the agent then:

- Receives a NetworkManagementInitiation message from the party, waiting for the response, and

- Processes the requested network management service and sends a NetworkManagementResponse message to that party.

Agent

Issuer Network Management : When the issuer initiates a network management process with an agent, the issuer:

- Sends a NetworkManagementInitiation message to the agent, waiting for the response, and

- Receives a NetworkManagementResponse message from the agent.

When an agent initiates a network management process with an issuer, the issuer:

- Receives a NetworkManagementInitiation message from the agent, waiting for the response, and

- Processes the requested network management service and sends a NetworkManagementResponse message to the agent.

Issuer

Acquirer Network Management : When the acquirer initiates a network management process with an agent, the acquirer:

- Sends a NetworkManagementInitiation message to the agent, waiting for the response, and

- Receives a NetworkManagementResponse message from the agent.

When an agent initiates a network management process with an acquirer, the acquirer:

- Receives a NetworkManagementInitiation message from the agent, waiting for the response, and

- Processes the requested network management service and sends a NetworkManagementResponse message to the agent.

Acquirer

Key Exchange Initiation : When an acquirer or an issuer initiates a key exchange process with an agent, the acquirer or the issuer:

- Initiates the key exchange, and - Sends a KeyExchangeInitiation message to the agent, waiting for

the response.

When an agent initiates a network management process with an acquirer or an issuer, the agent:

- Initiates the key exchange, and- Sends a KeyExchangeInitiation message to that party, waiting for

the response.

AcquirerAgentIssuer




Perform Key Exchange : When an acquirer or an issuer initiates a key exchange process with an agent, the agent:

- Receives a KeyExchangeInitiation message from the relevant party,

- Validates the message and sends a Rejection message to the relevant party, if the message is invalid,

- Updates the key and sends a KeyExchangeResponse message to the relevant party.

When an agent initiates a network management process with an acquirer or an issuer, the acquirer or issuer:

- Receives a KeyExchangeInitiation message from the agent,- Validates the message and sends a Rejection message to the

agent, if the message is invalid,- Updates the key and sends a KeyExchangeResponse message to

the agent.

AcquirerAgentIssuer

Key Exchange Completion : When the acquirer or issuer initiates a key exchange process with an agent, the agent:

- Receives a Rejection message from the relevant party, if the KeyExchangeResponse message it sent was invalid,

- Otherwise the key exchange process is complete.

When an agent initiates a network management process with an acquirer or an issuer the relevant party:

- Receives a Rejection message from the agent, if the KeyExchangeResponse message it sent was invalid,

- Otherwise the key exchange process is complete.

AcquirerAgentIssuer



5.5 File management

5.5.1 BusinessProcess – File action Process


Initiator

Request Action on File: The acquirer sends a FileActionInitiation message to request the authorisation to the issuer to perform an action on file by the issuer.

Acquirer

Process Request Action on File: The issuer processes the request for action on file and sends a FileActionResponse message to inform the acquirer about the result of this process.

Issuer

Process Response Action on File: The acquirer process the response for action on file.

Acquirer

Notify Action on File: The acquirer sends a FileActionInitiation message to notify the issuer about the action on file performed on his side if positive.

Acquirer

Process Notification Action on File: The issuer is notified about the action on file performed by the acquirer.

Issuer



5.6 Settlement reporting collection

5.6.1 BusinessProcess – Settlement Reporting Processes

Descriptions of the Business Activities

Initiator

Initiate Settlement Reporting : The agent initiates a reporting of a settlement activity by sending a SettlementReportInitiation message to inform the acquirer about financial totals already settled or to be settled issued as an outcome of the clearing process

Agent

Process Settlement Reporting : The acquirer sends back a SettlementReportResponse message to the agent to acknowledge the reporting.

Acquirer

Initiate Settlement Reporting : The agent initiates a reporting of a settlement activity by sending a SettlementReportInitiation message to inform the issuer about financial totals already settled or to be settled issued as an outcome of the clearing process

Agent

Process Settlement Reporting : The issuer sends back a SettlementReportResponse message to the agent to acknowledge the reporting.

Issuer



5.7 Fraud reporting collection

5.7.1 BusinessProcess – Fraud Reporting and Disposition Process

Descriptions of the Business Activities

Initiator

Initiate Fraud Reporting : The issuer initiates a reporting of a fraudulent activity by sending a FraudReportingInitiation message to inform the agent about a confirmed fraud.

Issuer

Process Fraud Reporting : The agent sends back a FraudReportingResponse message to the issuer to acknowledge the fraud reporting.

Agent

Initiate Fraud Disposition : The agent initiates a disposition of a fraudulent activity by sending a FraudReportingInitiation message to inform the issuer.

Agent

Process Fraud Disposition : The issuer sends back a FraudDispositionResponse message to the agent to acknowledge the fraud disposition.

Issuer

The same flow can be initiated by the acquirer.



6. BusinessTransactionsThis section describes the message flows based on the activity diagrams documented above. It shows the typical exchanges of information in the context of a BusinessTransaction.

6.1 IntroductionThe following BusinessTransactions show how an acquirer, agent and issuer interact for the exchange of card messages.

These BusinessTransactions scenarios are typical without being an exhaustive list.

A card payment is supported by an authorisation process to request the approval of the BusinessTransaction.

A financial exchange is required when the issuer has to be notified of the outcome of the payment.

The financial data of the BusinessTransaction must be transferred to the issuer through a financial message for clearing.

MessageFunction codes are used in the following card payment BusinessTransactions to qualify the action taken or to be taken by a given party in the exchange of messages. Depending on the MessageFunction code received by the receiver of the message, responses or approvals may be sent back to the sender of the message.

Request: Message where the sender informs the receiver that a transaction is in progress. A response is required to complete the activity.

Advice: Message where the sender notifies the receiver of an activity that has been taken that requires a response

Notification: Notification has two use cases;

1. Message where the sender notifies the receiver of an activity taken and no response is required. 2. Message where the sender notifies the receiver of an activity to be taken. The result of the

activity may be conveyed in a separate message exchange.



6.2 Authorisation and Financial Exchanges

The below series of scenarios depicts use cases related to the authorisation and financial processes of a card transaction.

6.2.1 Successful Authorisation

The below scenarios depicts use cases of successful authorisations and financial process performed in both Dual and Single Message modes.

6.2.1.1 Authorisation (Dual Message)

In this scenario, a card payment transaction is finalised through an authorisation followed by a financial process (Dual Message mode).

1: An AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is sent by the Acquirer to the Agent to request authorisation.

2: The AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to the Issuer to request authorisation.



3: An AuthorisationResponse (MessageFunction: AuthorisationRequest) message is returned by the Issuer to inform the Agent about the successful outcome of the request; once the issuer has authorised the BusinessTransaction.

4: The AuthorisationResponse (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to inform the Acquirer about the successful outcome of the request; once the issuer has authorised the BusinessTransaction.

5: A FinancialInitiation (MessageFunction: FinancialNotification) message is sent by the Acquirer to the Agent to complete the transaction with a financial process.

6: The FinancialInitiation (Message Function: FinancialNotification) message is forwarded by the Agent to the Issuer to complete the transaction with a financial process. Reconciliation totals (amount and number) are updated on both sides.

6.2.1.2 Authorisation (Single message)

In this scenario, the authorisation and financial process are performed in a single exchange (Single Message). The Issuer authorises and performs the financial process once a financial request message has been received.

1: A FinancialInitiation (MessageFunction: FinancialRequest) message is sent by the Acquirer to the Agent to request both authorisation and financial process of the card payment transaction by the Issuer.

2: The FinancialInitiation (MessageFunction: FinancialRequest) message is forwarded by the Agent to the Issuer to request both authorisation and financial process.

3: The Issuer authorises and performs the financial process of the transaction and updates the reconciliation totals (amount and number). A FinancialResponse (MessageFunction: FinancialRequest) message is returned by the Issuer to inform the Agent about the successful outcome of the request.

4: The FinancialResponse (MessageFunction: FinancialRequest) message is forwarded by the Agent to inform the Acquirer about the successful outcome of the request. Both the Acquirer and Agent do update their own reconciliation totals (amount and number).



6.2.2 Unsuccessful AuthorisationIn this scenario, the authorisation was unsuccessful. The card payment transaction was subsequently declined.



3: An AuthorisationResponse (MessageFunction: AuthorisationRequest) message is returned by the Issuer to inform the Agent that the authorisation was unsuccessful and the transaction declined.

4: The AuthorisationResponse (MessageFunction: AuthorisationRequest) message is returned by the Agent to inform the Acquirer that the transaction was declined.



6.2.3 Authorisation in an Agent Stand-in ProcessIn this scenario, the Issuer is unavailable to authorise the transaction. The Agent is acting on his behalf (stand-in process) to authorise the transaction vis-à-vis the Acquirer. The financial process of the authorised transaction is performed through a financial notification of the Acquirer to the Issuer.

1: The Acquirer sends an AuthorisationInitiation (MessageFunction: AuthorisationRequest) message to the Agent for authorisation.

2: The Issuer is unavailable. The Agent authorises the transaction on behalf of the Issuer (stand-in process) and sends an AuthorisationResponse (MessageFunction: AuthorisationRequest) message to the Acquirer to authorise the transaction.

3: Once the Issuer has become available again, the Agent sends an AuthorisationInitiation (MessageFunction: AuthorisationAdvice) message to advise the Issuer about the authorisation provided to the Acquirer in a stand-in process.

4: The Issuer sends an AuthorisationResponse (MessageFunction: AuthorisationAdvice) message to the Agent to acknowledge the authorisation stand-in process.

5: A FinancialInitiation (MessageFunction: FinancialNotification) message is sent by the Acquirer to the Agent to initiate the financial process of the transaction

6: The FinancialInitiation (MessageFunction: FinancialNotification) message is forwarded by the Agent to the Issuer to finalise the financial process of the transaction.



6.2.4 Authorisation for an estimated Amount In this scenario, an authorisation is requested for an estimated amount.

Once the transaction has been completed, an updated authorisation is initiated for the actual - final – amount of the transaction.

A financial process completed the whole process from a financial perspective.

1: An AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is sent by the Acquirer to the Agent to request authorisation for an estimated amount.

2: The AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to the Issuer to request authorisation for an estimated amount.

3: An AuthorisationResponse (MessageFunction: AuthorisationRequest) message is returned by the Issuer to inform the Agent about the successful outcome of the request; once the issuer has approved the BusinessTransaction.

4: The AuthorisationResponse (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to inform the Acquirer about the authorisation for the requested amount.

5: The transaction is completed with the actual amount of the transaction. The Acquirer sends to the Agent an AuthorisationInitiation (MessageFunction: AuthorisationAdvice) message to advise about the updated actual amount.



6: The Agent forwards to the Issuer the AuthorisationInitiation (MessageFunction: AuthorisationAdvice) message to advise the Issuer about the updated authorised amount.

7: The Issuer returns an AuthorisationResponse (MessageFunction: AuthorisationAdvice) message to the Agent and updates the transaction amount for the authorisation with the actual updated amount.

8: The Agent returns to the Acquirer an AuthorisationResponse (MessageFunction: AuthorisationAdvice) message to advise the Acquirer about the updated authorised amount.

9: A FinancialInitiation (MessageFunction: FinancialNotification) message is sent by the Acquirer to the Agent to perform the financial process of the transaction.

10: The FinancialInitiation (MessageFunction: FinancialNotification) message is forwarded by the Agent to the Issuer to finalise the financial process of the transaction for the actual amount. The reconciliation totals (amount and number) are updated at both sides.

6.2.5 PreAuthorisation for a maximum Amount In this scenario, an authorisation is requested for a maximum amount when the actual amount of the goods is unknown. For example, at an Automated Fuel Dispenser (AFD) where the transaction is authorised prior to dispensing the fuel.

Once the transaction has been completed, a financial process is initiated online within a specified time period for the actual - final – amount of the transaction.

1: An AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is sent by the Acquirer to the Agent to request authorisation for a maximum amount.

2: The AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to the Issuer to request authorisation for this maximum amount.



3: An AuthorisationResponse (MessageFunction: AuthorisationRequest) message is returned by the Issuer to inform the Agent about the outcome of the request.

4: The AuthorisationResponse (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to inform the Acquirer about the outcome of the request.

5: Once the transaction is completed at the Point of Service, the Acquirer sends to the Agent a FinancialInitiation (MessageFunction: FinancialAdvice) message to advise the Issuer about the actual amount of the transaction.

6: The Agent forwards to the Issuer the FinancialInitiation (MessageFunction: FinancialAdvice) message to advise the Issuer about the actual amount.

7: The Issuer returns a FinancialResponse (MessageFunction: FinancialAdvice) message to the Agent, posts the actual amount, and releases the excess authorised amount.

8: The Agent returns to the Acquirer a FinancialResponse (MessageFunction: FinancialAdvice) message to advise the Acquirer about the outcome of the financial process

The reconciliation totals (amount and number) are updated at both sides.



6.2.6 Maximum amount authorisation followed by real-time updateAn authorisation is requested for a maximum or proxy amount since the actual amount of the purchase is unknown at that time. Once the transaction has been completed at the point of service, an authorisation advice is sent to the Issuer for adjusting the authorised amount on the card account. A financial exchange is subsequently initiated to complete the transaction and be posted to the card account.

One example is an Automated Fuel Dispenser (AFD) where the transaction is authorised prior to dispensing fuel. An authorisation advice is sent for the actual final amount upon completion of dispensing the fuel. A financial process is further initiated to complete the transaction.

1: An AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is sent by the Acquirer to the Agent to request authorisation for a maximum or proxy amount by the Issuer.

2: The AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to the Issuer to request authorisation for the maximum or proxy amount.

3: An AuthorisationResponse (MessageFunction: AuthorisationRequest) message is returned by the Issuer to inform the Agent about the successful outcome of the authorisation for the maximum or proxy amount.

4: The AuthorisationResponse (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to inform the Acquirer about the successful outcome of the transaction for the maximum or proxy amount



5: Once the transaction has been completed at the point of service, an AuthorisationInitiation (MessageFunction: AuthorisationAdvice) message is sent by the Acquirer to the Agent to release the “Open to Buy” with the actual amount of the transaction.

6: The AuthorisationInitiation (MessageFunction: AuthorisationAdvice message is forwarded by the Agent to the Issuer to release the “Open to Buy” with the actual amount of the transaction.

7: An AuthorisationResponse (MessageFunction: AuthorisationAdvice) message is returned by the Issuer with the actual amount of the transaction.

8: The AuthorisationResponse (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to the Acquirer with the actual amount of the transaction.

9: A FinancialInitiation (MessageFunction: FinancialNotification) message is sent by the Acquirer to the Agent to further advise the Issuer about the financial process to be initiated for the actual – final – amount of the transaction. The reconciliation totals (amount and number) are updated by both parties.

10: The FinancialInitiation (MessageFunction: FinancialNotification) message is forwarded by the Agent to the Issuer to advise him about the financial process to be initiated for the actual – final – amount of the transaction. The reconciliation totals (amount and number) are updated by both parties.

6.2.7 Maximum amount authorisation followed by real-time financialAn authorisation is requested for a maximum or proxy amount since the actual amount of the purchase is unknown at that time. Once the transaction has been completed at the point of service, a financial advice is sent to the Issuer for posting the transaction to the card account.

The excess funds authorised are released upon receiving of a financial or a time limit whichever comes first.

One example is an Automated Fuel Dispenser (AFD) where the transaction is authorised prior to dispensing fuel. A financial process is further initiated for the actual – final – amount of the transaction upon completion of dispensing the fuel.



1: An AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is sent by the Acquirer to the Agent to request authorisation for a maximum or proxy amount from the Issuer.


3: An AuthorisationResponse (MessageFunction: AuthorisationRequest) message is returned by the Issuer to inform the Agent about the successful outcome of the authorisation for the authorised amount.

4: The AuthorisationResponse (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to inform the Acquirer about the successful outcome of the transaction for the authorised amount

5: Once the transaction has been completed at the point of service, a FinancialInitiation (MessageFunction: FinancialAdvice) message is sent by the Acquirer to the Agent to further advise the Issuer about the actual amount of the transaction. The reconciliation totals (amount and number) are updated by the Agent.

6: The FinancialInitiation (MessageFunction: FinancialAdvice) message is forwarded by the Agent to the Issuer to advise about the financial process to be initiated for the actual amount. The reconciliation totals (amount and number) are updated by the Agent.

7: A FinancialResponse (MessageFunction: FinancialAdvice) message is returned by the Issuer to inform the Agent about the completion of the transaction. The reconciliation totals (amount and number) are updated by the Issuer.



8: The FinancialResponse (MessageFunction: FinancialAdvice) message is forwarded by the Agent to inform the Acquirer about the completion of the transaction. The reconciliation totals (amount and number) are updated by the Agent.

6.2.8 Maximum amount authorisation followed by real-time reversalAn authorisation is requested for a maximum amount since the actual amount of the purchase is unknown at that time. Once the transaction has been completed at the point of service, a partial reversal of the authorisation is sent to the Issuer for adjusting the authorised amount on the card account. A financial exchange is subsequently initiated to complete the transaction and be posted to the card account.

One example is an Automated Fuel Dispenser (AFD) where the transaction is authorised prior to dispensing fuel. A partial reversal of the authorisation is sent to release the excess funds previously authorised upon completion of dispensing the fuel. A financial process is further initiated to complete the transaction.

1: An AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is sent by the Acquirer to the Agent to request authorisation for a maximum or proxy amount by the Issuer.




3: An AuthorisationResponse (MessageFunction: AuthorisationRequest) message is returned by the Issuer to inform the Agent about the successful outcome of the authorisation for the authorised amount.

4: The AuthorisationResponse (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to inform the Acquirer about the successful outcome of the transaction for the authorised amount

5: Once the transaction has been completed at the point of service, a ReversalInitiation (MessageFunction: ReversalAdvice) message is sent by the Acquirer to the Agent to initiate the release of the authorised with the actual amount of the transaction.

6: The ReversalInitiation (MessageFunction: ReversalAdvice message is forwarded by the Agent to the Issuer to release the authorised amount with the actual amount of the transaction.

7: A ReversalResponse (MessageFunction: ReversalAdvice) message is returned by the Issuer with the actual amount of the transaction.

8: The ReversalResponse (MessageFunction: ReversalAdvice) message is forwarded by the Agent to the Acquirer with the actual amount of the transaction.



6.2.9 Authorisation for an incremental AmountIn this scenario, the authorisation amount requested at the time of purchase or reservation may be different from the final amount of the transaction (e.g. hotel and car rental companies).

A first authorisation is requested for an estimated amount at the time of purchase or reservation. Each time a point of service registers new purchases related to the transaction, a new authorisation is initiated for an incremental amount related to the initial authorised transaction.

Once the transaction has been completed at the point of service, a partial reversal is performed when the actual amount is less than the current authorised one (adjustment of the “Open to Buy”).

A financial process is further initiated for the actual - final – amount of the transaction.



1: An AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is sent by the Acquirer to the Agent to request authorisation for estimated amount by the Issuer.

2: The AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to the Issuer to request authorisation for the estimated amount.

3: An AuthorisationResponse (MessageFunction: AuthorisationRequest) message is returned by the Issuer to inform the Agent about the successful outcome of the authorisation for the estimated amount.

4: The AuthorisationResponse (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to inform the Acquirer about the successful outcome of the transaction for the estimated amount



5: Should the point of service needs to authorise additional amounts for the same transaction, an AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is sent by the Acquirer to the Agent to request authorisation for an incremental amount by the Issuer.

6: The AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to the Issuer to request authorisation for the incremental amount.

7: An AuthorisationResponse (MessageFunction: AuthorisationRequest) message is returned by the Issuer to inform the Agent about the successful outcome of the authorisation for the incremental amount.

8: The AuthorisationResponse (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to inform the Acquirer about the successful outcome of the transaction for the incremental amount

9: Once the transaction has been completed at the point of service and when the actual amount is less than the authorised one, a partial ReversalInitiation (MessageFunction: ReversalAdvice) message is sent by the Acquirer to the Agent to initiate the release the “Open to Buy” with the actual amount of the transaction.

10: The ReversalInitiation (MessageFunction: ReversalAdvice message is forwarded by the Agent to the Issuer to release the “Open to Buy” with the actual amount of the transaction.

11: A ReversalResponse (MessageFunction: ReversalAdvice) message is returned by the Issuer with the actual amount of the transaction.

12: The ReversalResponse (MessageFunction: ReversalAdvice) message is forwarded by the Agent to the Acquirer with the actual amount of the transaction.





6.2.10 Authorisation for a maximum AmountIn this scenario, an authorisation is requested for a maximum amount. Once the transaction has been completed, a financial process is initiated for the actual - final – amount of the transaction.

1: An AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is sent by the Acquirer to the Agent to request authorisation for a maximum amount by the Issuer.

2: The AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to the Issuer to request authorisation for this maximum amount.

3: An AuthorisationResponse (MessageFunction: AuthorisationRequest) message is returned by the Issuer to inform the Agent about the successful outcome of the authorisation for the maximum amount.

4: The AuthorisationResponse (MessageFunction: AuthorisationRequest message is forwarded by the Agent to inform the Acquirer about the successful outcome of the request.

5: The reconciliation totals (amount and number) are updated by the Acquirer. A FinancialInitiation (MessageFunction: FinancialAdvice) is sent by the Acquirer to the Agent to advise the Issuer about the actual amount of the transaction.

6: The reconciliation totals (amount and number) are updated by the Agent. The Agent returns a FinancialResponse (MessageFunction: FinancialAdvice) to the Acquirer to advise about the financial process of the transaction with the actual amount.

7: The Agent sends a FinancialInitiation (MessageFunction: FinancialAdvice) message to the Issuer to advise about the financial process of the transaction with the actual amount.



8: A FinancialResponse (MessageFunction: FinancialAdvice) message is returned by the Issuer to inform the Agent about the completion of the transaction. The reconciliation totals (amount and number) are updated by the Issuer.

6.2.11 Single to Dual message conversionIn this scenario, the Acquirer request the Agent to perform an authorisation and a financial process in a single exchange (Single Message) whilst the Agent performs vis-à-vis the Issuer an authorisation followed by a financial process of the transaction in a dual exchange (Dual Message).

1: A FinancialInitiation (MessageFunction: FinancialRequest) message is sent by the Acquirer to the Agent to request both authorisation and financial process of the transaction.

2: An AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is sent by the Agent to the Issuer to request authorisation for the transaction.

3: The Issuer authorises the transaction and returns to the Agent an AuthorisationResponse (MessageFunction: AuthorisationRequest).

4: A FinancialResponse (MessageFunction: FinancialRequest) message is returned by the Agent to inform the Acquirer about the successful outcome of the request. The Acquirer reconciliation totals (amount and number) are updated by the Agent.

5: A FinancialInitiation (MessageFunction: FinancialNotification) message is sent by the Agent to the Issuer to perform the financial process of the transaction. The reconciliation totals (amount and number) are updated on both sides (Acquirer and Issuer).



6.2.12 Bilateral AuthorisationIn this scenario, a card payment transaction is performed between an Acquirer and an Issuer without involving an Agent.

6.2.12.1 Bilateral Authorisation (Dual Message)In the present scenario, authorisation and financial process are performed as a two-step process. A financial process is following the authorisation process to complete the transaction.

1: An AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is sent by the Acquirer to the Issuer to authorise a card payment transaction

2: An AuthorisationResponse (MessageFunction: AuthorisationRequest) message is returned by the Issuer to the Acquirer to inform about the successful authorisation of the transaction.

3: A FinancialInitiation (MessageFunction: FinancialNotification) message is sent by the Acquirer to notify the Issuer about the successful financial process of the transaction.



6.2.12.2 Bilateral Authorisation (Single Message)In this scenario, authorisation and financial process are performed as a single-step process. A financial process is performed with the authorisation to complete the transaction.

1: A FinancialInitiation (MessageFunction: FinancialRequest) message is sent by the Acquirer to the Issuer to perform the authorisation and financial process of a card payment transaction

2: A FinancialResponse (MessageFunction: FinancialRequest) message is returned by the Issuer to the Acquirer to inform about the successful authorisation and financial process of the transaction.



6.2.13 Credit AdjustmentIn this scenario, a credit adjustment is initiated by an Acquirer vis-à-vis an Issuer. It typically refers to adjustments to a transaction which has been completed (e.g. reimbursement of charges incurred by the cardholder).

1: A FinancialInitiation (MessageFunction: FinancialAdvice, TransactionType: CreditAdjustment) message is sent by the Acquirer to the Issuer to advise about a credit adjustment to be performed.

2: A FinancialResponse (MessageFunction: FinancialAdvice, TransactionType: CreditAdjustement) message is returned by the Issuer to the Acquirer to inform about the acknowledgment of the credit adjustment advice.



6.2.14 Debit AdjustmentIn this scenario, a debit adjustment is initiated by an Acquirer vis-à-vis an Issuer. It typically refers to adjustments to a transaction which has been completed (e.g. additional charges after the cardholder’s departure from a lodging facility).

1: A FinancialInitiation (MessageFunction: FinancialAdvice, TransactionType: DebitAdjustment) message is sent by the Acquirer to the Issuer to advise about a debit adjustment to be performed to a transaction.

2: A FinancialResponse (MessageFunction: FinancialAdvice, TransactionType: DebitAdjustment) message is returned by the Issuer to the Acquirer to inform about the acknowledgment of the debit adjustment advice.



6.2.15 Acquirer CaptureIn this scenario, an Agent is interacting directly with an Acceptor for its card transactions acquisition process on behalf of an Acquirer. The way the Acceptor interacts with the Agent is not covered by the present protocol.

The Agent sent to the Acquirer the capture information related to the transaction to facilitate clearing and settlement processes.

6.2.15.1 Acquirer Capture (Single message)The Agent forwards the authorisation and financial information to the Issuer in a single message exchange.

The Acquirer is advised about the outcome of the process and received information in order to reconcile the payment.

1: A FinancialInitiation (MessageFunction: FinancialRequest) message is sent by the Agent to the Issuer to request authorisation and financial process of a transaction.

2: A FinancialResponse (MessageFunction: FinancialRequest) message is sent by the Issuer to the Agent to authorise and perform the financial process of the transaction.

3: A FinancialInitiation (MessageFunction: FinancialCaptureAdvice) message is sent by the Agent to inform the Acquirer about the captured transaction by the Agent on its behalf and the settlement to be performed

4: A FinancialResponse (MessageFunction: FinancialCaptureAdvice) message is sent back by the Acquirer to the Agent to acknowledge. receipt of the Advice



6.2.15.2 Acquirer Capture (Dual message)The Agent requests the Issuer to authorise the transaction originated from the Acceptor. Once the Issuer has authorised the transaction, a notification message is sent by the Agent to the Acquirer to inform the Acquirer that the transaction has been authorised by the Issuer and still needs to be financially presented.

The Acquirer notifies the Agent to proceed with the financial process of the transaction. The Agent forwards this financial process notification to the Issuer.

The Issuer is notified by the Agent to perform the financial process of the transaction.

1: An AuthorisationInitiation (MessageFunction: AuthorisationRequest) message is sent by the Agent to the Issuer to request authorisation of the transaction.

2: An AuthorisationResponse (MessageFunction: AuthorisationRequest) message is sent by the Issuer to the Agent to authorise the transaction.

3: An AuthorisationInitiation (MessageFunction: AuthorisationCaptureNotification) message is sent by the Agent to inform the Acquirer that the captured transaction has been authorised by the Issuer (but no financial process performed)

4: A FinancialInitiation (MessageFunction: FinancialNotification) message is sent by the Acquirer to the Agent to proceed with the financial process of the transaction.

5: The FinancialInitiation (MessageFunction: FinancialNotification) message is forwarded by the Agent to the Issuer to proceed with the financial process of the transaction.



6.2.15.3 Capture of a Reversal transaction An Agent requests an Issuer the reversal of a previously authorised and financial transaction (outside of the scope of this scenario). Once the Issuer has authorised the reversal of the transaction; a capture notification message of the reversal is sent by the Agent to the Acquirer to inform the Acquirer about the reversal of the transaction previously authorised by the Issuer.

The Acquirer notifies the Agent to proceed with the financial reversal of the transaction. The Agent forwards this reversal to the Issuer.

1: A ReversalInitiation (MessageFunction: ReversalRequest) message is sent by the Agent to the Issuer to request the reversal of a transaction.

2: A ReversalResponse (MessageFunction: ReversalRequest) message is sent by the Issuer to the Agent to confirm that the reversal of the transaction was authorised.

3: A ReversallnInitiation (MessageFunction: ReversalCaptureNotification) message is sent by the Agent to notify the Acquirer that the reversal of a captured transaction has been authorised by the Issuer.

4: A ReversalInitiation (MessageFunction: ReversallNotification) message is sent by the Acquirer to the Agent to proceed with the reversal of the transaction.

5: The ReversalInitiation (MessageFunction: ReversalNotification) message is forwarded by the Agent to the Issuer to proceed with the actual financial reversal of the transaction.



6.2.16 Funds Transfers

6.2.16.1 Funds Transfer between Accounts - Same Institution In this scenario, a funds transfer is carried out between two accounts (e.g. two current accounts or between a deposit account and a current account) held by the Cardholder in the same institution.

The Acquirer (any entity acting on behalf of the Cardholder as a payment facilitator) receiving the request for transfer (from an ATM, for instance), forwards the instruction through the network to reach the Issuer which makes the transfer internally.

The Acquirer is not involved in the financial transfer since the transfer takes the form of an instruction to the Issuer to perform the transfer between two accounts held by the Cardholder.

1: The Acquirer sends an AuthorisationInitiation (MessageFunction: AuthorisationRequest, TransactionType: CardholderAccountsTransfer) message to the Agent for a further forwarding of the funds transfer instruction to the Issuer.

2: The Agent forwards the AuthorisationInitiation (MessageFunction: AuthorisationRequest, TransactionType: CardholderAccountsTransfer) message to the Issuer to perform the transfer between the accounts held by the Cardholder.

3: The Issuer performs the transfer of funds internally and sends an AuthorisationResponse (MessageFunction: AuthorisationRequest, TransactionType: CardholderAccountsTransfer) message to inform the Agent that the transfer between accounts was actually performed.

4: The Agent forwards the AuthorisationResponse (MessageFunction: AuthorisationRequest, TransactionType: CardholderAccountsTransfer) message to the Acquirer to inform the Cardholder that the transfer between accounts was performed.



6.2.16.2 FundsTransfer between accounts - Different institutionsIn this scenario, a funds transfer is performed between two accounts (e.g. two current accounts or between a deposit account and a current account) held in different institutions.

This transfer is carried out through two different steps involving the Agent who may (depending on the environment) further proceeds to clearing and settlement or forward this activity to a third-party (e.g. clearing house) once the financial process of the whole transaction has been carried out. A first process is related to the authorisation of the transfer from both a debit and credit perspective.

The Debit Issuer is requested to authorise and perform the funds transfer with the debit of the account of the Cardholder (Payer). The Credit Issuer is requested to authorise and perform the funds transfer with the credit of the account of the Payee.



The Acquirer receiving the transfer request (from an ATM, for instance), initiates the authorisation to perform the funds transfer which will ultimately debit the account of the Cardholder and credit the account of the Payee.

The Agent is informed about the outcome of this authorisation process to ensure a proper bookkeeping prior to the actual clearing and settlement processes.

1: The Acquirer initiates the financial process to debit the Cardholder’s account by sending a Financialnitiation (MessageFunction: FinancialRequest, TransactionType: NonCashFunding) message to the Agent for a further forwarding to the Debit Issuer.

2: The Agent forwards the FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: NonCashFunding) message to the Debit Issuer for authorising and performing the transfer and the debit of the account of the Cardholder for the amount of the transfer.

3: The Debit Issuer authorises and performs the transfer and the debit of the Cardholder’s account and sends a FinancialResponse (MessageFunction: FinancialRequest, TransactionType: NonCashFunding) message to the Agent. The Agent is informed about the Debit Issuer authorisation to debit the Cardholder for the transfer amount.

4: The Agent forwards the FinancialResponse (MessageFunction: FinancialRequest, TransactionType: NonCashFunding) message to the Acquirer to inform it about the authorisation to debit the Cardholder’s account at the Debit Issuer.

5: The Acquirer initiates the financial process to credit the Payee’s account by sending a FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: OriginalCredit) message to the Agent for a further forwarding to the Credit Issuer.

6: The Agent forwards the FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: OriginalCredit) message to the Credit Issuer for authorising the transfer and the credit to the account of the Payee for the amount of the transfer.

7: The Credit Issuer authorises the transfer and the credit of the Payee’s account by sending a FinancialResponse (MessageFunction: FinancialRequest, TransactionType: OriginalCredit) message to the Agent. The Agent is informed about the Credit Issuer authorisation to credit the account of the Payee for the transfer amount.

8: The Agent forwards the FinancialResponse (MessageFunction: FinancialRequest, TransactionType: OriginalCredit) message to the Acquirer to inform it about the authorisation to credit the Payee’s account at the Credit Issuer.

The Agent is then in a position to effect both the clearing and the settlement of the transaction by ultimately debiting the account of the Debit Issuer and crediting the account of the Credit Issuer.



6.2.17 Instant Posting

6.2.17.1 Instant Payment Instant payment involves a payment where the promptness for the Acceptor to receive funds on his account at a POI location is key in the provision of the service. According to some regulation, instant payments may be settled (with the funds posted and made available on the account of the beneficiary) in less than 20 seconds.

Whilst there may be different ways to ensure that the funds are made available to the Acceptor instantly, the following scenario relies on an Agent to:

a) Proceed to an instant payment authorisation and financial process vis-à-vis the Issuerb) Once the authorisation has been obtained from the Issuer, ensure an optional fast clearing (e.g.

in real-time) followed by an immediate settlement of funds on both the Acquirer and the Issuer accounts.

In this scenario, authorisation and financial process are performed in a single message process.



The Acquirer initiates the instant payment vis-à-vis the Agent. The Agent ensures the proper authorisation and financial process by forwarding the request to the Issuer.

1: The Acquirer initiates the instant payment by sending a FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: GoodsAndServicesPull, AdditionalService: InstantPayment) message to the Agent to enable it to perform the authorisation and financial process vis-à-vis the Issuer.

2: The Agent forwards the FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: GoodsAndServicesPull, AdditionalService: InstantPayment) message to the Issuer for authorising the instant payment and proceeding to the financial process of the transaction.

3: The Issuer authorises the payment and proceeds with the financial process by sending a FinancialResponse (MessageFunction: FinancialRequest, TransactionType: GoodsAndServicesPull, AdditionalService: InstantPayment) message to the Agent. The Agent is informed about the Issuer authorisation to perform the instant payment and the financial process of the transaction.

4: The Agent sends a FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: GoodsAndServicesPull, AdditionalService: InstantPayment) message to the Acquirer informing him that the instant payment was authorised and the financial process completed.

The Acquirer credits the account of the Acceptor immediately prior to receiving the funds from the Agent to comply with the quality of service of an Instant Payment and/or any potential regulation.



6.2.17.2 Instant Funds TransferInstant transfer involves a funds transfer between two accounts (usually an account held by the Cardholder in his bank and the account of the Payee held in another bank) where the promptness for the Payee’s to receive funds on his account is key for the provision of the Instant Funds Transfer service.

According to some regulation, instant funds transfers may be settled (with the funds posted and made available on the account of the Payee) in less than 20 seconds.

Whilst there may be different ways to ensure that the funds are made available to the Payee instantly, the following scenario relies on the Agent to:

a) Proceed to an authorisation process on both debit (Debit Issuer) and credit (Credit Issuer) sidesb) Once the authorisation has been obtained from both parties, ensure an optional fast clearing

(e.g. in real-time) followed by an immediate settlement of funds for both Payer’s and Credit Issuers.

To meet the obligation to make the funds available instantly, the Credit Issuer may decide to post the funds on the Payee’s account immediately after the authorisation of the Debit Issuer to accept the transfer and the debit of the Payer’s account has been obtained; and this without having to wait for receiving the funds resulting from the actual settlement made (usually) by the Agent (depending on schemes rules and regulation).

The following scenario depicts a situation where authorisation and financial process is performed in a single message exchange between parties.



The Acquirer receiving the transfer request (from a mobile phone, for instance), initiates the instant transfer process vis-à-vis the Agent. To this extent, he provides all information required to debit the account of the Cardholder and credit the account of the Payee. He also ensures that the information complying with AML regulation is properly populated for both the Cardholder (Payer) and the Payee.

The Agent is in charge of ensuring the proper authorisation process (on both debit and credit sides) prior to ensuring the actual instant clearing (optional) and settlement processes.

1: The Acquirer initiates the instant funds transfer by sending a FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: NonCashFunding, AdditionalService: InstantTransfer) message to the Agent.

2: The Agent forwards the FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: NonCashFunding, AdditionalService: InstantTransfer) message to the Debit Issuer for authorising the instant funds transfer and ensuring the final process of the transaction.

3: The Debit Issuer authorises the transfer and the debit of the Payer’s account and sends a FinancialResponse (MessageFunction: FinancialRequest, TransactionType: NonCashFunding, AdditionalService: InstantTransfer) message to the Agent.

4: The Agent sends a FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: NonCashFunding, AdditionalService: InstantTransfer) message to the Acquirer advising him about the Cardholder’s account to be further debited.

5: The Acquirer initiates the authorisation and financial processes to ultimately credit the Payee’s account by sending a FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: OriginalCredit, AdditionalService: InstantTransfer) message to the Agent for a further forwarding to the Credit Issuer.

6: The Agent forwards the FinancialInitiation (MessageFunction:FinancialRequest, TransactionType: OriginalCredit, AdditionalService: InstantTransfer) message to the Credit Issuer to authorise the transfer and advise crediting the account of the Payee for the amount of the transfer.

7: The Credit Issuer authorises the transfer and performs the financial process of the transaction. It sends a FinancialResponse (MessageFunction: FinancialRequest, TransactionType: OriginalCredit, AdditionalService: InstantTransfer) message to the Agent. The Agent is informed about the Credit Issuer authorisation to perform the instant funds transfer and the financial process of the transaction

8: The Agent forwards the FinancialResponse (MessageFunction: FinancialRequest, TransactionType: OriginalCredit, AdditionalService: InstantTransfer) message to the Acquirer to inform him about the Payee’s account to be further credited.



6.2.18 Bill Payment

6.2.18.1 Customer-initiated bill paymentA customer may initiate an electronic credit payment through his smartphone by scanning a QR code or by transferring any purchase-related information to his bank (usually from an electronic wallet).

In this type of scenario, the Originator (Issuer) is initiating the payment on behalf of its customer.

The Originator verifies the availability of funds and debits the account of its customer. It then sends the transaction to the Agent to further forward it to the Destination (Acquirer). The Destination (Acquirer) acknowledges the payment to the Agent and credits the account of the Merchant. It then informs the merchant that a payment has been received and his account credited for the amount of the payment.

The Agent forwards the response to the Originator to inform him that the payment was accepted and the merchant credited for the amount of the payment. The Originator informs the customer about the payment made to the merchant.

1: The Originator verifies the availability of funds of its customer and sends a FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: CustomerInitiatedBillPayment) message to the Agent for a further forwarding to the Destination.

2: The Agent forwards the FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: CustomerInitiatedBillPayment) message to the Destination to verify that the payment is accepted.

3: The Destination accepts the payment and credits the account of the merchant. It sends a FinancialResponse (MessageFunction: FinancialRequest, TransactionType: CustomerInitiatedBillPayment) message to inform the Agent that the payment was accepted and the account of the merchant credited. The Destination informs the merchant that his account was credited for the amount of the transaction.

4: The Agent forwards the FinancialResponse (MessageFunction: FinancialRequest, TransactionType: CustomerInitiatedBillPayment) message to the Originator to further inform the customer that the payment was actually performed.



6.2.19 Electronic Purse

6.2.19.1 Electronic Purse Load and Unload – Same InstitutionIn this scenario, an electronic purse is loaded or unloaded with funds debited or credited on the account of the Cardholder in the same financial institution.

The Acquirer receives the load or unload request (from an ATM, for instance), transfers the instruction throughout the network to reach the Issuer who will actually make the transfer internally from an account to the electronic purse (load) or from an electronic purse to an account (unload).

Both the Acquirer and Agent are not involved in the financial aspects of the transaction since the transfer takes the form of a simple instruction to the Issuer to perform the transfer between an electronic purse and an account held by the Cardholder in the same financial institution.

6.2.19.1.1 Electronic Purse Load (linked load)The Issuer is requested to authorise the purse transfer by debiting the account of the Cardholder and loading his electronic purse.

1: The Acquirer sends an AuthorisationInitiation (MessageFunction: AuthorisationRequest, TransactionType: PurseLinkedLoad) message to the Agent for a further forwarding of the card purse load instruction to the Issuer.

2: The Agent forwards the AuthorisationInitiation (MessageFunction: AuthorisationRequest, TransactionType: PurseLinkedLoad) message to the Issuer to authorise the debit of the account and the loading of the electronic purse.

3: The Issuer authorises the electronic purse to be loaded and sends an AuthorisationResponse (MessageFunction: AuthorisationRequest, TransactionType: PurseLinkedLoad) message to the Agent to further forward it the Acquirer.

4: The Agent forwards the AuthorisationResponse (MessageFunction: AuthorisationRequest, TransactionType: PurseLinkedLoad) message to the Acquirer to inform it that the purse load was performed.

In a card purse load process, the PAN of payment card used to debit the account is populated under ‘PAN’ whilst the PAN of the electronic purse is populated under AccountTo.



6.2.19.1.2 Electronic Purse Unload (linked unload)The Issuer is requested to authorise a purse unload of the Cardholder’s card purse by the credit of his account.

1: The Acquirer sends an AuthorisationInitiation (MessageFunction: AuthorisationRequest, TransactionType: PurseLinkedUnload) message to the Agent for a further forwarding of the card purse unload instruction to the Issuer.

2: The Agent forwards the AuthorisationInitiation (MessageFunction: AuthorisationRequest, TransactionType: PurseLinkedUnload) message to the Issuer to authorise the unloading of the card purse and the credit of the cardholder’s account.

3: The Issuer authorises the electronic purse to be unloaded, proceeds to the unload of the electronic purse and credits the cardholder’s account. It sends an AuthorisationResponse (MessageFunction: AuthorisationRequest, TransactionType: PurseLinkedUnload) message to the Agent to further forward it the Acquirer.

4: The Agent forwards the AuthorisationResponse (MessageFunction: AuthorisationRequest, TransactionType: PurseLinkedUnload) message to the Acquirer to inform him that the purse unload was performed with the credit of the Cardholder’s account.

In a card purse unload process; the PAN of payment card used to credit the account is populated under ‘PAN’; whilst the PAN of the electronic purse to be unloaded is populated under AccountFrom.



6.2.19.2 Electronic Purse Load and Unload – Different InstitutionsIn this scenario, an electronic purse load or unload is carried out between an electronic purse held in one financial institution and an account held in a different financial institution.

This transfer is carried out through two different steps involving the Agent who may (depending on the environment) further proceed to an internal clearing and settlement of the transaction or forward this activity to a third-party (e.g. clearing house) once the financial process of the whole transaction has been carried out. Both processes (authorisation and financial processes) need to be linked (same identifier of transaction, for instance) to ensure consistency throughout the whole transaction.

A first process is related to the authorisation of the transfer from both a debit and credit perspective.

This transfer is carried out through the process described below.

6.2.19.2.1 Electronic Purse Load (unlinked load)The Debit Issuer is requested to authorise and perform the purse load by the debit of the account of the Cardholder. The Credit Issuer is requested to authorise and perform the load of the electronic purse.



1: The Acquirer initiates both the authorisation and financial process to debit the Cardholder’s account by sending a FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: PurseLoadPull) message to the Agent for a further forwarding to the Debit Issuer.

2: The Agent forwards the Financialnitiation (MessageFunction: FinancialRequest, TransactionType: PurseLoadPull) message to the Debit Issuer to request authorising the transaction and debiting the account of the Cardholder for the amount of the transfer.

3: The Debit Issuer returns a FinancialResponse (MessageFunction: FinancialRequest, TransactionType: PurseLoadPull) message to the Agent. The Agent is advised to debit the Debit Issuer account for the transfer amount.

4: The Agent returns a FinancialResponse (MessageFunction: FinancialRequest, TransactionType: PurseLoadPull) message to the Acquirer to advise him about the Cardholder’s account to be further debited.

5: The Acquirer initiates both the authorisation and the financial process to load the electronic purse by sending a FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: PurseLoadPush) message to the Agent for a further forwarding to the Credit Issuer.

6: The Agent forwards the FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: PurseLoadPush) message to the Credit Issuer to advise loading the electronic purse for the transfer amount.

7: The Credit Issuer returns a FinancialResponse (MessageFunction: FinancialRequest, TransactionType: PurseLoadPush) message to the Agent. The Agent is advised to credit the Debit Issuer account for the amount of the electronic purse load.

8: The Agent forwards the FinancialResponse (MessageFunction: FinancialRequest, TransactionType: PurseLoadPush) message to the Acquirer to advise him about the electronic purse held at the Credit Issuer to be further loaded for the transfer amount.


In the authorisation and financial processes with the Debit Issuer, the PAN of payment card used to debit the account is populated under ‘PAN’.

In the authorisation and financial processes with the Credit Issuer, the PAN of the electronic purse used for loading is populated under ‘PAN’



6.2.19.2.2 Electronic Purse Unload (unlinked unload)The Debit Issuer is requested to authorise an electronic purse unload.

The Credit Issuer is requested to authorise the credit transfer on the Cardholder’s account.

1: The Acquirer initiates the authorisation and financial processes to unload the electronic purse by sending a FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: PurseUnloadPull) message to the Agent for a further forwarding to the Debit Issuer.

2: The Agent forwards the Financialnitiation (MessageFunction: FinancialRequest, TransactionType: PurseUnloadPull) message to the Debit Issuer to advise unloading the electronic purse for the amount of the transfer.

3: The Debit Issuer returns a FinancialResponse (MessageFunction: FinancialRequest, TransactionType: PurseUnloadPull) message to the Agent. The Agent is requested to debit the Debit Issuer account for the transfer amount.

4: The Agent returns a FinancialResponse (MessageFunction: FinancialRequest, TransactionType: PurseUnloadPull) message to the Acquirer to advise him about the electronic purse to be unloaded.

5: The Acquirer initiates the authorisation and financial processes to credit the account of the Cardholder by sending a FinancialInitiation (MessageFunction: FinancialRequest,



TransactionType: PurseUnloadedPush) message to the Agent for a further forwarding to the Credit Issuer.

6: The Agent forwards the FinancialInitiation (MessageFunction: FinancialRequest, TransactionType: PurseUnloadedPush) message to the Credit Issuer to advise crediting the account of the Cardholder for the transfer amount.

7: The Credit Issuer returns a FinancialResponse (MessageFunction: FinancialRequest, TransactionType: PurseUnloadedPush) message to the Agent. The Agent is advised to credit the Credit Issuer account for the amount of the transfer.

8: The Agent forwards the FinancialResponse (MessageFunction: FinancialRequest, TransactionType: PurseUnloadedPush) message to the Acquirer to advise him about the account of the Cardholder to be credited for the amount of the transfer.


In the authorisation and financial processes with the Debit Issuer, the PAN of the electronic purse to be unloaded is populated under ‘PAN’.

In the authorisation and financial processes with the Credit Issuer, the PAN of payment card used for crediting the account of the Cardholder is populated under ‘PAN’.

6.2.20 Addendum Message

Addendum message is used to provide supplemental data in addition to that which is required to complete an authorization initiation or financial initiation.





3: An AuthorisationResponse (MessageFunction: AuthorisationRequest) message is returned by the Issuer to inform the Agent about the outcome of the request.

4: The AuthorisationResponse (MessageFunction: AuthorisationRequest) message is forwarded by the Agent to inform the Acquirer about the outcome of the request.

5: A FinancialInitiation (MessageFunction: FinancialNotification) message is sent by the Acquirer to the Agent to complete the transaction with a financial process.

6: The FinancialInitiation (Message Function: FinancialNotification) message is forwarded by the Agent to the Issuer to complete the transaction with a financial process. Reconciliation totals (amount and number) are updated on both sides.

7: The Acquirer collects addendum data and sends AddendumInitiation (MessageFunction: AddendumNotification) message to the Agent.

8: The Agent forwards the AddendumInitiation (MessageFunction: AddendumNotification) message to the Issuer.



6.3 ReversalsA reversal is the partial or complete nullification of the effects of a previous authorisation, financial process, or financial accumulation process that cannot be processed as instructed, i.e. is undeliverable, cancelled or the acquirer times out waiting for a response.

6.3.1 Financial reversed by an Agent In this scenario, the Acquirer is unaware whether the transaction was authorised with a financial process by the Issuer since the Agent didn’t receive a response to its request after a timeout. After informing the Acquirer that the transaction was declined for technical reasons, the Agent initiates a reversal of the financial transaction to the Issuer.

The Issuer acknowledges the reversal of the transaction vis-à-vis the Agent.

1: The Acquirer sends a FinancialInitiation (MessageFunction: FinancialRequest) message to the Agent for an authorisation and financial process of the card payment transaction by the Issuer.

2: The Agent forwards the FinancialInitiation (MessageFunction: FinancialRequest) message to the Issuer for an authorisation and financial process (Single Message). The Issuer authorises the transaction and performed the financial process, updates the reconciliation totals and returns a FinancialResponse (MessageFunction: FinancialRequest) message to inform the Acquirer about the success of the request.

3: After a timeout on the response, the Agent sends a FinancialResponse (MessageFunction: FinancialRequest) to the Acquirer informing him that the transaction has been declined for technical reasons.

4: The Agent initiates the reversal of the transaction by sending a ReversalInitiation (MessageFunction: ReversalAdvice) advising the Issuer about the reversal of both the authorisation and financial process of the transaction.

5: The Issuer returns a ReversalResponse (MessageFunction: ReversalAdvice) message to the Agent to acknowledge the successful reversal of the transaction.



6.3.2 Authorisation reversed by an AcquirerIn this scenario, the Acquirer is unaware whether the transaction was authorised by the Issuer since the Acquirer didn’t receive a response from the Issuer to its request for authorisation after a timeout. The Acquirer initiates a reversal advice to reverse the authorisation vis-à-vis the Issuer.

1: The Acquirer sends an AuthorisationInitiation (MessageFunction: AuthorisationRequest) message to the Issuer for authorisation. Due to a communication error, no AuthorisationResponse is received by the Acquirer.

2: After timeout, the Acquirer sends a ReversalInitiation (MessageFunction: ReversalAdvice) message to advise the Issuer to reverse the authorisation.

3: A ReversalResponse (MessageFunction: ReversalAdvice) message is returned to the Acquirer to advise that the authorisation was reversed.

6.3.3 Financial reversed by an Acquirer through an AgentIn this scenario, the Acquirer is unaware whether the transaction was approved by the Issuer since the Acquirer didn’t receive a response from the Agent to its request for authorisation and financial process (Single Message) after a timeout. The Acquirer initiates a reversal advice to reverse the transaction vis-à-vis the Issuer.

The Agent acknowledges the reversal advice of the transaction and initiates a reversal to the Issuer.



1: The Acquirer sends a FinancialInitiation (MessageFunction: FinancialRequest) to the Agent for authorisation and financial process by the Issuer (single message).

2: The Agent forwards the FinancialInitiation (MessageFunction: FinancialRequest) to the Issuer for authorisation and financial process.

3: The Issuer authorises the transaction, updates the reconciliation totals and sends a FinancialResponse (MessageFunction: FinancialRequest) to inform the Agent about the success of the request. The Agent updates the reconciliation totals and fails to forward the FinancialResponse (MessageFunction: FinancialRequest) to the Acquirer.

4: After a timeout, the Acquirer sends to the Agent a ReversalInitiation (MessageFunction: ReversalAdvice) to initiate the reversal.

5: The Agent updates the acquirer reconciliation totals and returns to the Acquirer a ReversalResponse (MessageFunction: ReversalAdvice) to inform about the success of the reversal.

6: The Agent initiates the reversal of the transaction by sending a ReversalInitiation (MessageFunction: ReversalAdvice) request the Issuer to reverse the transaction.

7: The Issuer reverses the transaction, updates the reconciliation totals and sends back a ReversalResponse (MessageFunction: ReversalAdvice) to the agent to acknowledge the successful reversal of the transaction. The agent updates the issuer reconciliation totals.



6.3.4 Authorisation reversed through a Request by an Agent In this scenario, an authorisation was performed successfully, but the transaction was interrupted by the Acquirer after receiving the authorisation from the Issuer through the Agent. The Acquirer initiates a reversal through a reversal request exchange of messages to the Agent. The Agent forwards the reversal request message to the Issuer which approves the reversal. The Agent forwards the response of the Issuer to the Acquirer.

1: The Acquirer sends an AuthorisationInitiation (MessageFunction: FinancialNotification) message to the Agent for authorisation by the Issuer.

2: The Agent forwards the AuthorisationInitiation (MessageFunction: AuthorisationRequest) message to the Issuer for authorisation.

3: An AuthorisationResponse (MessageFunction: AuthorisationRequest) message is returned by the Issuer to inform the Agent about the successful outcome of the request.

4: The Agent returns an AuthorisationResponse (MessageFunction: FinancialNotification) message to the Acquirer authorising the transaction.

5: The transaction is interrupted. The Acquirer initiates a reversal of the authorisation by sending a ReversalInitiation (MessageFunction: ReversalRequest) message to the Agent to request the reversal of the authorisation.

6: A ReversalInitiation (MessageFunction: ReversalRequest) message is forwarded by the Agent to the Issuer to perform the reversal of the authorisation.

7: A ReversalResponse (MessageFunction: ReversalRequest) message is returned by the Issuer to the Agent to confirm that the transaction is reversed.

8: The Agent forwards the ReversalResponse (MessageFunction: ReversalRequest) message to the Acquirer to confirm the successful reversal of the transaction.



6.4 ReconciliationReconciliation is the exchange between two interchanging parties (Acquirer, Issuer or Agent) of totals and/or counts of messages within a specific session. Any of those parties can initiate a reconciliation.

6.4.1 Inquire for reconciliation totalsIn the present scenario, an Originator is requesting a Destination to provide totals and/or counts of financial messages exchanged within a period. The exchange of financial messages appears in the form of grey arrows in the below diagram to indicate that, whilst they are part of the period leading ultimately to reconciliation, they are not part of the reconciliation exchange as such. Any type of message dealing with totals and/or counts can lead to a reconciliation (e.g. Reversals, Chargebacks, FeeCollections, Authorisations, etc.).

1 to n+1: An Originator exchanges one or more financial messages with the Destination within a period.

n+2: At the end of the period, the Originator sends a ReconciliationInitiation (MessageFunction: ReconciliationRequest) message to the Destination to request the Destination’s totals and/or counts.

n+3: The Destination validates the request message. If the request is valid, it returns a ReconciliationResponse (MessageFunction: ReconciliationRequest) message to the Originator with its totals and/or counts.



6.4.2 Convey reconciliation totalsIn the present scenario, an Originator provides to a Destination the totals and/or counts of financial messages exchanged within a reconciliation period. The Destination acknowledges the receipt of the message. The response message may contain the Destination’s reconciliation totals in case of an out-of-balance condition.

The exchange of financial messages appears in the form of grey arrows in the below diagram to indicate that, whilst they are part of the period leading ultimately to reconciliation, they are not part of the reconciliation exchange as such. Any type of message dealing with totals and/or counts can lead to a reconciliation (e.g. Reversals, Chargebacks, FeeCollections, Authorisations, etc.).

1 to n+1: An Originator exchanges one or more financial messages with the Destination within a period.

n+2: At the end of the reconciliation period, the Originator sends a ReconciliationInitiation (MessageFunction: ReconciliationAdvice) message to the Destination to convey the Originator’s totals.

n+3: The Destination acknowledges the message and sends a ReconciliationResponse (MessageFunction: ReconciliationAdvice) to the Originator. The response message may contain the Destination’s reconciliation totals in case of an out-of-balance condition.



6.5 Network Management and ControlNetwork management and control is the range of activities carried out to control the system security and operating condition of the interchange network. It may be initiated by any interchanging party (Acquirer, Agent or Issuer).

6.5.1 Establishing a communication sessionIn this scenario, an Originator is initiating a communication session (sign-on) to a Destination. At the end of the communication session, the Originator closes the communication session (sign-off) with the Destination. The Destination may allow different communication sessions to be alive at the same time for different Originators.

1: A NetworkManagementInitiation (MessageFunction: NetworkManagementRequest, NetworkManagementType: SignOn) message is sent by an Originator to a Destination to initiate a communication session at the application level.

2: The Destination opens the communication session at application level (sign-on) and returns a NetworkManagementResponse (MessageFunction: NetworkManagementRequest, NetworkManagementType: SignOn) message to the Originator to confirm the sign-on process.

3: At the end of the communication session, a NetworkManagementInitiation (MessageFunction: NetworkManagementRequest, NetworkManagementType: SignOff) message is sent by the Originator to the Destination to terminate the communication session at the application level.

4: The Destination closes the communication session at application level for the Originator and returns a NetworkManagementResponse (MessageFunction: NetworkManagementRequest, NetworkManagementType: SignOff) to the Originator.



6.5.2 Echo Test after an Inactivity PeriodIn this scenario, an inactivity period is following an activity one with several exchanges of messages between an Originator and a Destination (financial process messages, for instance). In order for the Originator to ensure the availability of the Destination for new exchanges of messages, the Originator is sending a test for availability message to the Destination. The Destination returns a response message to this request which confirms its availability.

1: Prior to a request for availability, an Originator notifies the Destination about the financial process of a transaction by sending a FinancialInitiation (MessageFunction: FinancialNotification) message to the Destination (as for a last exchange of messages, for instance).

2: After an inactivity period without any exchange of messages, the Originator intends to test the availability of the Destination application by sending a NetworkManagementInitiation (MessageFunction: NetworkManagementRequest, NetworkManagementType: EchoTest,) to the Destination.

3: After verifying the availability of the application, the Destination returns a NetworkManagementResponse (MessageFunction: NetworkManagementRequest, NetworkManagementType: EchoTest) to the Originator.



6.6 Key ExchangeKey exchange is the activity of requesting or updating cryptographic keys. The initiation of a key exchange is usually an Issuer or an Agent acting on behalf of an Issuer. The destination of a key exchange process is usually an Acquirer or entity acting on its behalf.

6.6.1 Delivery of keys for a Cardholder’s cardIn this scenario, a delivery of keys is performed by an Issuer (Originator) to an Acquirer (Destination) for a Cardholder’s card.

This activity is made of three different phases: 1) Initiation of delivery of keys, 2) Verification of keys and 3) Implementation of keys in the card.

1: The Originator initiates the delivery of keys by sending security related control information through a KeyExchangeInitiation (MessageFunction: KeyExchangeAdvice, KeyExchangeType: DeliverKey) message containing he generated keys to a Destination.

2: The Destination updates the keys and returns a KeyExchangeResponse (MessageFunction: KeyExchangeAdvice, KeyExchangeType : DeliverKey) message to the Originator to confirm the delivery of the keys.

3: The Originator validates the key exchange by sending a KeyExchangeInitiation (MessageFunction: KeyExchangeRequest, KeyExchangeType : KeyVerification) message to the Destination with the keys to be verified.

4: The Destination computes the values to validate the keys update and returns to the Originator a KeyExchangeResponse (MessageFunction: KeyExchangeRequest, KeyExchangeType : KeyVerification) message to confirm the validity of the keys.

The Destination is in a position to proceed with the installation of the keys in the Cardholder’s card.



6.6.2 Update of keys for a Cardholder’s card

In this scenario, an update of keys is initiated by an Issuer (Originator) to an Acquirer (Destination) in order to update cryptographic keys of a Cardholder’s card.

This activity is made of three different phases: 1) Initiation of keys update, 2) Verification of keys and 3) Implementation of updated keys in the card.

1: The Originator initiate the update of keys by sending a KeyExchangeInitiation (MessageFunction: KeyExchangeAdvice, KeyExchangeType: KeyChange) message containing the new generated keys to an Destination.

2: The Destination updates the key and returns a KeyExchangeResponse (MessageFunction: KeyExchangeAdvice, KeyExchangeType: KeyChange) message to the Originator to confirm the update.

3: The Originator validates the key exchange by sending a KeyExchangeInitiation (MessageFunction: KeyExchangeRequest, KeyExchangeType: KeyVerification) message to the Destination requesting a key validation.

4: The Destination computes the values to validate the keys update and returns to the Originator a KeyExchangeResponse (MessageFunction: KeyExchangeRequest, KeyExchangeType: KeyVerification) message to confirm the validity of the keys.

The Destination is in a position to proceed with the update of the keys in the Cardholder’s card.



6.7 ErrorAn error message is sent when a party detects an error condition in the message received from another party so that it leads to the rejection of the whole message. It may be initiated by any interchanging party (Acquirer, Agent or Issuer).

6.7.1 Issuer initiated rejectionIn this scenario, a request for authorisation message is sent by an Acquirer, forwarded by an Agent to an Issuer and rejected ultimately by the Issuer.

1: An AuthorisationInitiation (MessageFunction: FinancialNotification) message is sent by the Acquirer to the Agent to request authorisation.


3: The Issuer cannot process the received message. The issuer returns an Error (MessageFunction: RejectNotification) message to notify the Agent.

4: An AuthorisationResponse (MessageFunction: AuthorisationRequest) is sent by the Agent to the acquirer to respond to the authorisation request.



6.7.2 Agent initiated Rejection with reversalIn this scenario, a request for a financial process message is sent by an Acquirer and then forwarded by an Agent to an Issuer. The Agent receives a financial response message from the Issuer but considered it as an invalid one and rejects it. The Acquirer is informed that the transaction was declined for technical reasons. Being unaware whether the transaction was actually authorised and the financial process performed by the Issuer, the Agent initiates a reversal after having rejected the message.

1: An Acquirer sends a FinancialInitiation (MessageFunction: FinancialRequest) message to the Agent for authorisation and financial process.

2: The Agent forwards the FinancialInitiation (MessageFunction: FinancialRequest) message to the Issuer for authorisation and financial process.

3: The Issuer approves the authorisation, updates the reconciliation totals and returns a FinancialResponse (MessageFunction: FinancialRequest message to the Agent to inform the Acquirer about the success of the request.

4: The Agent cannot process the received message. The agent returns an Error (MessageFunction: RejectNotification) message to the issuer.

5: The Agent returns a FinancialResponse (MessageFunction: FinancialRequest) message to the Acquirer to inform that the transaction has been declined.

6: The Agent initiates the reversal of the transaction and sends a ReversalInitiation (MessageFunction: ReversalAdvice) message to request the Issuer to reverse the transaction.

7: The Issuer returns a ReversalResponse (MessageFunction: ReversalAdvice) message to the Agent to acknowledge the advice message received.



6.7.3 Agent initiated Rejection with financial advice

In this scenario, a request for a financial process message is sent by an Acquirer and then forwarded by an Agent to an Issuer. The Agent receives a financial response message from the Issuer but considered it as an invalid one and rejects it. The Acquirer is informed that the transaction is approved or declined. The Agent initiates a financial advice message after having approved or rejected the message to inform the issuer of the transaction disposition sent to the acquirer.

1: An Acquirer sends a FinancialInitiation (MessageFunction: FinancialRequest) message to the Agent for authorisation and financial process.

2: The Agent forwards the FinancialInitiation (MessageFunction: FinancialRequest) message to the Issuer for authorisation and financial process.

3: The Issuer approves the authorisation, updates the reconciliation totals and returns a FinancialResponse (MessageFunction: FinancialRequest message to the Agent to inform the Acquirer about the success of the request.

4: The Agent cannot process the received message. The agent returns an Error (MessageFunction: RejectNotification) message to the issuer.

5: The Agent returns a FinancialResponse (MessageFunction: FinancialRequest) message to the Acquirer to inform that the transaction has been declined.

6: The Agent sends a FinancialInitiation (MessageFunction: FinancialAdvice) message to advise the Issuer of the action that was taken on the issuer’s behalf.

7: The issuer determines if an action needs to be taken on the cardholder’s account. This may occur should there be a discrepancy between the issuer’s previous decision and the action taken by the agent. The Issuer returns a FinancialResponse (MessageFunction: FinancialAdvice) message to the Agent.



6.8 AmendmentAn amendment is a message sent when a party detects one or more minor errors in the message received from another party and considers that he is in a position to correct it before processing and forwarding it further to its ultimate receiver. The original sender of the message is informed that its message was corrected and amended.

6.8.1 Amendment of Notification by an AgentIn this scenario, a FinancialInitiation (MessageFunction: FinancialNotification) message is sent by an Acquirer to an Agent. The Agent detects an error which he is in a position to correct before forwarding it to the Issuer. The Agent forwards the amended (corrected) version to the Issuer and informs the Acquirer accordingly.

1: A FinancialInitiation (MessageFunction: FinancialNotification) message is sent by the Acquirer to the Agent to inform about a financial process to be further processed by an Issuer.

2: The Agent detects an error that he considers being in a position to correct. He forwards the amended FinancialInitiation (MessageFunction: FinancialNotification) message to the Issuer.

3: The Agent sends an Amendment (MessageFunction: AmendmentNotification) message to the Acquirer with the details of the error corrected, the initial message prior to correction and, possibly, a copy of the message amended after correction to inform the Acquirer about the message corrected and amended.



6.9 Batch ManagementBatch exchanges are used to transfer a group of messages between two entities.

In a BatchManagement mode, data is transferred within a session delimited by BatchManagementType “Start” and “End” elements with the messages to be transferred encapsulated within this session.

6.9.1 Message by message without intermediate acknowledgementsIn this scenario, the transfer is performed message by message within a session initiated by an Originator interacting with a Destination. The session is delimited by a “Start” message type and ends with an “End” one. Messages of any type and of any message function can be exchanged within a batch session (as reflected in the diagram below in grey).



1: The Originator sends a BatchManagementInitiation (MessageFunction: BatchRequest, BatchManagementType: Start) message to the Destination to initiate a batch transfer.

2: The Destination acknowledges the batch management request by sending a BatchManagementResponse (MessageFunction: BatchRequest, BatchManagementType: Start) message to the Originator.

3: The Originator sends message per message all the messages that are part of the batch to the Destination.

4: The Originator sends a BatchManagementInitiation (MessageFunction: BatchRequest, BatchManagementType: End) message to inform the Destination that the batch transfer is completed.

5: The Destination sends a BatchManagementResponse (MessageFunction: BatchRequest, BatchManagementType: End) to the Acquirer to acknowledge the completion of the batch transfer.

6.9.2 Message by message with intermediate acknowledgementsIn this scenario, synchronisation within a batch session is ensured through several check-points requiring an acknowledgment.

Those acknowledgements may be initiated in two ways:

Intermediate acknowledgements after a number of messages, Intermediate acknowledgements on request.

6.9.2.1 Acknowledgements after a number of messagesIn the present scenario, the Originator informs the Destination that an acknowledgment is required after a given number of messages received. Those acknowledgements are used as a check point mechanism at any time during the batch session to ensure a proper synchronisation between the two parties. The Destination sends an intermediate acknowledgment to the Originator each time the number of expected messages is received.



1: The Originator sends a BatchManagementInitiation (MessageFunction: BatchRequest, BatchManagementType: Start) to the Destination to request a batch transfer. The message contains the number of the message in the sequence (MessageSequenceNumber = 1), the number of messages to send (NumberOfMessages = 100) as well as the number of messages requiring an acknowledgement (AcknowledgementResponse = 100).

2: The Destination sends a BatchManagementResponse (MessageFunction: BatchRequest, BatchManagementType: Start) to Originator to accept the batch management.

3: From 3: (1) to 3: (100) (100 messages): The Originator sends to the Destination the messages that are part of the batch management session. A sequence may start at 1 (MessageSequenceNumber = 1) or at any other sequence number decided by the Originator.

4: After having received the number of messages expected before acknowledgement, the Destination sends a BatchManagementInitiation (MessageFunction: BatchNotification, BatchManagementType: AcknowledgementResponse) to notify the Originator about both the number of messages actually received (NumberOfMessages = 100) as well as the sequence number of the last message received (MessageSequenceNumber = 100).



5: From 5: (101) to 5: (m): The Originator continues sending the messages of the batch to the Destination.

6: The Originator sends a BatchManagementInitiation (MessageFunction: BatchRequest, BatchManagementType: End) to the Destination to inform it about the end of the batch transfer. The message contains both the total number of messages included in the batch (NumberOfMessages = m) as well as the number of the last message sent in the sequence (MessageSequenceNumber = m).

7: The Destination sends back a BatchManagementResponse (MessageFunction: BatchRequest, BatchManagementType: End) to acknowledge the end of the transfer. The message contains both the total number of messages received in the batch (NumberOfMessages = m) as well as the number of the last message received in the sequence (MessageSequenceNumber = m).

6.9.2.2 Acknowledgements on requestIn this scenario, the transfer is performed message by message inside a session initiated by an Originator with a start-of-batch management message and which ends with an end-of-batch management message. The Originator sends to the Destination on regular intervals requests to acknowledge the messages already received.



1: The Originator sends a BatchManagementInitiation (MessageFunction: BatchRequest, BatchManagementType: Start) to the Destination to initiate a batch management. The message contains the number of the message in the sequence (MessageSequenceNumber = 1) as well as the number of messages to send (NumberOfMessages = 100).

2: The Destination sends a BatchManagementResponse (MessageFunction: BatchRequest, BatchManagementType: Start) message to the Originator to accept the batch management.

3: From 3: (1) to 3: (100) (100 messages): The Originator sends to the Destination the messages that are part of the batch management session (NumberOfMessages = 100). A sequence may start at 1 (MessageSequenceNumber = 1) or at any other sequence number decided by the Originator.

4: The Originator sends a BatchManagementInitiation (MessageFunction: BatchNotification, BatchManagementType: AcknowledgementRequest) message to the Destination requesting an intermediate acknowledgement for the messages in the batch. The message contains the number of messages expected before acknowledgement (NumberOfMessages = 100) as well as the sequence number of the last message sent (MessageSequenceNumber = 100).



5: The Destination sends back a BatchManagementInitiation (MessageFunction: BatchNotification, BatchManagementType: AcknowledgementResponse) to the Originator to acknowledge the messages received. The message contains the number of messages received (NumberOfMessages = 100) as well as the sequence number of the last message received (MessageSequenceNumber = 100).

6: From 6: (101) to 6: (m): The Originator continues sending the messages that are part form the batch.

7: The Originator sends a BatchManagementInitiation (MessageFunction: BatchRequest, BatchManagementType: End) to the Destination to inform about the end of the batch transfer. The message contains the total number of messages sent (NumberOfMessages = 100) as well as the sequence number of the last message sent (MessageSequenceNumber = 100).

8: The Destination sends a BatchManagementResponse (MessageFunction: BatchRequest, BatchManagementType: End) to the Originator to acknowledge the end of the transfer. The message contains the total number of messages received by the Destination. The message contains the number of messages received (NumberOfMessages = m) as well as the sequence number of the last message received (MessageSequenceNumber = m).



6.9.2.3 Batch with negative acknowledgmentsThis use case shows how the acknowledgement of the messages helps to recover from situations where some messages are not correctly received.



1: The Originator sends a BatchManagementInitiation (MessageFunction: BatchtRequest, BatchManagementType: Start) message to the Destination to request a batch management. The message contains the number of the message in the sequence (MessageSequenceNumber = 81) as well as the number of messages to send (NumberOfMessages = 170).

2: The Destination sends a BatchManagementReponse (MessageFunction: BatchRequest, BatchManagementType: Start) message to the Originator to acknowledge the batch management.

3: The Originator sends to the Destination 100 messages that are part of the batch. Each individual message contains the batch identification and the sequence number (MessageSequenceNumber = 81 up to 180).

4: The Originator sends a BatchManagementInitiation (MessageFunction: BatchRequest, BatchManagementType: AcknowledgementRequest) to the Destination to request an intermediate acknowledgement of the messages received. The message contains the batch identification, the number of the last message in the sequence (MessageSequenceNumber = 180), and the number of messages actually sent (NumberOfMessages = 100).

5: The Destination sends a BatchManagementResponse (MessageFunction: BatchRequest, BatchManagementType: AcknowledgementResponse) message to acknowledge the messages received. The Originator has sent 100 messages, but the Destination has only received the two first ones. The acknowledgment is negative (PositiveAcknowledgement = False); the message contains the number of the last message in the sequence received (MessageSequenceNumber = 82) as well as the number of messages actually received (NumberOfMessages = 2).

6: The Originator continues with the transmission of the messages, resuming from the first message that was not received by the Destination (MessageSequenceNumber = 83).

7: The Originator sends a BatchManagementInitiation (MessageFunction: BatchRequest, BatchManagementType: AcknowledgementRequest) message to the Destination requesting an intermediate acknowledgement for the messages in the batch. The message contains the number of messages expected before acknowledgement (NumberOfMessages = 100) as well as the sequence number of the last message sent (MessageSequenceNumber = 180).

8: The Destination sends back a BatchManagementInitiation (MessageFunction: BatchRequest, BatchManagementType: AcknowledgementResponse) to the Originator to acknowledge the messages received. The message contains the number of messages received (NumberOfMessages = 100) as well as the sequence number of the last message received (MessageSequenceNumber = 180).

9: The Originator continues sending the remainder of the messages that are part of the batch. Each individual message contains the batch identification and the sequence number (MessageSequenceNumber = 181 up to 250).

10: At the end of the transfer, the Originator sends a BatchManagementInitiation (MessageFunction: BatchRequest, BatchManagementType: End) to the Destination to inform the destination about the end of the batch transfer. The message contains the total number of messages sent (NumberOfMessages = 170) as well as the sequence number of the last message sent (MessageSequenceNumber = 250).



11: The Destination sends a BatchManagementResponse (MessageFunction: BatchRequest, BatchManagementType: End) to the Originator to acknowledge the end of the transfer. The message contains the total number of messages received by the Destination. The message contains the number of messages received (NumberOfMessages = 170) as well as the sequence number of the last message received (MessageSequenceNumber = 250).



6.9.1 Collection of batchesIn this scenario, a batch management collection is composed of several batch management exchanges. A start collection request message initiates the whole collection management. An end- collection request message completes the whole collection management.



1: The Originator sends a BatchManagementInitiation (MessageFunction: CollectionRequest, BatchManagementType: Start) message to the Destination to request a batch collection management.

2: The Destination sends a BatchManagementResponse (MessageFunction: CollectionRequest, BatchManagementType: Start) message to the Originator to accept the batch collection management.

3: The Originator sends a BatchManagementInitiation (MessageFunction: BatchRequest, BatchManagementType: Start) message to the Destination to initiate a batch management.

4: The Destination sends a BatchManagementResponse (MessageFunction: BatchRequest, BatchManagementType: Start) message to the Originator to accept the batch management. The Originator sends message per message all the messages that are part of the batch to the Destination

5: The Originator sends a BatchManagementInitiation (MessageFunction: BatchRequest, BatchManagementType: End) message to inform the Destination that the batch management is completed.

6: The Destination sends a BatchManagementResponse (MessageFunction: BatchRequest, BatchManagementType: End) message to the Originator to confirm that the batch management is completed.

7: The Originator sends a new BatchManagementInitiation (MessageFunction: BatchRequest, BatchManagementType: Start) message to the Destination to accept a new batch management.

8: The Destination sends a BatchManagementResponse (MessageFunction: BatchRequest, BatchManagementType: Start) message to the Originator to accept the new batch management. The Originator sends message per message all the messages that are part of the batch to the Destination.

9: The Originator sends a BatchManagementInitiation (MessageFunction: BatchRequest, BatchManagementType: End) message to inform the Destination that the batch management is completed.

10: The Destination sends a BatchManagementResponse (MessageFunction: BatchRequest, BatchManagementType: End) message to the Originator to confirm that the batch management is completed.

11: The Originator sends a BatchManagementInitiation (MessageFunction: CollectionRequest, BatchManagementType: End) message to inform the Destination that the collection management is completed.

12: The Destination sends a BatchManagementResponse (MessageFunction: CollectionRequest, BatchManagementType: End) message to the Originator to confirm that the collection management is completed.



6.10 Batch TransferBatch exchanges are used to transfer a group of messages between two entities.

In a BatchTransfer mode, the transfer of batch is performed in the form of a unique file (one single message) containing all messages that are part of the batch.

The BatchTransfer mode also allows performing financial clearing of FinancialInitiation messages.

The presence of dedicated clearing specific data in the BatchTransfer part of the message enables a clearing Agent to exploit the clearing information without the burden and responsibility to look into the FinancialInitiation messages that are part of the transfer. When this possibility is used, it is the responsibility of the Originator to ensure the accuracy of the clearing information provided to the Destination within the clearing data part of the batch.

6.10.1 Miscellaneous types of messages in a single batchThe batch transfer is performed in the form of a single message containing all the messages to be transferred which can be of various types as well as a mix of request and response messages.

6.10.1.1 Batch transfer of notification messagesIn this scenario, the response to the batch transfer of different types of messages in a batch is essentially a technical one and is used to acknowledge the receipt of all messages contain in the batch.

1. An Originator sends a BatchTransferInitiation (MessageFunction: BatchRequest) message to a Destination. The batch contains notification messages of various types (financial, reversals, etc.)

2. The Destination acknowledges to the Originator with a BatchTransferResponse (MessageFunction: BatchRequest) message the receipt of the batch.



6.10.1.2 Batch transfer of request/response messagesIn this scenario, request messages are sent in a dedicated batch file by the Originator to the Destination. Response messages corresponding to their request counterparts are sent as a response in a dedicated batch file by the initial Destination (becoming the Originator) to the initial Originator (becoming the Destination).

1: The Originator sends a BatchTransferInitiation (MessageFunction: BatchRequest) message to a Destination containing all the request messages that are part of the batch.

2: The Destination sends a BatchTransferResponse (MessageFunction: BatchRequest) message to the Originator to acknowledge receipt of the batch of messages.

3: The Originator (former Destination) sends a BatchTransferInitiation (MessageFunction: BatchRequest) message to a Destination (former Originator) containing all the response messages that are part of the batch.

4: The Destination (former Originator) sends a BatchTransferResponse (MessageFunction: BatchRequest) message to the Originator (former Destination) to acknowledge receipt of the batch of messages.



6.11 ChargebacksChargeback refers to the refunding process for a transaction carried out by a card following the violation of a rule.

6.11.1 Chargeback AdviceIn the present scenario, charge-backs are performed through the exchanges of advice messages.

1. The Issuer sends a ChargeBackInitiation (MessageFunction: ChargeBackAdvice) to the Agent to initiate a charge-back.

2. The Agent sends a ChargeBackInitiation (MessageFunction: ChargeBackAdvice) to the Acquirer to inform him that the Issuer initiated a charge-back.

3. The Acquirer sends back a ChargeBackResponse (MessageFunction: ChargeBackAdvice) to the Agent to confirm that the transaction has been completed and cleared on his side after the charge-back and the reconciliation totals have been updated accordingly.

4. The Agent sends back a ChargeBackResponse (MessageFunction: ChargeBackAdvice) to the Issuer to confirm that the transaction has been completed and cleared on his side after the charge-back. The reconciliation totals have been updated accordingly.



6.11.2 Chargeback NotificationIn the present scenario, charge-backs are performed through the sending of notification messages.

1. The Issuer sends a ChargeBackInitiation (MessageFunction: ChargeBackNotification) to the Agent to inform the Agent that a charge-back was initiated and that the transaction has been completed and cleared on his side after the charge-back. The reconciliation totals have been updated accordingly.

2. The Agent sends a ChargeBackInitiation (MessageFunction: ChargeBackNotification) to the Acquirer to inform him that the Issuer has initiated a charge-back and to confirm that the transaction has been completed and cleared on both sides after charge-back. The reconciliation totals have been updated accordingly.



6.11.3 Chargeback requiring ReviewIn the scenario, the Agent performs a review of the chargeback before forwarding, if valid, the chargeback to the acquirer.

1. The Issuer sends a ChargeBackInitiation (MessageFunction: ChargeBackRequest) to the Agent to initiate a charge-back.

2. The Agent sends back a ChargeBackResponse (MessageFunction: ChargeBackRequest, Result: UnderReview) to the Issuer to inform him that the transaction is under review.

3. When the chargeback has been reviewed and approved, the Agent sends a ChargeBackInitiation (MessageFunction: ChargeBackStatusAdvice, Result: Approved) to the Issuer to confirm that the transaction has been completed and cleared. The reconciliation totals have been updated accordingly.

4. The Issuer sends back a ChargeBackInitiation (MessageFunction: ChargeBackStatusAdvice, Result: Processed) message to the Agent to inform him that the chargeback has been processed.

5. The Agent sends a ChargeBackInitiation (MessageFunction: ChargeBackAdvice) to the Acquirer to inform him that the Issuer processed a valid chargeback. The reconciliation totals have been updated accordingly.

6. The Acquirer sends back a ChargeBackResponse (MessageFunction: ChargeBackAdvice, Result: Processed) to the Agent to confirm that the transaction has been completed and cleared.



6.12 File ActionA file action is used to add, change, delete or replace a file or record or inquire into a file or perform card administration, e.g. report lost or stolen cards. The components of the messages are used to convey specific file action record or file information.

6.12.1 File Action Request

1: The Originator sends a FileActionInitiation (MessageFunction: FileActionRequest) message to the Destination for action to be performed on a file by the Destination.

2: The Destination performs the requested action. A FileActionResponse (MessageFunction: FileActionRequest) message is returned by the Destination to inform the Originator about the outcome of the action performed.

6.12.2 File Action Advice



1: The Originator sends a FileActionInitiation (MessageFunction: FileActionAdvice) message to advice the Destination of an action already performed on a file.

2: FileActionResponse (MessageFunction: FileActionAdvice) message is returned by the Destination to the Originator.



6.13 RetrievalRetrieval is the activity performed by the Acceptor, Acquirer or any relevant Agent needed to support an Issuer who requested that a transaction information document be examined before a potential chargeback is sent or to satisfy another need of the card issuer or cardholder.

6.13.1 Retrieval of a transactionIn this scenario, an Issuer initiates a retrieval message to an Acquirer through an Agent. The Agent forwards the message to the Acquirer. The Acquirer processes the retrieval initiation request, constructs the retrieval fulfilment notification and sends a message back to the Agent for a further forwarding to the Issuer.

1: The Issuer sends a RetrievalInitiation (MessageFunction: RetrievalNotification) message to the Agent requesting the Acquirer to carry out a retrieval process.

2: The Agent forwards the Retrievalnitiation (MessageFunction: RetrievalNotification) message to the Acquirer requesting to carry out a retrieval process on behalf of the Issuer.

3: The Acquirer processes the retrieval initiation request and constructs RetrevalFufillmentInitiation (MessageFunction: RetrievalFulfillmentNotification) and sends the message back to the Agent for a further forwarding to the Issuers.

4: The Agent forwards the RetrievalFulfillmentInitiation (MessageFunction: RetrievalFulfillmentNotification) message to inform the Issuer about the results of the retrieval fulfillment.

6.13.2 Retrieval Status Advice In this scenario, an Issuer initiates a retrieval request to an Agent. Agent validates the issuer’s request and send Retrieval status advice to issuer. For the successful retrieval status, Agent also sends retrieval



advice to the Acquirer requesting for fulfilment of the retrieval. The Acquirer processes the retrieval initiation request, constructs the retrieval fulfilment advice and sends a message back to the Agent for a further forwarding to the Issuer.

.

1: The Issuer sends a RetrievalInitiation (MessageFunction: RetrievalRequest) message to the Agent for requesting the status of a retrieval.

2: The Agent send the RetrievalResponse (MessageFunction: RetrievalRequest) message to the Issuer to indicate Retrieval request is received.

3: Once retrieval request is validated, The Agent sends a RetrevalInitiation (MessageFunction: RetrievalStatusAdvice) message to inform the issuer about the status of the retrieval.



4: The Issuer sends a RetrevalResponse (MessageFunction: RetrievalStatusAdvice) message back to agent to indicate status of the retrieval is received.

5: When the status of the Retrieval request from Issuer is valid, The Agent sends the RetrievalInitiation (MessageFunction: RetrievalRequest) message to request acquirer to fulfil the retrieval.

6: Acquirer sends RetrievalResponse (MessageFunction: RetrievalRequest) to indicate the retrieval request is received.

7: Acquirer processes the retrieval initiation request and constructs RetrievalFulfillmentInitiation (MessageFunction: RetrievalFulfillmentAdvice) message to Agent for a further forwarding to the Issuers.

8: Agents sends RetrievalFulfillmentResponse(MessageFunction: RetrievalFulfillmentAdvice) message to acquirer for the receipt of Retrieval fulfilment message.

9: The Agent forwards the RetrievalFulfillmentInitiation (MessageFunction: RetrievalFulfillmentAdvice) message to inform the Issuer about the results of the retrieval fulfilment from Acquirer.

10: Issuer sends RetrievalFulfillmentResponse(MessageFunction: RetrievalFulfillmentAdvice) message to Agent for the receipt of Retrieval fulfilment message.

6.14 Fee CollectionFee collection is the activity that supports the collection and disbursement of miscellaneous service fees between financial institutions. Fee collection has financial impact and affects reconciliation totals. Fee collection shall not affect a Cardholder account.

6.14.1 Fee Collection AdviceIn this scenario, an Originator sends a fee collection advice message to a Destination for a service fee due to be collected. The Destination sends a message back to the Originator to acknowledge the message without having the possibility to decline the advice message.



1: A FeeCollectionInitiation (MessageFunction: FeeCollectionAdvice) message is sent by the Originator to the Destination to request a service fee. The advice message shall never be declined

2: A FeeCollectionResponse (MessageFunction: FeeCollectionAdvice) message is returned by the Destination to the Originator to acknowledge the receipt of the message by the Originator.

6.14.2 Fee Collection NotificationIn this scenario, an Originator sends a fee collection initiation notification message to a Destination for a service fee due to be collected.

1: A FeeCollectionInitiation (MessageFunction: FeeCollectionNotification) message is sent by the Originator to the Destination to notify about a service fee due to be collected.



6.15 Settlement ReportingA settlement reporting advice is sent by an Originator to a Destination to report about the settlement of funds resulting from card-initiated transactions.

The settlement process itself is not represented in the present model since it is managed outside of the scope of the protocol.

1: A SettlementReportingInitiation (MessageFunction: SettlementReportingAdvice) message is sent by an Originator to a Destination to inform the Destination about the settlement of funds on its account usually after clearing.

The SettlementReportingResponse (MessageFunction: SettlementReportingAdvice) is returned by the Destination to the Originator to acknowledge receipt of the advice related to the settlement of funds on its account.



6.16 Fraud Reporting and DispositionA fraud reporting advice message is usually sent by either an Acquirer or an Issuer to an Agent to report confirmed fraud information.

The Agent may further respond to either the Acquirer or the Issuer with the disposition of the confirmed fraud information.

6.16.1 Issuer Reported Fraud

1: A FraudReportingInitiation (MessageFunction: FraudReportingAdvice) message is sent by an Issuer to an Agent to report a confirmed fraudulent transaction.

2: A FraudReportingResponse (MessageFunction: FraudReportingAdvice) message is returned by the Agent to the Issuer to acknowledge a successful receipt of the advice.

3: The reported fraud information is reviewed by the Agent and a FraudDispositionInitiation (Message Function: FraudDispositionAdvice) message is sent by the Agent to inform the Issuer of the disposition of the previously submitted confirmed fraud report.

4: A FraudDispositionResponse (Message Function: FraudDispositionAdvice) is returned by the Issuer to acknowledge the successful receipt of the advice. The Issuer reviews the disposition, and if there are errors, corrects the necessary information and resubmits the report of the fraudulent transaction.



6.16.2 Acquirer Reported Fraud

1: A FraudReportingInitiation (MessageFunction: FraudReportingAdvice) message is sent by an Acquirer to an Agent to report a confirmed fraudulent transaction.

2: A FraudReportingResponse (MessageFunction: FraudReportingAdvice) message is returned by the Agent to the Acquirer to acknowledge a successful receipt of the advice.

3: The reported fraud information is reviewed by the Agent and a FraudDispositionInitiation (Message Function: FraudDispositionAdvice) message is sent by the Agent to inform the Acquirer of the disposition of the previously submitted confirmed fraud report.

4: A FraudDispositionResponse (Message Function: FraudDispositionAdvice) is returned by the Acquirer to acknowledge the successful receipt of the advice. The Acquirer reviews the disposition, and if there are errors, corrects the necessary information and resubmits the report of the fraudulent transaction.



6.17 VerificationVerification is an activity carried out at the initiative of an Acquirer to request verification or authentication.

Examples of usage are: authentication of certificates, assurance level of tokens, certificate management, address verification, account verification and cheque verification. It is also used to inform the Issuer of a verification that has been completed on its behalf.

6.17.1 Verification RequestIn this scenario, Verification is initiated by an Acquirer to an Issuer requesting the Issuer to verify the billing address of a Cardholder.

1: The Acquirer sends a VerificationInitiation (MessageFunction: VerificationRequest) message to the Issuer for a billing address verification.

2: After having performed the verification, the Issuer sends a VerificationResponse (MessageFunction: VerificationRequest) message to convey the outcome of the verification that was performed by the Issuer.



6.17.2 Verification NotificationA notification message is sent by an Issuer to notify the Acquirer of a verification that has been completed on its behalf (after a request initiated by phone by the Acquirer, for instance).

The Acquirer requests by phone verification of an address to the Issuer.

1: A VerificationInitiation (MessageFunction: VerificationNotification) message is sent by the Issuer to the Acquirer to confirm the validity of the address after verification.



6.18 Card management

The card management process is used by the acquirer to fulfil a request initiated by the cardholder at the point of service for an operation on the card account.

6.18.1 Card management

In this scenario, Card management is initiated by an Acquirer to an Issuer requesting the Issuer to perform on operation on the card account.

1: The Acquirer sends a CardManagementInitiation (MessageFunction: CardManagementRequest) message to request the Issuer to perform an operation on the cardholder’s account.

2: After having performed the operation on the cardholder’s account, the Issuer sends a CardManagementResponse (MessageFunction: CardManagementRequest) message to convey the outcome of the operation.



6.19 Inquiry

Inquiry process is used by the acquirer to fulfil a request initiated by the cardholder at the point of service to inquire about the details of the card account (e.g. fees prior to a transaction, available funds, balance, etc.).

6.19.1 Available balance inquiryIn this scenario, the Acquirer is fulfilling a request to ask the issuer to provide information about available funds held by the Cardholder on his account.

1: The Acquirer sends an InquiryInitiation (MessageFunction: InquiryRequest) message to the Agent to request available balance from a cardholder.

2: The Agent forwards the InquiryInitiation (MessageFunction: InquiryRequest) message to the Issuer to request available balance on the cardholder’s account.

3: The Issuer sends an InquiryResponse (MessageFunction: InquiryRequest) to the Agent with the information requested.

4: The Agent forwards the InquiryResponse (MessageFunction: InquiryRequest) to the Acquirer with the information requested.

6.19.2 Requesting of fees prior to a transaction

In this scenario, the Acquirer asks the Issuer to provide information about fees that a cardholder may incur prior to a transaction (e.g. fees pertaining to a withdrawal transaction at an ATM).



1: The Acquirer sends an InquiryInitiation (MessageFunction: InquiryRequest) message to the Agent to request the fees related to a given transaction prior to its execution.

2: The Agent forwards the InquiryInitiation (MessageFunction: InquiryRequest) message to the Issuer to request the information to the Issuer.

3: The Issuer sends an InquiryResponse (MessageFunction: InquiryRequest) to the Agent with the fees information.

4: The Agent forwards the InquiryResponse (MessageFunction: InquiryRequest) to the Acquirer with the information requested.



7. ExamplesExamples of various Message Definitions will be found in the relevant implementation guides to be delivered by the card payment industry.

8. Revision Record

Revision Date Author Description Sections affected

2.0 ISO TC68/SC7/TG1 (now ISO TC68/SC9/TG1)

First version All

4.0 02/25/2019 ISO/TC68/SC9/TG1 Second version All

Disclaimer:Although the Registration Authority has used all reasonable efforts to ensure accuracy of the contents of the iso20022.org website and the information published thereon, the Registration Authority assumes no liability whatsoever for any inadvertent errors or omissions that may appear thereon. Moreover, the information is provided on an "as is" basis. The Registration Authority disclaims all warranties and conditions, either express or implied, including but not limited to implied warranties of merchantability, title, non-infringement and fitness for a particular purpose.The Registration Authority shall not be liable for any direct, indirect, special or consequential damages arising out of the use of the information published on the iso20022.org website, even if the Registration Authority has been advised of the possibility of such damages.

Intellectual Property Rights:The candidate ISO 20022 MessageDefinitions described in this document were contributed by ISO TC68/SC7/TG1. The ISO 20022 IPR policy is available at www.ISO20022.org > About ISO 20022 > Intellectual Property Rights.


€¦ · Web viewScope and Functionality Background This Message Definition Report covers a set of...

Documents

Transcript of €¦ · Web viewScope and Functionality Background This Message Definition Report covers a set of...