Operating Rules for Cross Currency Payments using AFAQ Service
No: 42068309 Date(g): 5/5/2021 | Date(h): 24/9/1442 Status: In-Force In reference to the Gulf Instant Payment Settlement System "AFAQ", which aims to provide a unified environment for financial transactions between the Gulf Cooperation Council (GCC) countries and offer financial services to customers of all categories by enabling and facilitating cross-border transfers in a fast, secure, and efficient manner. This system serves as a tool to ensure the flow of payments in the local banking sector and supports bilateral and multilateral trade activities, contributing to enhancing economic cooperation and integration among the GCC member states.
Attached is the document regarding the "Operating Rules for Cross Currency Payments using AFAQ Service for the local banking sector".
For your information and implementation as of the current date.
1. Definitions
In this Operating Rules, the following terms will have the following meanings except as the context may otherwise require:
Term Definition SAMA Saudi Central Bank. NCB National Central Bank (NCB) or Monetary Authority of each of the six GCC countries. GPC Gulf Payments Company. AFAQ Arabian Gulf System for Financial Automated Quick Payment Transfer Confirmed
Exchange RateThe exchange rate to be used for conversion between a pair of GCC currencies. This rate is confirmed and guaranteed by the relevant NCBs on every Business Day for use throughout that Business Day. Cross-currency payment Payment from the bank of one country to a bank from another country through the GCC RTGS Central Component. The Paying Bank sends funds in its country domestic currency, and the Receiving bank receives funds in its country domestic currency. CSM Country Specific Model. Domestic RTGS The RTGS system operated by each NCB for processing domestic and eligible cross-currency cross-border payments.
The Domestic RTGS systems act in both Sending and Receiving mode. For clarity purposes in this OR references to the "Receiving Domestic RTGS" and "Sending Domestic RTGS" are used to illustrate various actions performed by these systems while they are acting in either Receiving or Sending mode.
AFAQ CC The Central Component (CC) of the AFAQ Service. OR Operating Rules. RPG Regional Payment Gateway. The RPG acts in both Sending and Receiving mode. Arbitrage The simultaneous buying and selling of securities, currency, or commodities in different markets or in derivative forms in order to take advantage of differing prices for the same currency or asset. 2. Introduction
2.1. General
The "Arabian Gulf System for Financial Automated Quick Payment Transfer" (AFAQ) is the Real Time Gross Settlement service for cross-currency cross-border payments between Gulf Cooperation Council (GCC) Countries; that is owned and managed by the National Central Banks (NCBs) of the six GCC countries (Kingdom of Saudi Arabia, United Arab Emirates, Kingdom of Bahrain, Sultanate of Oman, Qatar and Kuwait).
AFAQ Service is in line with the Charter of the Cooperation Council for the Arab States of the Gulf, which aims at achieving closer convergence and stronger links among the GCC countries, reaching advanced economic and financial integration, promoting collaboration, integration, interconnectedness and all aspects of cooperation among the GCC member states and their people at all levels.
2.2. Purpose
With the aim of Facilitating cross-border payments in the region, providing essential infrastructure to enable the on-going integration of financial markets across the GCC region, utilizing the advantages of real- time gross settlement, Encouraging closer financial and economic integration between the GCC countries; SAMA has implemented a Specific Model in which functions of the Domestic RTGS system for both Sending & Receiving cross-border payments will be performed at the AFAQ Service ‘s Central Component hosted technically by the Gulf Payments Company (GPC); While controlled, supervised & operated by SAMA according to the operating Rules.
2.3. Statuary Authority
Without prejudice to Saudi Central Bank "SAMA" rights under applicable laws and regulations, these Operating Rules are constituted by SAMA in exercise of the powers stipulated in the Saudi Central Bank Law dated 11/04/1442H (26/11/2020G); Designating SAMA as the competent authority to Establish, Develop & Operate national infrastructures for Payment, Clearing & Settlement systems; Issue rules, guidelines, and licenses; Control and Oversee Payment, Clearing & Settlement systems within its sphere of competence.
2.4. Scope
These Operating Rules will cover the following areas:
a) Key operational activities across cross currency payments using AFAQ Service; hereinafter referred to as "the Service",
b) Business Rules for access and eligibility of Direct Participants, suspension, termination and withdrawal of Direct Participants,
c) Payment Rules for eligible payments,
d) Business day timetable and calendar,
e) Claims and dispute management
f) Business continuity and contingency arrangements.
2.5. Amendment
SAMA may amend, replace or supplement the contents of these Operating Rules as it deems fit; in consultation with Participants. Such amendment will be duly notified to Direct Participants.
2.6. Compliance
Each Direct Participant will comply with these Operating Rules.
2.7. Charges
The Direct Participants will pay SAMA's charges for the use of the Service in accordance with the Service Charging Policy issued by SAMA, as amended by SAMA from time to time.
2.8. Controlled Documents
A list of controlled documents which delineates operations of the Service is included in APPX (1). The controlled documents set out the detailed system operations.
3. Direct Participants
3.1. Direct Participants Admission
SAMA may admit Direct Participants as members of the Service if in the opinion of SAMA they meet the qualifying criteria as defined by SAMA from time to time. A Direct Participant in the Service must be:
• Participating in the Saudi Arabian Riyal Interbank Express System (RTGS).
• Maintaining a current AFAQ's account in accordance with SAMA's banking conditions.
• Complying with legal, supervisory, technical & operational requirements communicated by SAMA.
• Signatory to the Agreement of Participation in the Service.
3.2. Suspension or Termination of Direct Participants
On notice to a Direct Participant, SAMA may in its discretion suspend a Direct Participant temporarily or terminate a Direct Participant permanently (in each case with immediate effect or as otherwise prescribed in the notice) if the Direct Participant fails to comply with the qualifying criteria defined by SAMA from time to time or if the Direct Participant is, or states that it is, or SAMA reasonably suspects that it may be insolvent or if Direct Participant's relevant licence is revoked or if the Direct Participant fails to comply with these Operating Rules or if, in the good faith opinion of SAMA, the continued membership of the Direct Participant may prejudice the Service or the other Direct Participants or is undesirable.
3.3. Withdrawal of Direct Participants
Subject to receiving a prior written consent of SAMA, Direct Participant may withdraw from the Service upon serving written notice to SAMA within a period not falling less than thirty 30 days prior to the proposed withdrawal date.
3.4. Obligations on Cessation
In case of cessation, the Direct Participant will remain liable for all its accrued and accruing obligations under these Operating Rules. SAMA may give directions as it sees fit to give effect to the suspension, termination or withdrawal of the Direct Participant, including without limitation the surrender of its rights, software and materials in respect of the Service and the continued use or non-use of the Service.
3.5. Notice
SAMA will as soon as practicable give the other Direct Participants notice of changes to or suspensions of a Direct Participant.
4. Systems & Operations
4.1. Overview of AFAQ Service's Architecture
The AFAQ Service is made up of the following components:
• Sending Domestic RTGS system,
• Sending Regional Payment Gateway (RPG),,
• Central Component,
• Receiving Regional Payment Gateway (RPG),
• Receiving Domestic RTGS system,
• Communications network linking all of the other components of the full system,
• In the case of the countries using the CSM, the functions of the Domestic RTGS system, for both Sending & Receiving cross-border payments, will be performed at the AFAQ Service CC. The service is technically hosted by GPC. The service is managed by the NCB of the country using the CSM as part of their Domestic RTGS services.
4.1.1 Sending Domestic RTGS
The Sending Domestic RTGS system, operated by that country's NCB, handles all communications with the Direct Participants in the sending country. It also deals with all aspects of the processing of outward cross- border payments in accordance with the OR of that country's Domestic RTGS system, including, message validation, accounting, verification of availability of funds on the account of the Sending Participant, debiting the account of the Sending Participant, crediting the account of the Receiving NCB and translation of the messages, if necessary, to the format required by the Sending RPG.
4.1.2 RPG
RPG’s main functions are to validate, transform and route the cross-border payment messages.
• Message routing and validation,
• Message queuing in any event causing the AFAQ Service or RPG to queue messages until they can be delivered,
• Handling of Payment Completion Confirmations,
• Exception handling and return of payments,
• Systems management and access control,
• Synchronization of static data with the AFAQ Service cc.
• Holding of the current Participant Directory for message validation purposes.
• Holding of the current FX Translation Rates table for message validation purposes.
• Holding of the current Calendar for message validation purposes.
• Conversion of message formats MX from/to MT.
• Rejection of cross-border cross-currency payments where validation fails.
4.1.3 Sending RPG
The Sending RPG, operated by that country's NCB, receives individual payment messages from the Sending Domestic RTGS system, validates the message format, encrypts all the sensitive data, adds the summary data required for settlement and prepares the full message for transmission to the AFAQ Service CC. The Sending RPG also processes Payment Completion Confirmation messages from the AFAQ Service CC and matches them with the previously sent payment messages.
4.1.4 Receiving RPG
The Receiving RPG, operated by that country's NCB, receives payment messages from the AFAQ Service CC, decrypts the sensitive data, translates the messages into the format required by the Receiving Domestic RTGS system and forwards the messages to the Receiving Domestic RTGS.
Any data not included in the message from the Receiving RPG to the Receiving Domestic RTGS system is retained and available in the Receiving RPG. Receiving Direct Participants and Receiving NCBs have access to this data.
The Receiving RPG also processes Payment Completion Confirmation messages from the Receiving Domestic RTGS, matches them with the previously sent payment messages and transmits the Completion Confirmation to the AFAQ Service CC.
4.1.5 AFAQ Service CC
The AFAQ Service CC will perform the following main functions:
• Receive payment messages from the Sending RPG,
• Validate the message format and content,
• Perform the accounting entries over the shadow accounts of sending and receiving NCBs, and the Primary Accounts of Direct Participants in the case of countries using the CSM,
• Transmit the payment message to the Receiving RPG, or, to the Direct Participants in the case of countries using the CSM,
• Process Payment Completion Confirmation messages from the Receiving RPG, match them with the previously sent payment messages and transmit the Completion Confirmation to the Sending RsPG, or, to the Direct Participants in the case of countries using the CSM,
• Process payment rejections and returns,
• Maintain the Direct Participants directory,
• Maintain FX Exchange Rates for cross-currency conversion and end-of-day Settlement,
• Maintain the Business Day Timetable and Calendar,
• Provide enquiry services to NCBs, and to the Direct Participants in the case of countries using the CSM,
• Produce and transmit MT950 Shadow Account statements at end-of-day, and
• Perform end-of day Settlement activities.
4.1.6 Receiving Domestic RTGS
The Receiving Domestic RTGS system, operated by that country's NCB, handles all communications with the Direct Participants in the receiving country. It also deals with all aspects of the processing of Inward cross-border payments in accordance with the rulebook of that country's RTGS system, including, debiting the account of the Sending NCB, crediting of the account of the Receiving Participant, sending of the Payment Completion Confirmation to the Receiving RPG and transmission of the inward payment message to the Receiving Participant.
4.1.7 Country Specific Model (CSM)
The architecture for the CSM is the same as for the standard RPG configuration except that there is no automated communication with the country's Domestic RTGS system that processes domestic transactions.
4.2. Service's Architecture
As SAMA has adopted the CSM for carrying out SAMA and Direct Participants operations in AFAQ's Service, the functions of a Domestic RTGS system in respect of both inward and outward cross-border payment processing and bookkeeping of Direct Participants' mirror accounts and the relevant NCB shadow accounts are performed in the AFAQ Service CC.
4.3. SAMA's Systems
SAMA controls the installation, maintenance, operation, security, and contingency of the Service and has the right to regulate, administer and monitor the Service using the facilities afforded.
4.4. Direct Participants' Systems
Each Direct Participant is responsible at its own cost for the development, maintenance, security and reliability (including back-up and contingency) of its host system connected to the Service and any links from or to the Service.
4.5. Certification
No Direct Participant may use the Service until it and its systems used in relation to the Service have been certified by SAMA.
4.6. Monitoring
SAMA has the right to monitor relevant Direct Participant's activities for the sake of ensuring that the Service is operated properly, exercising responsibility for central risk management and mitigating pertinent risks.
4.7. Responsibility for Liquidity
SAMA has no responsibility to monitor Direct Participant’s liquidity. It is the responsibility of each Direct Participant to manage its own Liquidity.
4.8. Information
The Service provides reporting and enquiry facilities operating in near real-time; giving each Direct Participant immediate visibility of respective position & enabling it to manage its Liquidity.
4.9. Enhancements to Systems
SAMA may arrange for enhancements and changes to the Service and advise the Direct Participants accordingly, giving such notice before the changes are to be implemented as SAMA considers reasonable. SAMA may give directions for the safe, accurate and timely implementation of changes, updates and distributions. The changes will be binding on the Direct Participants and each Direct Participant will at its own cost carry out all necessary tests & modifications to its own systems linked to the Service and to its pertinent procedures to give effect to these measures.
4.10. Service Levels
SAMA may from time to time specify the service levels to be provided by the Service and by the Direct Participants systems used in connection with the Service.
4.11. Reporting
Each Direct Participant must inform SAMA Immediately of any event which may affect its role or function as a Direct Participant in the Service, including any known or planned disconnection from the Service, or any significant changes to Its host system interface to the Service, its organisation, or environment.
4.12. Operating Procedures
Each Direct Participant must maintain their own internal operating procedures that comply with these Operating Rules.
4.13. Contingencies
Each Direct Participant must ensure that their back-up and contingency procedures are such that the Service is capable of completing their daily processing requirements, without compromising the integrity, security, or performance of the Service. Each Direct Participant will ensure that it has access to adequate contingency facilities to enable It to send and receive its Payment Messages at least during the Operational Phase of the Business Cycle. Each Direct Participant shall ensure that their contingency procedures allow the resumption of operations at the contingency site when required, with the minimum loss of operational time in accordance with the Business Continuity Management Framework published by SAMA, as amended from time to time.
4.14. Tests
Each Direct Participant will comply with the Business Continuity Management Framework issued by SAMA & conduct realistic tests of contingency facilities at least twice annually to ensure the readiness and capability of operations. Signed records of the conduct of such tests must be retained.
4.15. Back-ups
Each Direct Participant is responsible for backing up data and programs for its own the Service operations.
4.16. Confidentiality
Unless advised otherwise by SAMA, The Direct Participant agrees to keep confidential all information concerning SAMA's business or its ideas, intellectual properties, products, customers or services that are of confidential, proprietary or trade secret nature.
4.17. Security
The Direct Participants will abide by applicable rules, regulations, policies and frameworks issued by SAMA; including the Service Security Policy as amended by SAMA from time to time. The Direct Participant must ensure the security and soundness of (SAMA - AFAQ) operations and inform SAMA in case of any security incidents.
4.18. Fraudulent Activities
The Direct Participant must take necessary actions & implement adequate measures to prevent, detect and respond in a timely manner to fraudulent activities involving the Service & report such activities to SAMA and the Direct Participants concerned in accordance with relevant fraud prevention guidelines.
4.19. Accounts at SAMA
Each Direct Participant must maintain a current the Service account at SAMA. Relevant Direct Participant's account must be held in accordance with SAMA's banking conditions from time to time.
5. Business Day Timetable and Calendar
5.1. Timetable
The timetable will allow all Direct Participants to provide high level of service to their customers. The Business Day Timetable will be impacted by providing adequate time for the completion of start-of-day and end-of-day business processes and to allow reasonable time for extending the period required for "pre end- of-day activities" in the event of problems or delays.
Some of the Business Day times are controlled by the system(s) while others are intended as times that all parties must adhere to.
The following key events occur during the course of the business day (Business Day Period):
1. System start.
2. FX Translation Rate adjustment - NCBs can send messages with FX Translation Rates; the official rate for their currency against the USD.
3. FX Translation Rate authorization - at the beginning of the period AFAQ Service cc calculates the cross- rates for all currency pairs and delivers them to NCBs for approval. NCBs send authorization messages: either approval or decline. In case no approval or decline is received, the FX rate is considered as unconfirmed. The system will prohibit cross-border payments for unconfirmed pairs of currencies.
4. System Housekeeping - at the beginning of the period, the system sends FX Translation rates notifications to the NCBs for all approved currency pairs. This period is also used for other housekeeping e.g. Business Day Calendar changes and Participant Directory updates.
5. Start of Day Funding: In accordance with SAMA's banking conditions the Direct Participant wishing to transact through AFAQ on a specific day shall prefund their respective account with SAMA through the Saudi Arabian Riyal Interbank Express "RTGS" on a daily basis to ensure that available balance in AFAQ is sufficient to cover all payment messages of all types as they fall due for payment. The Start of Day Funding message must be supplemented as per the following criteria:
• Be for credit to SAMA.
• Be an Interbank Payment Message.
• Quoting the Routing Code /AFAQSD100/ in Account with institution Field.
• Stating the nature & date of the funding in the Sender to Receiver Information Field.
6. Exchange period for all types of payments - exchange window for any type of operations including returns initiated by Direct Participants.
7. Exchange period for Interbank payments - only interbank payments will be accepted during this period.
8. End-of-day operations - automated return of cross-currency payments by Central Component which cannot be delivered to the RPGs of the receiving countries. RPGs do not automatically return the payments which cannot be delivered to the Domestic RTGS systems - as this should be only RPG operator's decision.
9. Reporting - generation of statements and Net Position reports, reconciliations and confirmations by NCBs & Direct Participants.
10. End-of-day Settlement window - end of day settlement operations through the Settlement Agent.
11. End-of-day reconciliation with NCBs - NCBs can monitor today's activity and send inquiries to the system to reconcile their activities during the day in case of any inconsistencies.
12. End of Day reconciliation With Direct Participants: On a successful completion of End of Day Settlement Window with NCBs, SAMA will reconcile respective accounts held & issue a "Zeroizing" transaction to sweep the available balance maintained by the Direct Participant within the Service to the current account of the Direct Participant in RTGS.
13. Archiving - data archiving
14. System stop.
5.2. Business Days
SAMA will specify and advise the Direct Participants of the days deemed Business Days for the purposes of the Service. SAMA may declare Business Days to be non-Business Days and vice versa for the purposes of the Service.
5.3. Calendar
The Business Day Calendar is maintained as a table in the AFAQ Service cc. The table contains a calendar of working days and holidays for cross-currency payments per country. Cross-currency payments are processed only if there is a working day in both the Sending and Receiving countries. Any updates to the calendar will be made within the AFAQ Service CC.
5.4. Cut-off
SAMA has the right to manage the orderly cut-off of the Service.
5.5. Limits on Transactions
SAMA may limit the categories of transactions allowed during times of the Business Cycle under advice to the Direct Participants.
5.6. Closures
SAMA may close the Service for the purposes of maintenance, correction of technical problems، or installation of systems, or other reason, which in SAMA's opinion makes a closure desirable.
5.7. Availability
Each Direct Participant will ensure that it is in a position to receive and send Payment Messages during the Operational Phase advised by SAMA.
6. FX Rates and Currency Conversion
Prior to the start of the "open for business" phase, confirmed exchange rates will be set in the central system and the RPGs. These rates will be used throughout that business day for the transformation of payment messages. The Sending Direct Participant must include the currency code and amount in the currency of the sending country as well as the exchange rate and the currency code and amount in the currency of the receiving country in the appropriate fields of payment messages. The exchange rate must be the correct confirmed exchange rate for the pair of currencies for that business day. The exchange rate and the converted amount will be validated by the RPG and AFAQ Service cc. Payment messages with an incorrect exchange rate and/or converted amount will be rejected.
7. Payment Messages
7.1. Eligible AFAQ Transactions
7.1.1 The Direct Participant must ensure that AFAQ Transactions shall be effected solely for Genuine Client Needs. For the purposes of these Rules, Genuine Client Needs means bona fide financial and payment needs of non-banking clients of financial institutions participating in the AFAQ system, including (but not limited to) payments arising from bilateral commercial trade activities, remittances and consumer payments.
7.1.2 The Direct Participant shall place adequate measures to ensure that the Service is utilized in a manner consistent with clause 7.1.1.
7.1.3 The Direct Participant shall not, nor shall it permit any of its clients to engage in or be part of Arbitrage or Speculative Activities to profit from any price differences that may exist from time to time between the Foreign Exchange Rates used within the Service and any rates used in other foreign exchange markets.
7.2. Qualified Payment Messages
Payment messages transmitted for processing by the Service must meet the following criteria:
a) Single Payment Messages only,
b) Customer or Interbank payments in the format specified by SAMA,
c) Same day value only - must be a working day in both the Sending and Receiving countries,
d) Must include the currency code and amount in the currency of the Sending country as well as the exchange rate for that business day and the currency code and amount in the currency of the Receiving country in the appropriate fields.
e) Follow message specifications set out in respective Message Format Guidelines.
f) Be for credit to:
• The Receiving Direct Participant itself (interbank payment),
• A Financial Institution holding an account with the Receiving Direct Participant (Interbank payment), or,
• A non-financial institution or person holding an account with the Receiving Direct Participant (Customer payment).
7.3. Payments Processing
The payment for the Receiving Country, when transformed by the AFAQ Service, contains the opposite exchange rate and the two currency amounts in the opposite order. The Receiving Direct Participant, for checking of correct calculation of amounts, should use the original exchange rate used by the Sending Direct Participant (or Sending Domestic RTGS system).
The AFAQ Service cc will process the transaction as per the following:
1) Payments from countries using the CSM
a. Payment Message in the Sending Currency of countries using the CSM:
i. DR: Settlement Account of the Sending Direct Participant;
ii. CR: Shadow Account of the NCB of the Receiving Country;
b. Payment Message in the Receiving Currency:
i. DR: Shadow Account of the NCB of countries using the CSM,
ii. CR: Control (Technical) Account of the NCB of the Receiving Country
2) Payment to countries using the CSM
a. Payment Message in the Sending Currency:
i. DR: Control (Technical) Account of the NCB of the Sending Country,
ii. CR: Shadow Account of the NCB of the countries using the CSM.
b. Payment Message in the Receiving Currency of countries using the CSM:
i. DR: Shadow Account of the NCB of the sending country,
ii. CR: Settlement Account of the Receiving Direct Participant (in the countries using the CSM).
In all cases the entries of both payment messages are posted simultaneously.
If the payment cannot be processed by the AFAQ Service cc for any of the reasons listed under Reasons for Rejection in APPX (2), a rejection message will be sent back to the Sending RPG. The Sending RPG will generate a return payment and send it to the Sending the Direct Participant stating the reason for rejection.
A returned payment message must not be resent with the same Unique Message Reference as the original one. It may, after correction of the reason(s) for rejection, be sent as a new payment by the Sending Direct Participant with a different Unique Message Reference, but UETR can be the same.
7.4. Completion of a Payment
A payment is deemed to be completed, for the purpose of sending the Payment Completion Confirmation, once it has been validated and accepted by the Receiving Domestic RTGS system for onward transmission to the receiving Direct Participant.
The final stage of processing of a payment within the receiving country is subject to the rules, regulations and processing procedures that govern the Receiving Domestic RTGS system.
7.5. Confirmation of Completion
The Receiving Domestic RTGS system, after it has validated the incoming payment and accepted it for onward transmission to the Receiving Direct Participant, will generate and send a Payment Completion Confirmation through the Receiving RPG to the AFAQ Service CC quoting the Unique Message Reference of the payment message.
The AFAQ SERVICE cc will match the Payment Completion Confirmation with the Sent Payment with the same Unique Message Reference and forward the Payment Completion Confirmation through the Sending RPG to the Sending Domestic RTGS system.
The Sending NCB will monitor all payments sent to ensure that matching Payment Completion Confirmations have been received. If the relevant Payment Completion Confirmation has not been received after an interval of 10 minutes from the time the payment was sent by the Sending RPG, and the payment in question was not returned or rejected, the Sending NCB will commence enquiries with GPC as to the cause of the missing confirmation. The Sending NCB is required to monitor receipt of all Payment Completion Confirmations. All payments must be confirmed as completed before the end-of-day process is started.
7.6. Crediting Beneficiary's Account
In accordance with applicable laws, rules & regulations, The Receiving Direct Participant, where the Beneficiary's account number quoted in the Payment Message is the correct account number for the Beneficiary stated in "Beneficiary Customer" field (Field 59), must credit the Beneficiary with same day value as soon as possible but not later than the end of the same Business Cycle.
7.7. Value to Correct Beneficiary
The Receiving Direct Participant will ensure that the value of the payment is given to the correct Beneficiary as per the details in the relevant Payment Message.
7.8. Returns by the Receiving Direct Participant
In case a Payment Message couldn't be credited to the Beneficiary Customer, The Receiving Direct Participant - unless advised otherwise by SAMA - should return to the Sending Direct Participant as soon as possible, preferably within the same business day. If the payment cannot be returned on the same business day, it should be returned before the cut-off time for that type of payment on the next business day or within 2 business days at the latest without liability for use of funds compensation; abiding by the return rules prescribed in 7.8 & using the same exchange rate and currency amounts as in the original received payment with no deductions.
7.9 Return Payment Rules
The receiving Direct Participants shall perform the following validation checks, for returned cross-currency payment messages:
• Any Payment being returned must be returned as a single message,
• The Payment Reference in field 72 is the same as the Reference in the original payment,
• Only one successful return payment is allowed for each received payment message,
• The payment must be returned within a maximum of 2 business days from the date of receiving the original payment message when both countries (sending and receiving) have business day simultaneously,
• The payment currency code and amount in the return payment must be the same as those in the original payment message,
• The exchange rate in the return payment must be the same as the exchange rate in the original payment message received by the return message creator's party,
• The instructed currency code and amount in the return payment must be the same as those in the original payment message received by the return message creator's party,
• The presence of original direct payment reference is checked in Central Component database and Return is rejected if
o The original direct credit reference is not found, or,
o The return is greater than two business days
o A successful Return has already been accepted by the Central Component
o Either of the currency amounts, currency code or exchange rate do not match the original payment
7.10 Reasons for Return or Rejection
A list of valid return and rejection codes is included in APPX (2).
7.11 Payments to the UAE
All payments sent to UAE must contain the correct Purpose of Payment Code according to the list of such codes as communicated by SAMA.
7.12 IBAN
All Customer Payments sent to those countries that use the International Bank Account Number (IBAN) standard - as advised by SAMA from time to time - must quote the IBAN in the Beneficiary Customer's account number field in the payment message in the format and following the rules published for the receiving country. Failure to include valid IBAN may be a valid reason for rejecting/returning the payment.
7.13 Finality Provisions
A payment is deemed to be Final & Irrevocable once the account of the Sending Direct Participant has been debited.
7.14 Cancellation
A Payment Message, once it has been debited to the account of the Sending Direct Participant, cannot be cancelled or recalled.
7.15 Anti-Money Laundering and Combating Terrorist Financing
Each Direct Participant must comply with Anti Money Laundering and Combating Terrorist Financing laws and the Implementing Regulations.
8 Miscellaneous
8.1 Liabilities of SAMA
Notwithstanding anything to the contrary in these Operating Rules or in any document or electronic communication referred to in these Operating Rules, neither SAMA nor any of its officers, employees or agents ("a Specified Party") shall be liable for any losses, or damages or expenses of any kind, whether direct or consequential ("Losses") suffered by a Direct Participant or any other person arising directly or indirectly from:
a) any delays caused by or malfunctions or breakdowns or any inadequacy of the Service,
b) any interruption or loss of the Service or of any of the services contemplated by the Service,
c) any liability for Losses attributable to those parts of the Service which are the responsibility of a Direct Participant or to a Direct Participants fault or systems, or
d) (without limitation) any acts or omissions of a Specified Party in connection with the Service or these Operating Rules;
8.2 Force Majeure
A specified Party shall not be liable for any Losses or any non-performance of the Operating Rules or of Payment Messages or of any obligation in relation to the Service arising directly or indirectly from circumstances beyond reasonable control.
8.3 Emergencies
If any malfunction, breakdown, or interruption or any emergency affects the Service or its operations, transactions will be handled in accordance with the directions of SAMA. Without limiting the discretion of SAMA, SAMA may extend the hours of operation of the Service, direct the use of contingency facilities or close down the Service in whole or in part.
8.4 Direct Participants Act as Principals Only
Each Direct Participant shall be liable as principal in respect of its Payment Messages.
8.5 Assignments
No Direct Participant may assign all or any of its rights or obligations under these Operating Rules. The Service Operating Rules bind the successors of each Direct Participant.
8.6 Dispute Settlement
In the case of any unresolved disputes or claims arising between any persons in relation to these Operating Rules or any rules, regulations or directives issued pursuant to them, the complainant may submit the dispute or claim to SAMA.
8.7 Severability
In case any provision in this Operating Rules shall be invalid, illegal or unenforceable, the validity, legality and enforceability of the remaining provisions shall not in any way be affected or impaired thereby.
8.8 Governing Law
These Operating Rules are governed by the Laws of the Kingdom of Saudi Arabia.
Appendix 1 - Controlled Documents
This table contains the list of documents that have been shared with the pilot banks.
AFAQ Documentation Version Document SAMA-l 3095 DS 509 001 GCC RTGS SAMA Design specification Participants edition 2019-11-01 SAMA-l 3095 MF 502 001 GCC SAMA-LQ-Message Formats-2019-11-01 SAMA-l 3095 MF 502 001 GCC SAMA-MT-Message Formats-2019-11-01 SAMA-l 3095 TD 501 008 GCC RTGS REST API specification 2019-09-06 SAMA-l 3095 DS 506 018 GCC RPG Design SAMA Specifics Participants updated 2020-07-02 SAMA-l 3095 DS 506 002 GCC RPG SAMA Design Specification Participants Edition 2020-09-16 Version 001 GCC RTGS MX Message Formats for Participants 2020-09-16 Version 001 SAMA RPG Participant User Guide revision Version 001 GCC RTGS Security Requirement Version 1.0 GPC Circular No.003- Explanatory Note for AFAQ Currency Conversion 2020- 11-17 Version 1.1 Final GPC PKI Commercial CP Version 1.0 GCC RTGS Cross Currency Service - Integration Test and Market Rehearsal Plan version for Pilot Banks Version 1.0 GPC Market Rehearsal Kick-Off Presentation - KSA & BAH 30.N0V-2020 Appendix 2 - Return and Rejection Codes
This table contains the list of Return and Rejection codes that can be used in status messages. The codes can be interpreted as having the meanings shown for each code.
Return reason codes based on payments Rejected by the RPG or Central Component Code Explanation RJ00 System error. Contact support. RJ01 Incorrect FX Rate RJ02 Incorrect Receiving Currency amount RJ03 Invalid Value Date RJ04 Currency code wrong for Receiving country RJ05 A non working day in the Receiving Country RJ06 A non working day in the Sending Country RJ07 Invalid business day period RJ08 Invalid Receiving Direct Participant RJ09 Participant is not active RJ10 Non delivery to Receiving Domestic RTGS RJ11 FX rate is not authorized RJ12 BIC is invalid RJ13 Returned at cut-off time as not delivered RJ14 Approved FX rate not found RJ15 FX rate is absent RJ16 Payments are not allowed RJ17 No active business day found RJ18 Invalid account RJ19 Lack of funds RJ20 No direct credit found RJ21 Return period expired RJ22 Incorrect return amount RJ23 Return payment duplication RJ24 Payment was cancelled RJ25 Payment was rejected RJ90 Access rights check failed Payments Returned
Will be registered in AFAQ CC dictionary (which may be updated from time to time).
System will validate during return processing.
Code Explanation AC01 Format of the account number specified is not correct AC03 Wrong IBAN in SCT AC04 Account number specified has been closed on the bank of account's books AC06 Account specified is blocked prohibiting posting of transactions against it. AC13 Debtor account type is missing or invalid AC14 An agent in the payment chain is invalid AC15 Account details have changed AC16 Account is in sequestration AC17 Account is in liquidation ADRM Beneficiary account is dormant AG01 Transaction forbidden on this type of account (formerly No Agreement) AG02 Bank Operation code specified in the message is not valid for receiver AM01 Specified message amount is equal to zero AM02 Specific transaction/message amount is greater than allowed maximum AM03 Specified message amount is a non processable currency outside of existing agreement AM04 Amount of funds available to cover specified message amount is insufficient. AM05 Duplication AM06 Specified transaction amount is less than agreed minimum. AM07 Amount of funds available to cover specified message amount is insufficient. AM09 Amount received is not the amount agreed or expected AM10 Sum of instructed amounts does not equal the control sum. ARDT Already returned original SCT BACL Beneficiary account closed BALC Beneficiary account blocked BADE Beneficiary account does not exist BADC Beneficiary account is in a different currency BDIN Beneficiary Name does not match Beneficiary account number BE01 Identification of end customer is not consistent with associated account number (formerly Creditor Consistency). BE04 Specification of creditor's address, which is required for payment, is missing/not correct (formerly Incorrect Creditor Address). BE05 Party who initiated the message is not recognized by the end customer BE06 End customer specified is not known at associated Sort/National Bank Code or does no longer exist in the books BE07 Specification of debtor's address, which is required for payment, is missing/not correct. BE08 Returned as a result of a bank error. CN01 Authorization is cancelled. CURR Currency of the payment is incorrect CUST Cancellation requested by the Debtor DS28 Return following technical problems resulting in erroneous transaction. DT01 Invalid date (eg, wrong settlement date) ED01 Correspondent bank not possible. ED03 Balance of payments complementary info is requested ED05 Settlement of the transaction has failed. ERIN The Extended Remittance Information (ERI) option is not supported. FF05 Local Instrument code is missing or invalid FOCR Return following a cancellation request FR01 Returned as a result of fraud. FRTR Final response/tracking is recalled as mandate is cancelled. IBAN Invalid Beneficiary account number IBIC Invalid Beneficiary BIC MD06 Return of funds requested by end customer MD07 End customer is deceased. MS02 Reason has not been specified by end customer MS03 Reason has not been specified by agent. NARR Reason is provided as narrative information in the additional reason information. NOAS No response from Beneficiary NOCM Customer account is not compliant with regulatory requirements, for example FICA (in South Africa) or any other regulatory requirements which render an account inactive for certain processing. NOOR Original SCT never received PPCI Purpose of Payment Code incorrect or invalid RC01 Bank Identifier code specified in the message has an incorrect format (formerly Incorrect Format For Routing Code). RC07 Incorrect BIC of the beneficiary Bank in the SCTR RF01 Transaction reference is not unique within the message. RR01 Specification of the debtor's account or unique identification needed for reasons of regulatory requirements is insufficient or missing RR02 Specification of the debtor's name and/or address needed for regulatory requirements is Insufficient or missing. RR03 Specification of the creditor's name and/or address needed for regulatory requirements is insufficient or missing. RR04 Regulatory Reason RUTA Return following investigation request and no remediation possible. SL01 Due to specific service offered by the Debtor Agent SL02 Due to specific service offered by the Creditor Agent SL11 Whitelisting service offered by the Debtor Agent; Debtor has not included the Creditor on its "Whitelist'' (yet), In the Whitelist the Debtor may list all allowed Creditors to debit Debtor bank account. SL12 Blacklisting service offered by the Debtor Agent; Debtor included the Creditor on his "Blacklist". In the Blacklist the Debtor may list all Creditors not allowed to debit Debtor bank account. SL13 Due to Maximum allowed Direct Debit Transactions per period service offered by the Debtor Agent. SL14 Due to Maximum allowed Direct Debit Transaction amount service offered by the Debtor Agent. SP01 Payment is stopped by account holder. SP02 Previously stopped by means of a stop payment advise. TMO1 Associated message was received after agreed processing cut-off time. TRAC Return following direct debit being removed from tracking process. ULBA Unable to locate Beneficiary account UPAY Payment is not justified. XX00 Unknown reason (system replaces when receives a reason not registered in the CC dictionary)
Soft Launch
Your access and use of SAMA Regulatory Rulebook and its content is considered as an acceptance and approval of commitment by you without any limitation or condition to the following:
SAMA Regulatory Rulebook is a platform that aims to assist the regulated entities to access SAMA regulatory content adeptly and efficiently.
SAMA Regulatory Rulebook is still on its development and soft launch stage. SAMA is not liable for its contents and does not warrant or represent that (the Services related to the platform, information or material presented in the platform) is displayed free of any inaccuracies, omissions, or errors (“Faults”). SAMA accepts no liability for any loss, claim or damage resulting from any use of the platform, and any decisions made, or actions taken based on the information contained in or generated by the platform.
SAMA Regulatory Rulebook has no legal effect and it does not aim to amend or revoke any legal provisions. The Rulebook still Contains some documents under review, including translated versions. Therefore, SAMA Regulatory content circulated through SAMA official channels remains in force.
Without prejudice to the terms of use of SAMA website Hereby, you acknowledge that any illegal, unauthorized use and/or any breach of any of these provisions may result in legal actions against you.
Your access and use of SAMA Regulatory Rulebook and its content is considered as an acceptance and approval of commitment by you without any limitation or condition to the following:
SAMA Regulatory Rulebook is a platform that aims to assist the regulated entities to access SAMA regulatory content adeptly and efficiently.
SAMA Regulatory Rulebook is still on its development and soft launch stage. SAMA is not liable for its contents and does not warrant or represent that (the Services related to the platform, information or material presented in the platform) is displayed free of any inaccuracies, omissions, or errors (“Faults”). SAMA accepts no liability for any loss, claim or damage resulting from any use of the platform, and any decisions made, or actions taken based on the information contained in or generated by the platform.
SAMA Regulatory Rulebook has no legal effect and it does not aim to amend or revoke any legal provisions. The Rulebook still Contains some documents under review, including translated versions. Therefore, SAMA Regulatory content circulated through SAMA official channels remains in force.
Without prejudice to the terms of use of SAMA website Hereby, you acknowledge that any illegal, unauthorized use and/or any breach of any of these provisions may result in legal actions against you.