EACHA Instant Payments Interoperability Framework

Transcription

1 EACHA Instant Payments Interoperability Framework EACHA Framework version : 2017 V1.0 EACHA Framework approval date : 6 April 2017 Aligned to EPC Scheme Rulebook version : 2017 SCT Inst Rulebook version 1.0 Document status : Final

2 DISCLAIMER The information contained in this document is published by EACHA without EACHA undertaking or accepting any duty of care or responsibility for its content or the timeliness of the publication. No assurance of the quality of the information is given or undertaken (whether as to its accuracy, completeness, fitness for any purpose, conformance to any description, or otherwise), or as to the timeliness of the publication. EACHA hereby excludes all liability (whether for breach of contract, in tort (including negligence) or otherwise) for all or any loss, damage, cost and expense incurred or sustained by any person arising from or in connection with the use or reliance on the information, except to the extent liability may not be excluded or limited by law. Page 2 of 45

3 Content 1 About the EACHA The EACHA Purpose and Scope of Document Terminology EACHA Instant Payments Interoperability Framework structure Building Technical Interoperability Building the Interoperability Framework on EPC work Interoperability models Compliance with Eurosystem conditions The EACHA CSM Interoperability model Equality between Parties Achieving and maintaining Interoperability standards The EACHA model Overview of EACHA interoperability process Reach and routing EPC message flows, message standards and validation rules Settlement Operational management Version history Glossary Annex I Annex II Annex III Annex IV Annex V : Reach Table : Reconciliation message : Administration messages : SCT Inst Payment, Recall and Investigation Messages : CSM Liquidity Transfer Request and response Page 3 of 45

4 1 About the EACHA 1.1 The EACHA The European Automated Clearing House Association started in early 1990 as an informal meeting of executives from European ACHs. On 28 September 2006, representatives from 20 Automated Clearing Houses and retail Payment Processors founded EACHA officially under Belgian law, since then it has grown to comprise 22 members. The list of members and a link to members own websites can be found on EACHA is a not-for-profit organisation and does not perform a commercial or operational role in payment processing. EACHA is the technical cooperation forum of European ACHs; its philosophy is that healthy competition also means cooperative teamwork. EACHA believes firmly in developing a common vision for the future, and favouring harmonious implementation of European policies and schemes including Interoperability based on open standards. EACHA aims to: Be a forum enabling its members to share information; Advance the views of its members on issues of general interest; Address specific issues as and when they arise e.g. developing common guidelines for clearing and settlement of SEPA Payments. 1.2 Purpose and Scope of Document In this Framework, Interoperability refers to the ability to be systematically and consistently accessible to other Payments Service Providers and CSMs processing SCT Inst transactions in euros. CSMs will choose whether to establish interoperability links and the CSMs they will link to. If CSMs choose to establish interoperability, this framework enables parties to use the same technical standards and procedures and make it possible for them to exchange data fully automatically. The Interoperability Framework facilitates Interoperability between CSMs, but may also be used by PSPs. This Interoperability Framework complements and complies with the scheme rules, standards and market goals for SCT Inst developed by the EPC. The Framework also complies with the conditions set by the Eurosystem for the clearing of instant payments. It is EACHA's aim to enable technical Interoperability on the basis of this framework. It is not EACHA's aim or role to implement bilateral Interoperability agreements between CSMs. This is the domain of the CSMs themselves. It is up to the individual CSMs to decide if, and with which party, they would like to operate a link based on the EACHA Framework. This framework will be will be freely available to PSPs, to EACHA CSMs and non EACHA CSMs. This framework may in due course be extended to include other currencies. 1.3 Terminology The Framework uses the PSD terminology. Parties are addressed in their role as Payment Service Providers or CSMs. It concentrates on the payment functions rather than who is performing the specific functions or processes, as many banks combine (parts of) both roles. Whenever in this document the term "bank" is used, it refers to its role as Payments Service Provider. The term Clearing and Settlement Mechanism (CSM) is used in the capacity of a Page 4 of 45

5 Payment Processor that allows participating PSPs or their branches to clear and settle payments made between them. This is in line with the definition of CSM in SEPA. The terms OCSM and BCSM are used to describe the CSM servicing the Originator PSP and the CSM servicing the Beneficiary PSP respectively. A glossary of terms is included in section EACHA Instant Payments Interoperability Framework structure The EACHA Instant Payments Interoperability Framework is aligned with the latest version of the EPC SCT Inst Rulebook. A split is made in this framework between the functional and technical description of EACHA Interoperability to make it more accessible. The Framework itself gives a global functional and technical overview for those who want to understand the main principles of EACHA Interoperability. A number of annexes provide the technical and functional details necessary for the implementation: Annex I contains the technical specification of the Reach Tables Annex II contains detailed message definition for the Reconciliation Message Annex III contains detailed message definitions for Administration Messages Annex IV contains the detailed message definitions for an SCT Inst Payment, a Recall and an Investigation Annex V contains the detailed message definitions for the CSM liquidity transfer Request Page 5 of 45

