HCT INST SCHEME RULEBOOK V2.0

Transcription

1 HCT INST SCHEME RULEBOOK V Budapest, Vadász utca 31. Telefon: (1) , (1) Fax: (1)

2

3 HCT INST SCHEME RULEBOOK V2.0

4 Issued by GIRO Zrt. GIRO Zrt. declares that the content of the present document in not final. GIRO Zrt reserves the right to change it unilaterally especially but not exclusively if change of legal conditions or any other circumstances require the modification of this document. Therefore, GIRO Zrt. explicitly excludes all liabilities for any material and non-material, direct and indirect damages arising in connection with the modification of this document that is used by persons who decide on business decisions making IT developments. GIRO Zrt. hereby grants the User the right to download this document on its computer, to store, print it in unlimited number, or use it for personal use, but only GIRO Zrt. is entitled to disclose, distribute, recompile, process, publish, modify, translate this document entirely or partly. User or any other person may exercise such rights exclusively on the basis of the written permission of GIRO Zrt. Permitting these rights does not imply the cancellation or withdrawal of the above liability exclusion from GIRO Zrt. HCT Inst Scheme Rulebook v2.0 Number of pages: 50 GIRO Zrt. Budapest,

5 Table of Contents 1. INTRODUCTION PURPOSE OF THIS DOCUM ENT REFERENCES, RELATED DOCUMENTS NATURE OF THIS DOCUME NT CHANGE HISTORY GENERAL OVERVIEW SERVICES PROVIDED BY GIROI NSTANT Basic function Ancillary functions SPECIFICS OF PROCESSI NG ACCORDING TO THE HTC INST SCHEME Types, identifiers and reasons of payment instructions PROCESS DIAGRAMS THE PROCESS OF AN ACC EPTED, FULFILLED HCT INST TRANSACTION GIROI NSTANT REJECTS THE I NSTANT PAYMENT TRANSACTION BENEFICIARY BANK REJECTS THE INST ANT PAYMENT TRANSACT ION BENEFICIARY BANK RESENDS THE ST ATUS REPORT AFTER TI MEOUT BENEFICIARY BANK RECEIVES A STATU S REPORT WITHOUT A P RECURSOR ORIGINATOR BANK SENDS AN INVESTIGATION ME SSAGE INAPPROPRIATE STATUS REPORT FROM BENEFICIARY S BANK ORIGINATOR BANK SENDS A RECALL, BENEFICIARY BANK ACCEPTS IT ORIGINATOR BANK SEND S RECALL, BENEFICIARY BANK RE JECTS IT APPENDICES APPENDIX: DATASETS APPENDIX: MAXIMUM EXECUTION TIME APPENDIX: HUNGARIAN SPECIALITIES APPENDIX: CONNECTION POSSIBILITIES APPENDIX: REPORTS APPENDIX: GLOSSARY Version: v1.0 Date: page I.

6 LIST OF FIGURES page II. Date: Version: v2.0

7 1. INTRODUCTION The GIROInstant (GIROInst) service continuously processes, clears and settles HCT Inst transaction 1 messages 24 hours a day and every Calendar Day of the year. In addition to the regulations detailed in the SCT Inst Scheme Rulebook 2 the HCT Inst Scheme Rulebook contains also the Hungarian specialties, the clearing and settlement processes in accordance with the related payment legal regulations. Whilst the SCT Inst Scheme describes only the processes and banking functions related to instant payments and only refers to the tasks of the CSMs, HCT Inst Scheme Rulebook also details the processes of clearing and settlement PURPOSE OF THIS DOCUMENT This document presents the rules, processes, standards and practical information necessary to ensure the interoperability of interbank instant payment transactions. Present document of HCT Inst Rulebook contains definitions of rules and obligations of the Scheme, gives reliable information on the functions of the Scheme, details the clearing and settlement processes REFERENCES, RELATED DOCUMENTS Identifier Title EPC 3 rules, standards EPC EPC SEPA INSTANT CREDIT TRANSFER (SCT INST) SCHEME RULEBOOK SEPA INSTANT CREDIT TRANSFER (SCT INST) SCHEME INTERBANK IMPLEMENTATION GUIDELINES 4 ISO standards ISO Financial Services Universal Financial Industry message scheme Related legislation 1 HCT Inst Instant Hungarian Credit Transfer, SCT Inst Scheme complemented with Hungarian specialities 2 SEPA INSTANT CREDIT TRANSFER (SCT INST) SCHEME RULEBOOK EPC version 1.1 Issue date: 18 October 2017 Date effective: 21 November European Payments Council 4 To help the IT development HCT Inst Message Implementation Guideline will contain the details of the structures and usability of standards Version: v1.0 Date: page 3.

8 MNB regulation Decree No 35/2017. of the Governor of the MNB Other documents HCT_INST_MIG v1.0_ Request To Pay Scheme Rulebook v2.0 Proxy Identifiers Scheme Rulebook v2.0 HCT_INST Message Implementation Guideline Liquidity management GIROInstant Liquidity management guideline V NATURE OF THIS DOCUMENT Present document is not a regulation. Any reference to the responsibilities, rights and obligations of either the GIRO Zrt. or the participant payment system providers and/or Direct Participants serves as information only. Responsibilities, rights and obligations of the participants are contained in the appropriate Service Contracts / General Business Conditions respectively CHANGE HISTORY Version Issue date Contents, main changes v First public release of HCT Inst Scheme Rulebook v Modifications according to banks remarks Deleting the roles of Sponsor and Sponsored banks Supplementary explanation and Figures of the balances of the collateral and settlement accounts Changing the chapter Glossary of Terms Introducing List of Changes v Modifications according to Decree of the Governor of the MNB Modifications according to banks remarks Correction of TYPOs v Edited for structure and content changes due to the specialties of the system to be implemented. page 4. Date: Version: v2.0