6 2 Building Technical Interoperability 2.1 Building the Interoperability Framework on EPC work EACHA explicitly recognises the key role of the European Payment Council (EPC) in defining the SEPA Payment schemes and the business Interoperability that they ensure between scheme Participants. The rules and standards defined in the EPC SCT Inst Scheme Rulebook, EPC Implementation Guidelines, and in the UNIFI Message sets lay the foundation for Interoperability. The SCT Inst scheme is optional for PSPs. However, participating PSPs must be reachable by all other participating PSPs. To meet this reachability requirement, EACHA believes that additional operational and technical conventions for technical Interoperability are needed. EACHA seeks to standardise the technical procedures necessary for the technical Interoperability of CSMs through this framework based on strict conformance with the scheme rules. EACHA believes that Interoperability is a key component of the SEPA infrastructure in a competitive market and through the Interoperability Framework aims to promote the following shared goals: Creating reach for instant payments within SEPA. Using common standards CSMs are able to connect to each other (Inter-CSM connections) and share their reach. This creates the infrastructure needed in SEPA. A harmonised implementation of SCT Inst processing on the infrastructure level. Flexible competitive choices for Payment Services Providers and CSMs. Technical Interoperability is required within the SEPA to offer PSPs the freedom to change Community or to join several communities, all based on the same Interoperability model. CSMs will compete on a level playing field based on the volumes they attract and on the services they provide. Combined with low switching cost as a result of shared Interoperability, the market will constantly arbitrage inefficiencies and barriers. Market-led rationalisation to boost efficiency and quality. 2.2 Interoperability models EACHA has already developed a framework for SCTs and SDDs which has been implemented by a number of CSM, which is one of the possible models in SEPA for achieving reach. 2.3 Compliance with Eurosystem conditions Following discussions with industry stakeholders, the Eurosystem have specified three conditions for the clearing and settlement of instant payments i.e. A single procedure for settlement of pan-european instant payments via TARGET2 ASI. A single model for risk management. A common access policy. This framework aims to be aligned to these conditions. Page 6 of 45

7 2.4 The EACHA CSM Interoperability model Interoperability is achieved in a layered approach, building on international messaging standards delivered by ISO and the scheme rules and standards delivered by the EPC. The layers are illustrated from a CSM perspective in the diagram below. EACHA Interoperability Model Business layer CSM bilateral interoperability agreements Technical layer EACHA Instant Payments Interoperability Framework EPC Scheme SCTinst Rulebook and Implementation Guidelines Figure 1: The Interoperability layers on top of the basis for SEPA: EPC Rulebooks and Implementation Guidelines The layers will operate as follows: Business layer: an overarching Business layer is added through bilateral Inter-CSM Interoperability Agreements covering the contractual responsibilities and liabilities undertaken by the CSMs in providing Interoperability to their Participants. The business layer is a key component to Interoperability being the contractual relationship between two CSMs in providing bilateral reach. The business layer will also specify CSM compliance with the Interoperability Framework in relation to: o o o o messaging and processing flows, operational procedures and exception handling, routing table usage and exchange, settlement and risk management. Technical layer: EACHA delivers this Framework that defines the technical layer that supplements the scheme Rulebook and Implementation Guidelines. The framework specifies additional messaging standards and rules in the Inter-CSM space to ensure efficient and safe delivery of transactions between CSMs EPC Scheme EPC will create the SCT Inst Rulebook and Implementation guidelines which will specify the rules and obligations for participants in the scheme as well as the standards to be used. Page 7 of 45

8 2.5 Equality between Parties EACHA believes that Interoperability can only be established based on mutually agreed conditions without specific pre-conditions from one of the parties involved. Only in this way a level playing field can be established enabling the required competition within the SEPA. It means that parties may cooperate on creating the interoperable connection and compete on services. 2.6 Achieving and maintaining Interoperability standards The Interoperability standards are developed and maintained by an EACHA Working Group that consists of Payments experts of the EACHA Members. Maintenance and developments are based on the developments and changes of the EPC Rulebooks and the experience of Members operating connections. This assures that the Framework remains aligned with current working practises and supporting the goals of PSPs and CSMs alike within SEPA. EACHA builds on the standards set by EPC. However, where functionality and standards are required specifically to support Interoperability that is not defined in the EPC Rulebook or Implementation Guidelines, EACHA has defined solutions based on open XML standards. The Reach Table is a good example of this. The EACHA Framework is future proof because it offers the flexibility to extend the Interoperability between CSMs to any future schemes or scheme extensions developed by the EPC. Page 8 of 45

9 3 The EACHA model This section of the Framework defines the functional areas of technical interoperability and is supported by appropriate technical annexes. This section describes the following areas of functionality: Overview of EACHA interoperability process, Reach and Routing, Message flows, message standards and validation rules, Settlement and reconciliation, Operational procedures, Connectivity and security. 3.1 Overview of EACHA interoperability process Many SCT Inst payments will be processed between PSPs on the basis of a single CSM between them. However where payments are to be processed across multiple CSMs (usually two) the EACHA interoperability model may be used. Interoperability covers the clearing process, the settlement process and access policies The clearing process The clearing process follows the EPC defined SCT Inst message flows, although there will be more than one CSM between the Originator PSP and the Beneficiary PSP. This is illustrated at a high level in the diagram below. Mandatory Scope of EPC Scheme Payment Payment Payment Originating PSP OCSM BCSM Beneficiary PSP Beneficiary Response: accept or reject 6 Response: accept or reject 5 Response: accept or reject EPC target 10 seconds 4 Response: accept or reject The sequence of operations in the model will be as follows: 1. On receipt of an instant payment instruction from its Originating customer, the Originator PSP sends a payment instruction to its chosen CSM (OCSM in the diagram), 2. OCSM determines based on its routing tables that the Beneficiary PSP is connected to another CSM (BCSM in the diagram) and routes the message to BCSM, 3. BCSM sends the message to the Beneficiary PSP, 4. The Beneficiary PSP sends either an accept or reject message to BCSM. When the Beneficiary PSP is certain that the accept response has reached the BCSM, funds will be made available to the Beneficiary, 5. BCSM passes on the response to OCSM, 6. OCSM responds to its Originating PSP, 7. Originator PSP responds to its Originating Customer as agreed with its customer. Page 9 of 45