9 2. GENERAL OVERVIEW GIROInstant service operated by GIRO Zrt. as system operator is based on open standards. The processing does not need manual intervention (STP 5 ), instantly clears and settles individual credit transfer orders SERVICES PROVIDED BY GIROINSTANT BASIC F UNCTION Clearing and settlement of payment transactions according to HCT Inst payment scheme Clearing and settlement is a) pre-funded, b) continuous (every day of the year), c) real time, d) credit transfer, e) carried out using the balance of the participant s individual direct settlement accounts within GIROInstant, using the balance as collateral on the MNB collateral accounts ANCILLARY F UNCTI ONS Proxy identifiers (Secondary account identifiers) Information on handling and processing secondary account identifiers can be found in a separate Rulebook. Clients of financial intermediaries can initiate instant payment transactions using the secondary identifier, however the transfer message has to be submitted by the intermediary to GIROInstant using the IBAN format and the accompanying bank identifier. Request to pay Information on request to pay transactions can be found in a separate Rulebook SPECIFICS OF PROCESSI NG ACCORDING TO THE HTC INST SCHEME TYPES, IDENTIFIERS A ND REA SONS OF PAYME NT INST RUCTI ONS Type: original instruction (transfer) or post-transfer ( R- ) transaction. The message identifier determines whether the message is of a transfer or a notification type: o pacs.nnn instruction modifying the bank s balance or a notification of balance change (payment clearing and settlement), o camt.nnn notification not modifying the bank s balance (cash management) 5 Straight Through Processing Version: v1.0 Date: page 5.

10 Additional information needs to be provided in case of post-transfer ( R- ) transactions o reference to the precursor transfer instruction, o reason for transfer initiation missing final status report (initiating Direct participant), beneficiary Direct participant s confirmation regarding the transfer s - fulfilment, the availability of cash (immediate or at a later time) for the beneficiary (ACSC or ACWC) - rejection (RJCT and the reason for rejection) initiating Direct participant s or the customer s reason for recall, beneficiary Direct participant s notification regarding the recall s - fulfilment and the return of funds - rejection of recall and the reason for rejection The GIROInstant service checks the validity of the reason o in the recall message submitted by the initiating Direct participant and o in the response messages sent for the recall instruction by the beneficiary Direct participant. In case of an invalid reason the particular instruction will be rejected with the reason: invalid reason (HU76). does not check o the reason code given by the beneficiary Direct participant in the (positive or negative) response message. The beneficiary direct participants can use the rejection codes agreed between banks bilaterally and/or the ISO20022 rejection codes, as well as the positive notification codes of ASCS and/or ACWC o the validity of data of the original transfer instruction referenced in the recall and the recall response messages, does not pair the data of the R- transaction with the referenced original. It is the responsibility of the Direct participant submitting the R- transaction to reference each and every data of the original transaction properly as required by the standard. Below are several rejection codes as required by the ISO standard type message originator / response / reason name / id sender payment pacs.008 payer / sender Direct participant status message positive response pacs.002 beneficiary Direct participant transferred amount is available for the client - immediately: ACSC page 6. Date: Version: v2.0

11 - at a later time: ACWC status message negative response (rejection) pacs.002 beneficiary Direct participant Payment is rejected: RJCT, because the beneficiary s - account is invalid: AC03 - account is blocked: AC06 - account is closed: AC07 - account cannot accept this type of transaction: AG03 - deceased: MD03 recall camt.056 payer / sender Direct participant payer / sender client l - duplicated message: DUPL - technical problem: TECH - suspected fraud: FRAD - recall initiated by customer: CUST - invalid amount: AM09 - incorrect IBAN: AC03 recall fulfilment, pacs.004 transfer beneficiary s - return of funds after recall: FOCR return of funds Direct participant (Following Cancellation Request) rejection of recall camt.029 transfer beneficiary s Direct participant recall request rejected: RJCR, because - beneficiary customer rejected the repayment: CUST - legal requirement: LEGL - recalled funds have already been returned: ARDT - account closed: AC04 - lack of funds: AM04 - no response from customer regarding recall request: NOAS - no transfer arrived referred in the recall request: NOOR investigation pacs.028 payer / sender Direct GIROInstant message participant - resends the final status report, or -notifies that there was no incoming transfer with such reference: NOOR final status message payment process completed pacs.002 GIROInstant Error / unable to process / not forwarded transfer: RJCT - sender Direct participant lack of coverage: AM04 - no unique identifier: AM05 - invalid currency: CURR - invalid amount: AM01 / AM12 (fillér > 0) - too late message arrival (compared to timestamp): AB06 - invalid timestamp: DT01 Note: this table only lists a handful of rejection reasons as an example Detailed verification conditions and rejection reasons can be found in the HCT_INST MIG. Correct, transfer forwarded to beneficiary - in case the beneficiary bank responded within time limit - in case the response is valid and can be processed then the response code the beneficiary bank sends - in case the response cannot be processed then thee reason is: timeout AB05 (sender Direct participant) TM01 (beneficiary Direct participant) - beneficiary bank s response arrives after timeout processing of payment has finished due to the timeout: Version: v1.0 Date: page 7.

12 AB05 (sender Direct participant) TM01 (beneficiary Direct participant) Note: both parties (sender and beneficiary Direct participants) receive the message. response regarding not acknowledged messages - GIROInstant the message sender is notified in a SOAP message, in case of not processable messages, where the message body only contains invalid <message type> for example in the following cases: - wrong format (XSD), - invalid characters, - received from unauthorised endpoint page 8. Date: Version: v2.0

13 3. PROCESS DIAGRAMS The following section presents an overview of the message flows describing the logic behind the individual steps as well as their roles in clearing and settlement. The diagram below depicts the schematics of a successful message flow. Originator 1. HCT Inst Instruction 7. HCT Inst transaction was not successful Originator bank $ HCT Inst transaction Clearing function of GIROInst HCT Inst transaction 6. 4 Confirmation message (transaction successful or not) Confirmation message (transaction successful or not) Beneficiary 5. bank Makes funds instantly $ available Beneficiary III. Notification of funds made available I. Notification of confirmation message received II. Notification of funds made available Settlement function of GIROInst/VIBER Figure 1. HCT Inst processing Logic diagram of a successful message flow Process steps: 1. The Originator Bank receives an instant payment instruction from the Originator. The Originator Bank carries out the necessary steps to prepare for the execution of the instant payment: following receipt of the transaction and user s authentication it generates the timestamp, validates the instruction and reserves the amount on the client s account. As a final step it creates the HCT Inst transaction. Originator Bank instantly informs the Originator about the result of the preparation. In case of failure (e.g. erroneous order, lack of liquidity) the credit transfer will not be executed. 2. The Originator Bank instantly sends the HCT Inst transaction message to the GIROInstant. Via this message, the Originator Bank gives the authorization to GIROInst for reserving funds on its account in order to cover settlement obligation for the HCT Inst transaction. GIROInstant reserves as part of the clearing and settlement process - the amount of the transaction in the GIROInstant settlement account of the Originator Bank. 3. GIROInst forwards the HCT Inst transaction message to the Beneficiary Bank. Due to the reservation on the Originator Bank s account the Beneficiary Bank has settlement certainty for this HCT Inst transaction in case the Beneficiary Bank accepts the transaction for further processing. (There is no credit risk.) The Beneficiary Bank instantly verifies whether the amount of the HCT Inst transaction can be made available on the Beneficiary s account. 4. The Beneficiary Bank sends the confirmation message to the GIROInstant indicating that the Beneficiary Bank: Version: v1.0 Date: page 9.

14 has received the HCT Inst transaction, is able to instantly process the HCT Inst transaction (positive confirmation). 5. GIROInstant executes the clearing on the respective accounts; debits the Originator Bank (decreases the balance of the Originator Bank s account within GIROInstant by the amount reserved) and credits the Beneficiary Bank (increases the balance of the Beneficiary Bank s account within GIROInstant by the amount transferred), then it notifies both the sender and beneficiary of the execution. 6. The Originator Bank o debits its client s account (by the amount reserved in step 1), o notifies its client - according to the service contract between the bank and the client that the transferred amount has been made available to the beneficiary. The notification itself and the time needed for it is not part of the scheme. The Beneficiary Bank o instantly makes the received funds available to the Beneficiary right after receiving the settlement confirmation from GIROInstant (as a response to the positive confirmation message sent in step 4.), o notifies its client - according to the service contract between the bank and the client that the transferred amount is now available on the client s account. The notification itself and the time needed for it is not part of the scheme THE PROCESS OF AN ACCEPTED, FULFILLED HCT INST TRANSACTION The scheme applies the following principles which are to be respected by all scheme participants: 1. When the GIROInstant platform forwards a HCT Inst message to the Beneficiary Bank, the Beneficiary Bank has no credit risk exposure to the Originator Bank regarding the amount of the transaction. This settlement certainty is guaranteed by the coverage reservation function of the GIROInstant platform. When an Originator Bank sends a HCT Inst message to the GIROInstant platform then at the same time the Originator Bank authorizes the GIROInstant platform to reserve the amount on its account held at GIROInstant thereby securing the coverage to clear and settle the HCT Inst transaction. 2. It is the responsibility of the Beneficiary Bank to confirm the acceptance or rejection of the HCT Inst transaction towards the Originator Bank. 3. The Originator Bank finalizes the transaction and debits the paying party s (originator) account based on the positive confirmation provided by the Beneficiary Bank and received through GIROInstant. In case of a negative confirmation the Originator Bank releases the amount reserved on the paying party s account. page 10. Date: Version: v2.0

15 The diagram below describes the steps of an accepted and fulfilled HCT Inst transaction process flow. Successfully processed HCT Inst transation and status report Debtor bank GIROInstant Creditor bank Prepare and send HCT Inst transation pacs.008 Receive, validate HCT Inst,allocate funds (Reservation on debtor account) pacs.008 Receive and process HCT Inst Settlement of the HCT Inst (debit debtor, credit creditor) pacs.002 Prepare and send positive status report Process positive final status report pacs.002 Prepare and send positive final status report pacs.002 Process positive final status report Figure 2. Successfully processed HCT Inst transaction and status report The GIROInstant platform receives and accepts the instant payment, carries out the necessary format and content validations, then checks the availability of fund coverage and reserves the amount on the Originator Bank s settlement account. Following these initial steps, it forwards the transaction to the Beneficiary Bank. If the Beneficiary Bank confirms the possibility of crediting the Beneficiary s account with a positive confirmation, then GIROInstant finalizes the transaction by debiting the Originator Bank s account and crediting the Beneficiary Bank s account, thereby completing the settlement between the financial service providers. Version: v1.0 Date: page 11.

16 3.2. GIROINSTANT REJECTS THE I NSTANT PAYMENT TRANSACTION GIROInstant rejects the payment transaction when it has not passed the format and content validation or the amount necessary for settlement cannot be reserved on the Originator Bank s account (lack of coverage). In this case a negative final status report is sent to the Originator Bank containing the appropriate reason code and the amount does not get reserved on the account of the Originator Bank. The diagram below describes the lifecycle of a transaction rejected by the GIROInstant platform. GIROInstant rejects HCT Inst Debtor bank GIROInstant Creditor bank Prepare and send HCT Inst pacs.008 Receive and validate HCT Inst HCT Inst is rejected Process negative final status report pacs.002 Prepare and send final status report Figure 3. Instant payment transaction rejected by GIROInstant page 12. Date: Version: v2.0