10 3.1.2 The settlement process In line with the Eurosystem conditions, CSMs will use a single procedure for the settlement of pan-european instant payments. This involves PSPs pre-funding the settlement of their instant payments in cash. This will be supported by the TARGET 2 Ancillary System Interface (ASI). The ASI6 Realtime procedure will be used to manage the prefunded balances of PSPs via a single TARGET2 technical account per CSM. The single procedure means that all instant payments are settled in real time, including intra CSM payments. The technical processes that CSMs will support to enable their PSPs to fund and defund the technical accounts is out of scope for this interoperability framework. During TARGET2 opening hours, CSMs will transfer prefunded liquidity to the technical accounts of the CSMs they are connected to, in order to fund the inter CSM payments they are making. Two settlement models have been developed. Model 1 CSMs will transfer liquidity to the technical accounts of connected CSMs to prefund their payments. OCSMs are responsible for ensuring sufficient liquidity is available before they clear payments via BCSMs. BCSM will reject payments from OCSM if OCSM has not provided sufficient liquidity in the BCSM s technical account. EACHA compliant CSMs will support this inter CSM prefunding process. CSMs will use TARGET2 to transfer funds between each other in both directions i.e. OCSM will transfer funds to BCSM and OCSM will be able to request the return of excess funds from BCSM. These transfers of liquidity from one CSM ASI Technical Account to another are illustrated in the diagram below. A. OCSM transfers liquidity to BCSM 1. Transfer request 2. Credit advice TARGET2 ASI OCSM BCSM B. OCSM requests return of liquidity from BCSM 4. Credit advice TARGET2 ASI 3. ASI transfer request OCSM 1. Request for return of liquidity (pacs.010) 2. BCSM accepts / rejects request (pacs.002) Messages in EACHA scope BCSM Page 10 of 45

11 Model 2 CSMs may also agree bilaterally to transfer liquidity on a post rather than pre funding basis. This means that OCSM will earmark liquidity that is to be transferred to other CSMs as payments are cleared and from time to time OCSM will transfer earmarked liquidity to BSM s technical account after payments have been cleared. In this case, CSMS will agree bilaterally on how risk is managed. The transfer of liquidity using TARGET2 will follow the same flows as described in the above diagram for A. OCSM transfers of liquidity to BCSM. The return of liquidity functionality will not be required Risk management Where CSMs choose the prefunded settlement procedure all intra CSM and inter CSM payments are made based on prefunded liquidity held in TARGET2 technical accounts. Where CSMs choose post funded inter CSM settlement, they will agree how inter CSM risk is managed Common access policy CSMs will bilaterally agree the operational and commercial terms on which they will exchange payments outside the scope of this framework. They will do this on the basis of this Interoperability Framework. Nevertheless, access will be established in line with the principle of equality between parties (see section 2.5). Accordingly, cross ACH membership should not be necessary and an ACH should be able to move messages and funds to another ACH without requiring the sponsorship of a credit institution or a National Central Bank. Page 11 of 45

12 3.2 Reach and routing Introduction Each CSM is responsible for deciding how to route payments and what reach it will provide to its PSPs for SCT Inst payments. Where a CSM establishes interoperability with another CSM to provide reach, the reach table mechanism facilitates the routing process. Each PSP will be connected to at least one CSM in order to reach all other SCT Inst participants. On the basis that not every PSP will be connected to every CSM, CSMs will cooperate with each other to facilitate reachability for SCT Inst. This allows PSPs connected to a CSM to send payments to PSPs connected to another CSM. Because each CSM and PSP may have several connections, it will often be possible for an originating PSP to reach the Beneficiary PSP through more than one route. The EACHA routing mechanism enables PSPs and CSMs to identify and select the optimal routing path for their SEPA Inst payments but does not guarantee to provide full reach to all SCT Inst PSPs. Establishing the necessary reach and the routing of payments is a decision for each CSM. In EACHA interoperability, there will be no more than 2 CSMs between OPSP and BPSP Reach table principles CSMs will be connected to one or more other CSMs. Each CSM will make available a table of its reachable PSPs to the other CSMs it is connected to. This allows the connected CSMs to create their own internal routing table to support their routing of payments. The EACHA reach table mechanism adheres to the following broad principles: Each CSM will make the table available to all CSMs it is connected to. It is in a standardised structured form based on XML ISO data definitions. The table of each CSM defines the PSPs that participate in that CSM and are reachable for inter CSM payments. It is a decentralised table. There is no centralised coordination. Each CSM constructs its own internal reach table using its own business rules from the tables of its connected CSMs and any other information it may choose to use e.g. price, speed of processing, etc. The table may be provided as a full list of all participants, or the changes since the last version (delta update). CSMs will agree bilaterally how the table is to be exchanged and when. CSMs may agree extensions to the table on a bilateral basis. Reach tables will define the validity date and time i.e. the exact time from which the CSM should use the entries in the table Reach table entries The reach table consists of entries which identify the PSPs connected to the CSM providing the table. A full definition of the table is in ANNEX I. Reachable PSPs are identified by BICs which may be specified in one of three formats as described in the table below. Page 12 of 45