17 3.3. BENEFICIARY BANK REJECTS THE INSTANT PAYMENT TRANSACTION The Beneficiary Bank can reject the instant payment transaction due to formatting and/or content problems. Such content problem could be for example if the final beneficiary indicated in the transaction cannot be identified by the bank or in other words it does not know the beneficiary. A negative status report is sent to the central infrastructure as a notification containing the relevant reason code of the rejection. The processing of the instant payment transaction ends with the GIROInstant platform sending out final status reports to both the sending and the receiving participants about the failure of the transaction while releasing the reservation on the Originator Bank s account. The diagram below describes the lifecycle of a transaction rejected by the Beneficiary Bank. Creditor bank rejects HCT Inst Debtor bank GIROInstant Creditor bank Prepare and send HCT Inst transation pacs.008 Receive, validate HCT Inst,allocate funds (Reservation on debtor account) pacs.008 Receive and process HCT Inst Revert HCT Inst (cancel resevation on debtor account ) pacs.002 Prepare and send negative status report Process negative final status report pacs.002 Prepare and send final status report pacs.002 Process negative final status report Figure 4. - Instant payment transaction rejected by the Beneficiary Bank Version: v1.0 Date: page 13.

18 3.4. BENEFICIARY BANK RESENDS THE STATUS REPORT AFTER TIMEOUT If the Beneficiary Bank does not receive a final status report from the GIROInstant platform within the timeout limit, then the Beneficiary Bank may resend the original pacs.002 positive or negative status report to GIROInstant. The response from GIRO Instant depending on the final status of the transaction can be delivered again as a positive or negative confirmation message. Resending the status report is only allowed for the Beneficiary Bank if the timeout limit has been reached. It can be resent a maximum of five times containing only the original information that has been sent with the original message (original message, transaction ID and original content). The status of a transaction is always communicated by the GIROInstant to the banks participating in the transaction, the banks themselves cannot override it. The operators of the central infrastructure can monitor and investigate the status of a transaction at all times without resending the status report via the GIROInstant Operator Portal as well as analysing the reports. The diagram below describes the possibility of resending status reports by the Beneficiary Bank. Creditor bank optionally resends status report due to timeout Debtor bank GIROInstant Creditor bank Prepare and send HCT Inst transation pacs.008 Receive, validate HCT Inst,allocate funds (Reservation on debtor account) pacs.008 Receive and process HCT Inst Prepare and send positive/negative status report Lost or XSD invalid pacs.002 OR Process final status report pacs.002 Prepare and send final status report Lost pacs.002 Optional flow Detect attempted retransmission Resend positive/negative status report Resend positive/negative final status report Process positive/negative final status report Figure 5. Optional resending by the Beneficiary Bank page 14. Date: Version: v2.0

19 3.5. BENEFICIARY BANK RECEIVES A STATUS REPORT WITHOUT A P RECURSOR It can occur that the Beneficiary Bank did not receive or could not process the pacs.008 message. In this case GIROInstant rejects the transaction due to timeout and sends out the negative pacs.002 message to both banks participating in the transaction ORIGINATOR BANK SENDS AN INVESTIGATION MESSAGE If the Originator Bank does not receive a confirmation message by the timeout limit, they may use the - optional - investigation process defined by the scheme to clarify the status of the HCT Inst transaction. Resending the original instant payment (pacs.008) message is not allowed. If GIROInstant can find the transaction referenced in the investigation message (pacs.028), it will resend the related final status report. If the transaction cannot be located, the system generates a negative report. The Originator Bank may send an investigation message only after timeout, and not more than 5 times. The operators of the central infrastructure have the opportunity to investigate the status of the transaction without resending it at any time on the Operator Portal, or by analysing the reports. The diagram below describes the process of Originator Bank sending investigation message after timeout. Debtor bank sends status request Debtor bank GIROInstant Creditor bank Prepare and send HCT Inst Lost pacs.008 OR Lost pacs.002 Prepare and send a status request pacs.028 Search for the original HCT Inst Process positive/ negative final status report pacs.002 Send positive/ negative final status report Figure 6. Originator Bank sends investigation message after timeout Version: v1.0 Date: page 15.

20 3.7. INAPPROPRIATE STATUS REPORT FROM BENEFICIARY S BANK Status reports sent by the Beneficiary bank that are not applicable are not processed further. Such reports include status reports sent via an unknown or not previously defined communication channel, reports blocked during a security check and reports that cannot be matched with a previous instant payment. The above instances require manual investigation. Messages that do not correspond to XSD validation or contain invalid characters initiate SOAP replies which only indicate inaccuracy. The transaction will be failed due to timeout, GIROInstant notifies both banks about the failure in final status reports. The messages are retrievable on the Operator Portal ORIGINATOR BANK SENDS A RECALL, BENEFICIARY BANK ACCEPTS IT When GIROInstant has sent the final status report the instant payment is considered final. A recall is when Originator Bank wishes to recall a previously settled HCT Inst transaction. A recall may only be initiated by Originator Bank, either on customer s request or of own accord. Originator Bank may initiate a recall based on the following reasons: duplication (error code: DUPL) erroneous HCT Inst transaction(s) due to technical problem (error code: TECH) HCT Inst transaction possibly related to fraud (error code: FRAD). Beneficiary Bank has 30 days to reply to a HCT Inst recall initiated by Originator Bank within 30 days after payment. Originator Bank may recall a transaction based on customer request for the following reasons: customer transferred the wrong amount (error code: AM09) customer specified wrong account to credit (error code: AC03) other reason, not specified by customer (error code: CUST) A recall by Originator Bank s customer may be initiated by the last day of the 13th month after the original transaction the latest. Beneficiary Bank has 30 days to reply. The original Originator Bank sends a recalling camt.056 message to GIROInstant. GIROInstant validates the message and forwards it to the original Beneficiary Bank. This step in the process does not involve any blocking of funds or change in liquidity. The original Beneficiary Bank has 30 days to decide (coordinating with customer if necessary) whether to approve or reject the recall. If original Beneficiary Bank approves the recall, a pacs.004 return transfer message is sent in reply to the recall. This message generates money movement where participant banks reverse roles: the original Beneficiary Bank will be the sender and the original Originator Bank will be the addressee. The reverse transfer is processed instantly by GIROInst, the account of the sender is debited, addressee is credited and the reverse message is forwarded to the original Originator Bank. page 16. Date: Version: v2.0