13 BIC format Example Meaning BIC11 BANKDEFFMUC This BIC11 is reachable via the CSM BIC8 (wild card) BANKDEFF Any BIC11 where the first 8 characters match the specified BIC8 is reachable. This wild card option allows CSMs to specify that multiple branch BICs with the same first 8 characters are reachable without needing to list every branch BIC11. BIC8+XXX BANKDEFXXX This BIC8 is reachable via the CSM A number of worked examples are given below to illustrate the above rules. EXAMPLES This example is based upon an EACHA link between two CSMs, OCSM and BCSM, where the focus is mainly on the PSPs that can be reached through BCSM. BCSM has previously transmitted the following reach table to OCSM. This table includes three PSPs specified through specific BIC entry sets. Reach table sent by BCSM to OCSM Name of PSP BANK BANA BANB Table entry BANKDEFF BANADEFFXXX BANADEFFWXY BANBDEFFWXY BANBDEFFXYW The following table specifies the expected processing in OCSM when checking whether payments can be routed to BCSM. The Receiving Agent provided within this table is the Creditor Agent of the corresponding payment message. Receiving agent Reachable Yes/No? Logic BANKDEFF Y Transaction can be routed to BCSM (thanks to the BANKDEFF wildcard within the RT) BANKDEFFXXX Yes Transaction can be routed to BCSM (thanks to the BANKDEFF wildcard within the RT) BANKDEFFWXY Yes transaction can be routed to BCSM (thanks to the BANKDEFF wildcard within the RT) BANADEFF Yes Transaction can be routed to BCSM (thanks to the explicit BANADEFFXXX within the RT) BANADEFFXXX Yes Transaction can be routed to BCSM (thanks to the explicit BANADEFFXXX within the RT) BANADEFFWXY Yes Transaction can be routed to BCSM (thanks to the explicit BANADEFFWXY within the RT) BANADEFFXYW No Transaction cannot be routed to BCSM (no match) BANBDEFF No Transaction cannot be routed to BCSM (no match) BANBDEFFXXX No Transaction cannot be routed to BCSM (no match) BANBDEFFWXY Yes Transaction can be routed to BCSM (thanks to the explicit BANBDEFFWXY within the RT) BANBDEFFXYW Yes transaction can be routed to BCSM (thanks to the Page 13 of 45

14 Receiving agent Reachable Yes/No? Logic explicit BANBDEFFXYW within the RT) BANBDEFFYWX No Transaction cannot be routed to BCSM (no match) Moreover, in order to ensure the correct forwarding of possible Recall transactions, OCSM can also use the reach table sent by BCSM to check if acceptance of original transaction would lead to a cul-de-sac for those Recall transactions. Therefore, the following table specifies the expected behaviour from BCSM for different transactions received from OCSM. The Receiving Agent provided within this table is the Debtor Agent of the underlying original payment message. Receiving agent Reachable Y/N? Logic BANKDEFF Yes Transaction shall be accepted (thanks to the BANKDEFF wildcard within the RT) BANKDEFFXXX Yes Transaction shall be accepted (thanks to the BANKDEFF wildcard within the RT) BANKDEFFWXY Yes Transaction shall be accepted (thanks to the BANKDEFF wildcard within the RT) BANADEFF Yes Transaction shall be accepted (thanks to the explicit BANADEFFXXX within the RT) BANADEFFXXX Yes Transaction shall be accepted (thanks to the explicit BANADEFFXXX within the RT) BANADEFFWXY Yes Transaction shall be accepted (thanks to the explicit BANADEFFWXY within the RT) BANADEFFXYW No Transaction shall be rejected (no match) BANBDEFF No transaction shall be rejected (no match) BANBDEFFXXX No transaction shall be rejected (no match) BANBDEFFYWX No transaction shall be rejected (no match) BANBDEFFWXY Yes transaction shall be accepted (thanks to the explicit BANBDEFFWXY within the RT) BANBDEFFXYW Yes transaction shall be accepted (thanks to the explicit BANBDEFFXYW within the RT) Specifying the activation date / time Reach tables will only be effective when CSMs activate the new routing information in their systems. Changes to tables may be the addition, the deletion or the amendment of entries. Entries will be activated on the basis of a validity date and time which specifies when each entry should be used. Activation dates are calendar dates and may fall on non TARGET2 operating days. Because payments continue to be processed 24X7, CSMs should activate reach table entries as close as possible to the relevant validity date and time in order to avoid misalignment with other connected CSMs. BCSMs may choose to implement reach table changes slightly before the validity date and time in order to minimise the possibility of payments being rejected. Validity date and time may be specified in two ways i.e. Page 14 of 45