21 Sender (the original Beneficiary Bank) receives a status report about the success of the reverse transfer from GIROInstant (be it successful or not). The following diagram shows the recall process, if original Beneficiary Bank accepts recall. Original Creditor bank accepts the recall Debtor bank GIROInstant Creditor bank Prepare and send a recall camt.056 Validates recall Process rejection status report (validation result) pacs.002 if rejected if accepted Process status report (forwarded) pacs.002 Forwards the recall camt.056 Receive and process recall Receive and process return pacs.004 Validate transfer liquidity pacs.004 Prepare and send return Not expected to be sent immediately pacs.002 Process status report (validation result) Figure 7. Original Beneficiary Bank accepts recall Version: v1.0 Date: page 17.

22 3.9. ORIGINATOR BANK SENDS RECALL, BENEFICIARY BANK REJECTS IT If Beneficiary Bank rejects the recall, a camt.029 (recall rejected) message is sent in reply. GIROInstant validates and forwards the rejection message to original Originator Bank for further processing. In reply to a rejection of a recall - depending on GIROInstant s validation - a status report (positive or negative) is sent to the original Beneficiary Bank. The report is in pacs.002 format, to the file with the inappropriate format (XSD or character error) the system sends a SOAP message. The following diagram shows the process of recall when Beneficiary party rejects recall. Original Creditor bank rejects the recall Debtor bank GIROInstant Creditor bank Prepare and send a recall camt.056 Validates recall Process rejection status report (validation result) pacs.002 if rejected if accepted Process status report (forwarded) pacs.002 Forwards the recall camt.056 Receive and process recall Receive and process reject camt.029 Validate and forward reject camt.029 Prepare and send reject Not expected to be sent immediately pacs.002 Process status report (validation result) Figure 8. Original Beneficiary Bank rejects recall page 18. Date: Version: v2.0

23 APPENDICES 1. APPENDIX: DATASETS INTERBANK DATASET (DS-02) Identification Name Description DS-02 Interbank dataset This dataset describes the content of the interbank payment message (mandatory unless otherwise indicated) Rules: Where an Originator has provided information in a specific payment transaction relating to an optional DS-02 field (with the exception of AT-45), this field will be populated in the interbank payment message, subject to any overriding legal/regulatory requirements. If the Originator and the Originator s bank agreed otherwise in the bankside processes then the Originator s bank can send out the DS-02 message without populating the AT-45 to the Beneficiary s bank. Attributes Attributes Usage rules AT-01 Originator account IBAN number AT-02 Originator name AT-03 Originator address (optional) AT-04 Amount of the HCT Inst in HUF AT-05 Remittance Information (optional) AT-06 BIC code of the Originator Bank AT-08 Name of the Originator Reference Party (optional) Originator s settlement account (IBAN Only), to be debited in case of HCT Inst. Name of the owner of the payment account to be debited. Address of the owner of the payment account to be debited. Sum of the transaction that contains the HUF currency code as well as the value in whole numbers to two digits accuracy, but after the comma only 0 is allowed as a value. The remittance information can only be 140 characters long according to the EACT 6 standard. The standard determines those items that allow the automated processing of payments between business partners. Further information regarding the standard can be found at this website: eact_standard_for_unstructured_remittance_information To store the dataset described in the standard, a 140 character unstructured narrative field has to be used. Code created according to ISO 9362 and registered by SWIFT. The Originator reference party is the party making the payment in reality and is representing or is in connection with the Originator. Any reference to the real payer in connection with any payment does not mean that this party would be the originator or would wish to pay or they would be obliged or authorized to pay under contract whatsoever. It is not the owner of the account to be debited, it is a third party, the partner of the beneficiary who pays to the beneficiary. 6 European Association of Corporate Treasurers Version: v1.0 Date: page 19.

24 AT-09 Identification code of the Originator Reference Party (optional) AT-10 Originator identification code (optional) AT-20 Beneficiary account IBAN AT-21 Beneficiary name AT-22 Beneficiary address (optional) AT-23 BIC code of the Beneficiary Bank AT-24 Beneficiary identification code (optional) AT-28 Name of the Beneficiary Reference Party (optional) AT-29 Identification code of the Beneficiary Reference Party (optional) AT-40 Identification code of the HCT Inst Scheme AT-41 Originator s reference of the HCT Inst Transaction (EndtoEndId) AT-42 Settlement Date of the HCT Inst transaction AT-43 Originator Bank s reference number of the HCT Inst transaction message (TxId) AT-44 The purpose of the HCT Inst Transaction (optional) Code determined by the Originator, that is passed on unaltered to the Beneficiary. Code determined by the Originator, that is passed on unaltered to the beneficiary. International bank account that serves as unique identifier for the client s payment account at a particular financial institution according to the ISO standard. Beneficiary name determined by the Originator. Beneficiary address determined by the Originator. Mandatory attribute in the DS-02 dataset Code determined by the Originator Name of the person in contact with the Beneficiary receiving the payment. The real Beneficiary is the person who represents or is in contact with the person on whose behalf the Beneficiary receives the payment. Any reference to the real Beneficiary in connection with any payment does not mean that this party would be the Beneficiary or they would be obliged or authorized under contract whatsoever. It is not the owner of the account to be credited, it is a third party, the partner of the Beneficiary who receives the payment. Code determined by the Originator, that is passed on unaltered to the Beneficiary. This code distinguishes the HCT Inst transaction from every other scheme transaction. Originator s unique identifier of the HCT Inst transaction for the use of the Originator Bank (EndToEndId). This reference is passed on during the entire process of handling the HCT Inst transaction from start to end. It is a reference that can be used by any of the participants in the chain (e.g. recall, return transfer or investigation). The originator cannot be asked to provide any other reference regarding the identification of the HCT Inst transaction. The originator has to determine the inner structure of the message, however the only requirement is that the reference should be meaningful to the originator. The date when the obligations regarding the transfer between the Originator Bank and the Beneficiary Bank are fulfilled. The message from the Originator Bank contains the requested settlement date while the message sent to the Beneficiary Bank contains the effective settlement date. Reference provided by the payer s bank that is passed on to the Beneficiary bank without alteration (TxId). The purpose of the HCT Inst transaction is the information on the legal title behind the goal of such a transaction. page 20. Date: Version: v2.0