15 Header level: the validity date and time of the reach table may be specified in the field file validity date at group header level (<GrpHdr><FileValidityDate>). This date/ time must always be in the future i.e. after the time when the table was distributed. Individual entry: the dates of the element validity at individual reach entry level (<RchEntry><Validity><FrDtTm> and <RchEntry><Validity><ToDtTm>). Note that the entry level date / time does not have to be the same as the validity date of the reach table as specified in the group header level. Entry validity date / time may therefore be the same or later than the group header date/ time, but not earlier Distribution of reach tables The frequency and method CSMs use to exchange reach tables will be agreed bilaterally. Nevertheless, experience in SCT shows that CSMs should consider carefully the timing and frequency of the reach table exchange. CSMs should consider the following points: A market wide harmonised timetable for the exchange of reach tables between CSMs will be beneficial. This will ensure the simultaneous activation, amendment and deletion of BICs across all connected CSMs, which is important where PSPs are connected to more than one CSM. The timetable for the exchange of routing data should give sufficient time for CSMs to resolve any queries they have on the data they receive from other CSMs and distribute reach data to their participants. The two CSMs acting in a bilateral inter CSM relationship are regarded to be both in the role of sending (OCSM) and receiving (BCSM); hence the combination of frequencies should be agreed in order to work in both directions Using the reach table entries to route payments Each CSM is responsible for determining its own routing criteria e.g. time, cost, etc. However the following points should be noted and observed by CSMs: Reach table updates could occur while a payment is being processed. A CSM sending an instant payment should route it based on the CSM reach table information valid at the moment of Acceptance Date and Time (AT-50). Instant payments for a specific date may span two TARGET2 working days because the TARGET2 day starts each day at 19:30 CET. The reach table of a CSM manages the current valid information as well as the future valid information. When a CSM receives a Recall transaction, it will check whether it processed the original transaction. If so, then it routes (forwards) the Recall transaction through the path of the original transaction, if it is possible. If not, then it routes the Recall transaction according to the current reach table. In case this is not possible (no reach) it rejects the Recall transaction. Page 15 of 45

16 3.3 EPC message flows, message standards and validation rules The message flows and message standards used by CSMs will be compliant with those specified in the EPC Rulebook and Implementation Guide. Annex IV contains the message descriptions and the data element definitions for all of these EPC defined messages. This section defines the technical standards necessary to support interoperability i.e. Principles for message processing for interoperable CSMs, Time limits in the processing of messages, The three message exchanges specified in the EPC rulebook are defined in terms of how they would operate with connected CSMs i.e. o o SEPA SCT Inst processing flow, Recalls processing flow, o Investigation message processing flow, Supplementary data rules Principles for message processing for interoperable CSMs The following principles will apply; It is up to the individual PSP and CSM which validations are done and in what way. CSMs should ensure that payments send to another CSMs adhere to the rules and timelines set in the SCT Inst Rulebooks and Implementation Guide. Even if a CSM in the payment chain is not using white fields in the payment message, the CSM should always pass any white fields to the next party in the chain. All actors in the payment chain must be able to support all yellow field options in the payment messages. For example, if data can be included in the group header or the individual transactions then CSMs must be able to support both options. CSMs will always pass on messages without change. For example, the instructing and instructed agent fields will always contain the BIC of the BPSP or the OPSP as appropriate; the agent fields will never contain the BIC of the CSM Time limits in the processing of messages The various timing rules are as follows: 20 second timeout: the deadline at which the BCSM has to receive an accept or reject message from BPSP. If OCSM, BCSM or BPSP receives an SCT Inst payment after this time they will reject the payment. 25 second deadline: the time by which the accept or reject message from BPSP has to reach the OPSP, After the 25 second deadline: OPSP can start an investigation procedure. In addition the rulebook requires special processing by any party in the payment chain when technical problems delay messages which link to the above timing rules. The rules are summarised as follows: Page 16 of 45

17 Actor Originator PSP (OPSP) OCSM BCSM Beneficiary PSP (BPSP) Time related processing rules It cannot unilaterally reject an SCT Inst payment. It has to wait for a response message from OCSM Can only reject an SCT Inst payment if it receives it after 20 seconds. In all other cases, it has to hold the reservation on the OPSP settlement position and wait for the response message from the BCSM which could be an accept or reject. Rejects an SCT Inst payment if it receives it after 20 seconds from OCSM or it has not received the response message from the BPSP within 20 seconds Rejects an SCT Inst payment if the initial SCT Inst payment cannot be processed it receives the payment from BCSM after 20 seconds it is certain that its response message for the payment cannot reach / has not reached the BCSM within the 20 seconds Makes funds immediately available: only if it is certain that its positive confirmation message reached BCSM within 20 seconds. This certainty is provided in EACHA interoperability by BCSM sending the pacs.002 confirmation message to the BPSP as well as to OCSM. Details about the way in which payments should be processed in accordance with the above rules in exceptional circumstances are in the following sections of the document: Message processing logic for timeouts is in section The way in which accepted, rejected and timed out payments will be settled between CSMs is described in section SCT Inst processing flow This section describes the message flows and the processing logic for accepted and rejected using the pacs.008 and pacs.002 messages. Customer to PSP messages are out of scope. The diagram below summarises the processing flow. The steps in the process are as follows: 1. The Originator initiates a credit transfer initiation message to the Originator PSP, using either a pain.001 or similar (proprietary) message in accordance with an agreement with its PSP. Page 17 of 45

18 2. Based on the credit transfer initiation message, the Originator PSP sends a SCT Inst (pacs.008) to OCSM. 3. OCSM forwards the SCT Inst (pacs.008) to BCSM with a Reconciliation Reference (see section 3.4.8). 4. BCSM forwards the SCT Inst (pacs.008) to the Beneficiary PSP. 5. The Beneficiary PSP validates the SCT Inst (pacs.008) and sends a positive/negative status report (pacs.002) message back to BCSM to confirm that the message was valid / invalid. 6. BCSM then delivers that status report (pacs.002) message to OCSM. At the same time, the BCSM sends the positive status report (pacs.002) message to the Beneficiary PSP to ensure that it is certain that its response has been received by BCSM. Content of pacs.002 sent to OCSM and BPSP by BCSM will be identical to the one received from the BPSP with the Reconciliation Reference (see 3.4.8). 7. OCSM delivers the received status report (pacs.002) to the Originator PSP. 8. The Originator PSP processes the positive / negative pacs.002 as appropriate, including an immediate response to the Originator if it is a negative response. Page 18 of 45

19 The processing logic for each actor in the chain is explained in the diagram below

20 The processing steps are as follows: 1) The Originator initiates a credit transfer initiation message to the Originator PSP, using either a pain.001 or similar (proprietary) message in accordance with an agreement with its PSP. 2) The Originator PSP validates the Credit Transfer and either accepts it or rejects the initiation request. 2a) In the case of an accept, the Originator PSP generates an SCT Inst (pacs.008) message and sends it to OCSM. 2b) In the case of a reject, the Originator PSP generates a negative response back to the Originator. 3) OCSM validates the SCT Inst and either accepts or rejects it. 3a) In the case of an accept, OCSM generates an SCT Inst (pacs.008) message with the Reconciliation Reference included in the message. Afterwards it sends the SCT Inst to BCSM. 3b) In the case of a reject (structural or time-out), OCSM generates a negative response back to the Originator PSP. 4) BCSM validates the SCT Inst and either accepts or rejects it. 4a) In the case of an accept, BCSM generates an SCT Inst (pacs.008) message and sends it to the Beneficiary PSP. 4b) In the case of a reject (structural or time-out), BCSM generates a negative response with the information of the original Reconciliation Reference included in the message. Afterwards it sends to the negative response back to OCSM. 5) The Beneficiary PSP validates the SCT Inst and either accepts or reject it. 5a) In case of an accept BPSP generates a positive response to the SCT Inst (pacs.008) message in the form of a pacs.002 and sends it to BCSM. 5b) In the case of a reject (structural or time-out), the Beneficiary PSP generates a negative response back to BCSM. 6) The beneficiary CSM will receive the pacs.002 response from BPSP 6a) In the case of an accept by BPSP, the BCSM will send the pacs.002 response to OCSM and BPSP 6b) In the case of a reject by BPSP, the BCSM will send the pacs.002 response to OCSM. Note that BCSM needs to provide the original Reconciliation Reference from the original SCT Inst back to OCSM 7) BPSP receives the pacs.002 confirmation from BCSM and as a result is certain that its response has been received by the BCSM. The Beneficiary PSP makes the funds available to the Beneficiary. 8) All received responses (positive or negative) will be passed back to the previous sender (either PSP or CSM). 8a) Received response forwarded to the Originator PSP. 8b) Originator PSP provides response back to the Originator as appropriate and as required in the SCT Inst Rulebook. Page 20 of 45

21 3.3.4 Recalls Recalls are not subject to a Rulebook defined timeout and are not synchronous i.e. a response may take minutes, hours or days to come back. The EPC rulebook requires that the Recall message is routed through the same path which was used for the initial SCT Inst Transaction with no alteration of the data contained in the original SCT Inst transaction. The Rulebook also requires that parties in the interbank space must send the recall messages to the next party in the interbank space immediately. Responses to recall messages must also be forwarded immediately. However, CSMs may send the Recall messages via their normal SCT process or use their SCT Inst service. If OCSM sends a recall to BCSM via its SCT Inst service (camt.056) BCSMs should ensure that the response (pacs.004 or camt.029) is returned to the recalling OCSM via the same SCT Inst route. OCSMs will pass messages through and will not validate them e.g. the OCSM will not check that response messages matches a previous camt.056 request or check that a camt.056 matches a previous payment, etc. The diagram below summarises the processing flow. Note the original SCT Inst flow is not shown (see section 3.3.3heik) The steps in the process are as follows: 1. The Originator PSP initiates a recall using the Cancellation Request (camt.056) and sends the recall to OCSM within 10 business days of the original payment. 2. OCSM forwards the recall request (camt.056) to BCSM. 3. BCSM forwards the recall request to the Beneficiary PSP. 4. Beneficiary PSP investigates and consults the Beneficiary. 5. Investigation response from Beneficiary. 6. Based on the outcome of the investigation either a negative response in form of a camt.029 or a positive response in form of a Payment Return (pacs.004) will be initiated by the Beneficiary PSP and send to BCSM. 7. BCSM forwards either the negative (camt.029) or positive response (pacs.004) to OCSM. 8. OCSM forwards the response from the recall request back to the Originator PSP. 9. Originator PSP provides the response back to the Originator.