25 AT-45 The category purpose of the HCT Inst transaction (optional) AT-50 Time Stamp of the HCT Inst transaction The category purpose is the information on the overall legal title of the transaction that can serve various purposes: the Originator or the Originator bank can offer specific processing services based on this. This information can only be forwarded to the Beneficiary bank on the request of the paying party. The time stamp determines the beginning of the instruction processing and this has to be included in the message by the Originator bank. The time stamp has to be represented to one thousands second accuracy. Technical characteristics Remarks From a business perspective, interbank HCT Inst transactions are always considered to be single payments, each containing one Originator Payment Account and one Beneficiary Payment Account. These attributes reflect business requirements and do not prescribe fields in the HCT Inst Message Implementation Guideline. CONFIRMATION MESSAGE (DS-03) Identification Name Description DS-03 Confirmation Message This dataset describes the content of a positive or a negative confirmation message on an HCT Inst transaction message to be sent instantly to the Originator Bank. This dataset is also used when the GIROInst has to send instantly a negative confirmation message to the Beneficiary Bank in case GIROInst has not received any confirmation message from the Beneficiary Bank on the initial HCT Inst transaction within the time-out deadline after the timestamp. Attributes of a negative confirmation message (RJCT code) Attributes AT-06 BIC code of the Originator Bank AT-41 Originator s reference of the HCT Inst transaction message (EndToEndId) AT-43 Originator Bank s reference number of the HCT Inst transaction message (TxId) AT-R1 R message type AT-R2 Identification of the type of party initiating the R message AT-R3 Reason code for non-acceptance of the HCT Inst Transaction Usage rules BIC code of the Originator Bank Originator s reference of the HCT Inst transaction message Originator s reference of the HCT Inst transaction message Possible values: Rejection Recall Possible values for Rejection messages: CSM/GIROInst Beneficiary bank Possible values for Recall messages: Originator Originator bank Reasons for rejection by the Beneficiary bank: Time-out. The amount is greater than the maximum limit set for the HCT Inst transaction, or the specific receipt limit set by the Beneficiary bank Invalid account address Blocked bank account, no reason given Closed bank account Version: v1.0 Date: page 21.

26 Bank account identification invalid (i.e. invalid IBAN or the account does not exist) Bank identifier is invalid (i.e. invalid BIC number) Beneficiary deceased According to the instruction of the beneficiary Transaction forbidden on this type of account Duplicated payment Operation / transaction code invalid, invalid format Regulatory reason No reason given Positive confirmation message AT-R4 Specific reference of the party initiating the Rejection (Status ID) AT-06 BIC code of the Originator Bank AT-41 Originator s reference of the HCT Inst Transaction (EndToEndId) AT-43 Originator Bank s reference number of the HCT Inst transaction message (TxId) AT-51 The Beneficiary Bank s reference of the HCT Inst transaction (status ID) This reference is determined by the party initiating the HCT Inst transaction rejection, the message has to be forwarded to the Originator bank and optionally to the Originator. This information has to be sent out by the initiator of the rejection upon request by the Originator or the Originator bank to clarify the reason for rejection. BIC code of the Originator Bank sending out the positive confirmation message Originator bank s reference in the HCT Inst transaction message Originator bank s reference in the HCT Inst transaction message Beneficiary Bank s reference of the HCT Inst transaction that has to be relayed unaltered to the Originator bank. INVESTIGATION MESSAGE SENT BY THE ORIGINATOR BANK (DS-07) Identification DS-07 Name Dataset for the HCT Inst transaction status investigation sent by the Originator bank Description This dataset describes the content of the HCT Inst transaction status investigation message that the Originator Bank may send in case no confirmation message has reached the Originator Bank within 5 seconds after the time-out deadline. Attributes Attributes Usage rules AT-41 Originator s reference of the HCT Inst transaction message (EndToEndId) AT-43 Originator Bank s reference number of the HCT Inst transaction message (TxId) AT-50 Timestamp of the HCT Inst transaction Originator s reference of the message to be investigated Originator s reference of the message to be investigated The timestamp determines the beginning of the instruction processing and this has to be included in the message by the Originator bank. The timestamp has to be represented with millisecond accuracy. page 22. Date: Version: v2.0

27 RECALL (DS-05) Identification Name DS-05 Dataset of a Recall of a HCT Inst transaction Description This dataset contains the messages for description of the minimum information that an Originator Bank needs to make available to the Beneficiary Bank Attributes Attributes Usage rules An exact copy of the original Interbank payment dataset (DS-02), which is being recalled. AT-04 Amount of the HCT Inst in HUF Sum of the transaction that contains the HUF currency code as well as the value in whole numbers to two digits accuracy, but after the comma only 0 is allowed as a value. AT-48 Recall reason code AT-49 Additional Information to AT-48 Recall reason code AT-R2 Identification of the type of party initiating the R message AT-R6 Specific reference of the bank initiating the recall Determined by the Originator bank, initiating the recall. The Beneficiary bank uses this code to notify the Beneficiary about the reason of recall. Code values can be the following: duplicate HCT Inst transactions invalid due to technical problems HCT Inst transaction can be associated to fraud When the Originator bank uses the reason code fraud associated HCT Inst : further information is provided regarding the AT-48. The text has to be meaningful to the Beneficiary bank. The Beneficiary bank is not obliged to act based on the received information. Values regarding the recall message: Originator Originator bank This reference is determined by the bank initiating the HCT Inst recall. This recall message has to be relayed to the Beneficiary bank and optionally to the Beneficiary. The Beneficiary or the Beneficiary bank needs to quote this reference in any further message correspondence requesting more information. Remarks Except for AT-49, these attributes reflect business requirements and do not prescribe fields in the HCT Inst Message Implementation Guideline. Version: v1.0 Date: page 23.