22 The processing logic for each actor in the chain is explained in the diagram below Recall Message Flow Originator Originator PSP OCSM BCSM Beneficiary PSP Beneficiary Initiation of Credit Transfer Generation of SCTInst (pacs.008) pacs.008 SCTInst (pacs.008) pacs.008 SCTInst (pacs.008) pacs.008 SCTInst (pacs.008) Provision of availability of Funds Funds available Positive Response Flow Negative Response Flow Recall Flow Original Flow (simplified) Originator Response Originator Response Funds available 9d 8e 8d Initiation of Recall 1 Response to Originator Response to Originator 9c 8c Response to SCTInst (pacs.002) Generation of Recall of SCTInst (camt.056) Negative Response to Recall (camt.029) Positive Response to Recall (pacs.004) camt.056 pacs.002 pacs.004 Validation of camt.056 Yes Generation of Recall of SCTInst (camt.056) Response to SCTInst (pacs.002) 3a No camt.056 Positive Response to Recall (pacs.004) Generation of Negative Response t0 Recall (camt.029) pacs.002 Validation of camt.056 Yes Generation of Recall of SCTInst (camt.056) Response to SCTInst (pacs.002) 4a No camt.056 Positive Response to Recall (pacs.004) Generation of Negative Response t0 Recall (camt.029) pacs camt.029 8b 9b 3b Negative Response to Recall (camt.029) pacs.004 camt.029 8a 9a 4b Negative Response to Recall (camt.029) pacs.002 Validation of camt.056 No 5b Generation of Negative Response t0 Recall (camt.029) pacs Yes No Start of Investigation 7 Recall accepted Yes 8 Generation of Recall (pacs.004) 5a Resolution of Investigation 6 Yes 7a Funds reversed

23 Note: Original payment flow (simplified) not described The processing steps are as follows: 1) The Originator PSP initiates a Recall within 10 business days of the original payment. This can be either based on the Response to the SCT Inst (pacs.002) or independent any time after the original pacs.008 was sent. 2) Originator PSP generates the Recall of SCT Inst (camt.056) and forwards the message to OCSM. 3) OCSM validates the receive Recall (camt.056) and either accepts it or rejects it. 3a) In case of an accept OCSM generates the Recall of SCT Inst (camt.056) message and forward it to BCSM. 3b) In case of a reject OCSM generates a negative response back to the Originator PSP. 4) BCSM validates the Recall of SCT Inst (camt.056) and either accepts or rejects it 4a) In case of an accept BCSM generates a Recall of SCT Inst (camt.056) message and sends it to the Beneficiary PSP. 4b) In case of a reject BCSM generates a negative response (pacs.002) and sends the negative response back to OCSM. 5) The Beneficiary PSP validates the Recall of SCT Inst (camt.056) and either accepts or rejects it 5a) In case of an accept the Beneficiary PSP starts an investigation and forward this investigation request to the Beneficiary (the form and messages are outside of the EACHA specification). 5b) In case of a reject the Beneficiary PSP generates a negative response (camt.029) back to BCSM. 6) The Beneficiary informs the Beneficiary PSP of the outcome of the investigation 7) The Recall of SCT Inst was either accepted or rejected. In case of reject step 5b) for the generation of the reject of recall (camt.029). 7a) In case of an accept the Beneficiary PSP reverse the funds (re-debit) the account of the Beneficiary. Recall Accept 8) In case of acceptance generation of the Positive Response to Recall (pacs.004) with the original payment details and forward it to BCSM 8a) BCSM receives the Positive Response to Recall and forwards it to OCSM. BCSM provides the information of the original payment and the information of the reconciliation cycle in the message. 8b) OCSM receives the Positive Response to Recall and forwards it to the Originator PSP 8c) Originator PSP receives the Positive Response and generates the response to the Originator 8d) The Originator PSP makes the funds available to the Originator 8e) Originator receives the response based on the Positive Response to Recall of SCT Inst. Note: step 8c) to 8e) depends on the Originator PSP how to communicate the Recall to the Originator Recall Reject 9) Beneficiary PSP generates the Negative Response to Recall (camt.029) and forwards it to BCSM 9a) BCSM receives the Negative Response to Recall (camt.029) and forward it to OCSM. 9b) OCSM receives the Negative Response to Recall (camt.029) and forward it to the Originator PSP. 9c) Originator PSP receives outcome of the Recall of SCT Inst and generates the response to the Originator.

24 9d) Originator receives the response based on the Negative Response to Recall of SCT Inst. Note: step 9c) and 9d) depends on the Originator PSP how to communicate the Recall to the Originator Investigation message The investigation procedure is optional. It may be sent by the Originator PSP (OB) if they do not receive a response a response within the maximum time permitted (e.g. 25 seconds). The diagram below summarises the processing flow. 1. The Originator initiates a credit transfer initiation message to the Originator PSP, using either a pain.001 or similar (proprietary) message in accordance with an agreement with its PSP. 2. Based on the credit transfer initiation message, the Originator PSP sends a SCT Inst (pacs.008) to OCSM. 3. OCSM forwards the SCT Inst (pacs.008) to BCSM. 4. BCSM itself forwards the SCT Inst (pacs.008) to the Beneficiary PSP. 5. The Beneficiary PSP receives the SCT Inst. 6. The Originator PSP does not receive the confirmation of the SCT Inst and starts and investigation after 25 seconds. The investigation message (pacs ) is forwarded to OCSM. 7. OCSM validates the investigation message and if the original SCT Inst payment was received OCSM forwards the investigation message to BCSM. In the case that the SCT Inst was not received by OCSM, it provides the response back to the Originator PSP. 8. BCSM validates the investigation and sends response to investigation (pacs.002) back to OCSM. 9. The BCSM sends response to investigation (pacs.002) to OCSM 10. OCSM forwards the response to the Originator PSP. 1 Message type is not yet approved in ISO Page 24 of 45

25 The processing logic for each actor in the chain is explained in the diagram below.