28 RESPONSE TO A RECALL (DS-06) Identification Name Description Attributes of a positive response message to a recall Attributes of a negative response message to a recall Remarks DS-06 Response to a recall of an HCT Inst dataset This dataset contains the messages for the description for sending the response to a recall of an HCT Inst dataset. Attributes Usage rules An exact copy of the original interbank payment dataset (DS-02) which is being recalled. The GIROInstant does not do matching. AT-46 The returned amount of the positive This amount can be the same as AT-04, if there response to the Recall in HUF is no AT-47 present. If the fee of the positive response to a recall is populated in AT-47, then this amount equals to the difference of amounts in AT-04 and AT-47. Sum of the transaction that contains the value in whole numbers to two digits accuracy, but after the comma only 0 is allowed as a value. AT-47 The fee for the positive response to a Recall Sum of the transaction that contains the HUF in HUF (optional) currency code as well as the value in whole numbers to two digits accuracy, but after the comma only 0 is allowed as a value AT-R1 R message type This code represents the type of the return transaction in the transfer. The value can be: recall or rejection. AT-R2 Identification of the type of party initiating This attribute contains the originator type of a the R message recall or rejection message: Its content can be: Originator Originator bank AT-R6 Specific reference of the bank initiating the recall AT-R7 Settlement Date for the positive answer to Settlement date of the interbank fulfilment of the Recall the return transaction. An exact copy of the original Interbank payment dataset (DS-02) which is being recalled. AT-R5 Reason code for non-acceptance of the The following codes can be used: recall Beneficiary refuses to return the funds Legal reasons Account closed No coverage on bank account No response from beneficiary Original transaction hasn t arrived Funds have already been returned (returned transaction) These attributes reflect business requirements and do not prescribe fields in the HCT Inst Message Implementation Guideline. page 24. Date: Version: v2.0

29 REQUEST FOR RECALL BY THE ORIGINATOR (DS-08) Identification DS-08 Name Request for Recall by the Originator dataset Description This dataset contains the attributes describing the minimum information that the Originator Bank needs to make available in a Request for Recall by the Originator Attributes Attributes Usage rules An exact copy of the original Interbank payment dataset (DS-02) which the Request for Recall by the Originator relates to AT-52 Reason code for the Request for Recall by the Originator AT-53 specific reference of the Originator Bank for the Request for Recall by the Originator This code describes the reason of the recall initiated by the Originator. The Originator bank determines the code, based on the information provided by the Originator, that initiates the recall request The following codes can be used: Beneficiary account invalid unique identifier Invalid amount Upon request of the originator, no reason provided Request for status update. The reference is determined by the Originator Bank that initiates the request for recall regarding the original HCT Inst transaction launched by the Originator. This has to be relayed to the Beneficiary bank Remarks AT-54 Additional Information to AT-52 Reason The Originator Bank can use this attribute to code for the Request for Recall by the Originator provide additional information regarding AT-52. The text needs to be meaningful to the Beneficiary Bank that received the request by the Originator Bank, and they are obliged to take action based on this information. These attributes reflect business requirements and do not prescribe fields in the HCT Inst Message Implementation Guideline. In case the reason code Request for Status Update is used, an exact copy of the original Request for Recall by the Originator needs to be provided instead of the copy of DS-02. Version: v1.0 Date: page 25.

30 RESPONSE TO THE REQUEST FOR RECALL BY THE ORIGINATOR (DS-09) Identification Name Description Attributes of positive response message DS-09 Dataset for the response to the Request for Recall by the Originator. This dataset contains the attributes for describing the response from the Beneficiary Bank to a Request for Recall by the Originator Attributes Usage rules An exact copy of the original Interbank payment dataset (DS-02) which the Request for Recall by the Originator relates to Attributes of negative response message AT-53 specific reference of the Originator Bank for the Request for Recall by the Originator AT-55 Returned amount of the positive response to the Request for Recall by the Originator in HUF AT-56 Settlement date for the positive response to the Request for Recall by the Originator AT-58 Fee for the positive response to a Request for Recall by the Originator in HUF Attributes An exact copy of the original Interbank payment dataset (DS-02) which the Request for Recall by the Originator relates to AT-53 Specific reference of the Originator Bank for the Request for Recall by the Originator AT-57 Reason code for non-acceptance of the Request for Recall by the Originator The reference is determined by the Originator Bank that initiates the request for recall regarding the original HCT Inst transaction launched by the Originator. This has to be relayed to the Beneficiary bank Sum of the transaction that contains the HUF currency code as well as the value in whole numbers to two digits accuracy, but after the comma only 0 is allowed as a value. The date when the GIROInstant platform books the returned funds. Fee of the positive response to a recall (in case it is not zero).the value in whole numbers to two digits accuracy, but after the comma only 0 is allowed as a value. Usage rules The reference is determined by the Originator Bank that initiates the request for recall regarding the original HCT Inst transaction launched by the Originator. This has to be relayed to the Beneficiary bank Codes that determine the reason of the recall request initiated by the Originator: AT-59 Provision of all information available to file a legal claim to recover the funds in case of reason code a Kedvezményezett számlájának helytelen egyedi azonosítója meaning: Invalid identifier of the Beneficiary s account (optional) Codes to be used: Rejection by beneficiary Lack of coverage on bank account no response from Beneficiary Funds have already been returned (returned transaction). The Beneficiary Bank provides all information regarding the Beneficiary according to data protection rules. This provides all the information to the Originator needed to carry out legal action. (Optional attribute). page 26. Date: Version: v2.0

31 Remarks These attributes reflect business requirements and do not prescribe fields in the HCT Inst Message Implementation Guideline. Version: v1.0 Date: page 27.

32 2. APPENDIX: MAXIMUM EXECUTION TIME TIMESTAMP The timestamp helps to measure the maximum and the expected execution time of transactions, which all participants need to monitor. The timestamp is defined by the payment service provider of the paying party after accepting the instruction and validating the client. Execution time of the transaction starts when the instruction of the paying party has been accepted by the first payment service provider and when customer has been validated. Whichever of these two actions takes place later, that will be the start of the execution time in the timestamp (timed to the millisecond). This timestamp is shown on the HCT Inst instruction (see attribute AT-50). The timestamp means the starting time of the execution of the transaction. EXPECTED AND MAXIMUM EXECUTION TIME After validating the customer and specifying the timestamp the transaction goes from Originator Bank through GIROInstant to Beneficiary Bank. In the end Beneficiary Bank sends feedback if the crediting of the amount in question is possible in their system. If it is possible, GIROInstant settles the payment and notifies Beneficiary Bank about it. The timeframe of the above process is 5 seconds (Figure 10). Beneficiary Bank sends notification to Originator Bank if they accept or reject the transaction (positive or negative confirmations respectively). The timeframe to do this is also 5 seconds (Figure 11). positive confirmation: the amount can be made available for beneficiary customer immediately (ACSP confirmation code) or later, if the account of the beneficiary signals an account with a currency outside the EEA (ACWC confirmation code); The transferred amount needs to be made available to beneficiary customer immediately after receiving the GIROInstant final status report about the crediting of the settlement account of the Beneficiary Bank (in the case of an ACSP confirmation code); negative confirmation: the beneficiary account specified in the transfer instruction cannot be credited (confirmation code RJCT and reason for rejection); Originator Bank needs to notify Originator customer about a negative confirmation (rejection) immediately. Only transactions rejected for regulatory reasons are an exception to immediate notification (e.g. rejection due to possible money laundering). page 28. Date: Version: v2.0

33 Final status of HCT Inst order Interbank space Execution time Initiation execution time GIRO Zrt. HCT Inst Scheme Rulebook v2.0 The following diagram shows the process steps of the expected execution time of the HCT Inst transaction. HCT Inst process flow MAXIMUM EXECUTION TIME Maximum time Originator Interbank Originator bank space Beneficiary bank Beneficiary GIROInst Submits HCT Inst instruction Authentication+ Adding time stamp HCT Inst instruction is not valid Validation+fund check HCT Inst instruction is valid Reserves amount and prepares HCT Inst transation Up to 5+5 sec. Routes Mandatory negative confirmation message Validation is ok? N Reject the HCT Inst transation Y Receipt of HCT Inst transation and validation check Receipt of negative confirmation Transmits negative conf. message N Valid HCT Inst transation? Receipt of positive confirmation Y SETTLEMENT Receipt of positive confirmation message (about settlement) Sends an acknowledgement/ formal notification Receipt of positive confirmation message (about settlement) Y Funds available Funds reservation lifted Optional information Instruction has failed! Mandatory information Funds are available! NOT defined by the scheme Debit on payment account Optional information Successful instruction! Figure 9. Flowchart of the maximum execution time Version: v1.0 Date: page 29.

34 Final status of HCT Inst order Interbank space Execution time Initiation execution time GIRO Zrt. HCT Inst Scheme Rulebook v2.0 ACTIONS OF THE 5+5 SECONDS The following two flowcharts show the actions in the first and second 5 seconds, based on the previous chart. HCT Inst process flow MAXIMUM EXECUTION TIME first 5 seconds Maximum time Originator Interbank Originator bank space Beneficiary bank Beneficiary GIROInst Submits HCT Inst instruction Authentication+ Adding time stamp HCT Inst instruction is not valid Validation+fund check HCT Inst instruction is valid Reserves amount and prepares HCT Inst transation First 5 sec. Routes Mandatory negative confirmation message Validation is ok? N Reject the HCT Inst transation Y Receipt of HCT Inst transation and validation check Receipt of negative confirmation Transmits negative conf. message N Valid HCT Inst transation? Receipt of positive confirmation Y SETTLEMENT Receipt of positive confirmation message (about settlement) Sends an acknowledgement/ formal notification Receipt of positive confirmation message (about settlement) Y Funds available Funds reservation lifted Optional information Instruction has failed! Mandatory information Funds are available! NOT defined by the scheme Debit on payment account Optional information Successful instruction! Figure 10. Flowchart of the expected execution time - first 5 seconds page 30. Date: Version: v2.0

35 Final status of HCT Inst order Interbank space Execution time Initiation execution time GIRO Zrt. HCT Inst Scheme Rulebook v2.0 HCT Inst process flow MAXIMUM EXECUTION TIME second 5 seconds Maximum time Originator Interbank Originator bank space Beneficiary bank Beneficiary GIROInst Submits HCT Inst instruction Authentication+ Adding time stamp HCT Inst instruction is not valid Validation+fund check HCT Inst instruction is valid Reserves amount and prepares HCT Inst transation Routes Mandatory negative confirmation message Validation is ok? N Reject the HCT Inst transation Y Receipt of HCT Inst transation and validation check Receipt of negative confirmation Transmits negative conf. message N Valid HCT Inst transation? Second 5 seconds Receipt of positive confirmation SETTLEMENT Y Receipt of positive confirmation message (about settlement) Sends an acknowledgement/ formal notification Receipt of positive confirmation message (about settlement) Y Funds available Funds reservation lifted Optional information Instruction has failed! Mandatory information Funds are available! NOT defined by the scheme Debit on payment account Optional information Successful instruction! Figure 11. Flowchart of the expected execution time - second 5 seconds Version: v1.0 Date: page 31.