26 Note: Original payment flow (simplified) not described The processing steps are as follows: 1) Originator PSP has not received a response to the original SCT Inst after 25 seconds. 2) The Originator PSP initiates an investigation (pacs.028) and forwards it to OCSM. 3) OCSM validates the investigation and evaluates if the original SCT Inst was received. 3a) In case of non-receipt of the original SCT Inst OCSM sends the response to the investigation (pacs.002) back to the Originator PSP with the associated reject code (code AG09) for non-receipt of original payment. 3b) In case of receipt of the original SCT Inst OCSM validates if it had received a response to the original SCT Inst. 3c) In case the response to the original SCT Inst was received OCSM re-sends the response back to the Originator PSP 3d) In case the response was not received from BCSM, OCSM forwards the investigation message to BCSM. 4) BCSM validates the investigation and evaluates if the original SCT Inst was received. 4a) In case of non-receipt of the original SCT Inst (pacs.008) BCSM sends the response to the investigation (pacs.002) back to OCSM with the associated reject code (code AG09) for non-receipt of original payment. 4b) In case of receipt of the original SCT Inst (pacs.008) BCSM validates if it had received a response from BPSP to the original SCT Inst (pacs.002). 4c) In case the response to the original SCT Inst was received BCSM re-sends the response back to OCSM 4d) In case the response (pacs.002) was not received from the Beneficiary PSP the BCSM would have had a time-out with the associated response message (pacs.002). 4e) In case of time-out BCSM re-sends the negative response (pacs.002) back to OCSM. Response to Investigation 5a) In case the response from BCSM was based on non-receipt of the original SCT Inst OCSM forwards the response to the Originator PSP. 5b) The Originator PSP provides the response back to the Originator (non-receipt of original SCT Inst). Note: step 5b) depends on the Originator PSP how to communicate the reject back to the Originator. Response to original SCT Inst 6a) In case the response from BCSM was based on the original response to the SCT Inst or based on a time-out reject BCSM forwards (re-sends) the response to OCSM. 6b) In case the response from BCSM was based on the original response to the SCT Inst OCSM forwards the response to the Originator PSP. 6c) The Originator PSP provides the response back to the Originator according to the original response to the SCT Inst. Note: No Settlement will occur until the OCSM receives the response to the original SCT Inst Supplementary data rules and standards The EPC Rulebook and Implementation Guide specify the message standards to be used i.e. pacs.008, pacs.002, pacs.004, camt.056, camt.029, pacs.028. EACHA has added additional elements to some messages to produce the EACHA message set which is in Annex IV. This section specifies additional rules and standards in the EACHA message set needed to achieve interoperability.

27 Inter CSM Reconciliation Reference Inter CSM payment messages will carry a Reconciliation Reference that identifies the inter CSM reconciliation cycle. The reference will be used to reconcile the liquidity positions and the messages exchanged between CSMs (see section 3.4 for further details). The reference will be present in the following payment messages: Standard payment - pacs.008 Payment response pacs.002 Response to the recall camt.056 pacs.004 The reference will be 16 characters as follows Identity of CSM (positions 1-4): first 4 characters of the CSM s BIC Date of transfer (positions 5-10): yymmdd Reconciliation cycle, which must be unique within the day (positions 11-16): nnnnnn Validation of payment values CSMs will not validate the values in any of the SCT Inst payments messages. PSPs will validate payment amounts, including ensuring compliance with the scheme maximum value Reason codes Where a payment is rejected, the negative response message (pacs.002 FIToFIPaymentStatusReport) shall contain a reason code in the field StatusReasonInformation. The standard ISO codes as specified by EPC in the Implementation Guide will be used which include a number of new codes for SCT Inst. The use of the new codes is illustrated in the following examples. General errors occurring at the Beneficiary PSP (Creditor Agent) or at the Intermediary PSP or CSM (the Instructed Agent) AB09, AB10 Code AB09 will inform the Originator PSP (Debtor Agent) that an error occurred at the Beneficiary PSP (Creditor Agent). Code AB10 will inform the Originator PSP (Debtor Agent) that an error occurred at the CSM or other Intermediary agent (Instructed Agent).. Time-out at Beneficiary PSP (Creditor Agent) AB05 If the designated time is exceeded at the level of the Beneficiary PSP (Creditor Agent), the Beneficiary PSP has to reject the (instant) payment. Reason code AB05 informs the Originator PSP (Debtor Agent) that the Beneficiary PSP (Creditor agent) rejected the payment. Time-out at BCSM (Intermediary Agent) AB06 Page 27 of 45

28 If the designated time is exceeded at the level of a CSM (or other involved Intermediary Agent), the CSM (or other involved Intermediary Agent) has to reject the (instant) payment. Reason code AB06 informs the Originator PSP (Debtor Agent) that the CSM or other Intermediary Agent (Instructed Agent) rejected the payment. Beneficiary PSP (Creditor Agent) not available AB07, AB08 The Originator PSP (Debtor Agent) needs to be informed if the Beneficiary PSP (Creditor Agent) or CSM or other intermediary Agent (Instructed Agent) is not signed-on (i.e. not available). Codes AB07 and AB08 are used to inform the Originator PSP (Debtor agent) about this unavailability Beneficiary PSP (Creditor Agent) is suspended AG10, AG11 In case the Beneficiary PSP (Creditor Agent) is suspended for processing of Real Time Payments via a CSM or other Intermediary Agent (Instructed Agent), the Originator PSP (Debtor Agent) needs to be informed of this situation. Code AG10 (general) or AG11 (specific for Creditor Agent) can be used to address this situation. Page 28 of 45