Operating Rules for ACH Participants

Transcription

1 Operating Rules for ACH Participants ver

2 Table Of Contents 1. RULE 1 - INTRODUCTION General ACH Payment System Objective Membership Ownership and Licensing Operating Rules Amendments to the Operating Rules Usage of ACH RULE 2 - PARTICIPANT ACCESS Participant Types Participants Membership Participant Identification Responsibility of Direct and Indirect Participants Technical Requirements for Direct and Technical Participants RULE 3 - SYSTEM OPERATIONS Type of Operations ACH Business Calendar Business Cycle Business Hour Timetable Cancellation, Returns and Reversals of ACH transaction Processing for suspended /excluded participants End of Clearing Session Outgoing files to the Participants...19 PSD Page 1 of 67 ver

3 3.8 Settlement Management End-of-the-Day Processing Future Value Payments Special Processing Days Monitoring by the Central Bank Authority of the Central Bank of Oman RULE 4 TRANSACTIONS PROCESSING ACH File Submission Procedure ACH File Specification Validation Process Cancellation of Payment Messages RULE 5 PRE-AUTHORISED DIRECT DEBIT Authorisation Processing Dishonoured Preauthorised Debits RULE 6 - RETURN PROCESSING Return of Credit Transfer Return of Debit Transfer RULE 7 SETTLEMENT OF PAYMENT Time of Settlement and settlement schedule Settlement Process Notification of Settlement Failure of Settlement Table of RTGS messages in the scheme...36 PSD Page 2 of 67 ver

4 8. RULE 8 DEBIT CAP MANAGEMENT Setting up of Debit Cap Monitoring of the Debit Cap Modification in Debit Cap Payment instructions in excess of the Debit Cap RULE 9 - FINALITY OF PAYMENT Obligations of the sender participant Obligations of the receiving participant Definition of Finality Return of Funds RULE 10 SECURITY CONTROLS Encryption of Message Transmission PKI Security Access Control Participant Workstations RULE 11 - TESTING, CERTIFICATION AND CHANGE CONTROL Participant Pre-requisite Service Level Specification Certification Requirement Participants Responsibility Authority of Effect Change Mandatory Reporting by Participant Internal operating guideline and procedure Operations by Participants Change Control...42 PSD Page 3 of 67 ver

5 12. RULE 12 - FEES AND CHARGES Transaction Fees and Charges Collection of Fee and Charges RULE 13 - EMERGENCY CONDITION Authority Request for Extension Failure of Clearing Settlement Business Continuity RULE 14 DISCIPLINE Authority Suspension of Participant Suspended Participants obligation Suspension Notification RULE 15 - DEFAULT PROCESSING Authority Notification of Default Participant Obligation RULE 16 - OBLIGATION TO LAW (MISCELLANEOUS PROVISION) Central Bank of Oman Fraud FORCE MAJEURE Central Bank Personnel Officers, employees and Agents Emergencies Participants Act as Principals...48 PSD Page 4 of 67 ver

6 16.8 Assignments Dispute Settlement Governing Law RULE 17 - CONTACT Help-Desk Contact Details APPENDICES Appendix I- Glossary APPENDIX II LIST OF DIRECT PARTICIPANTS APPENDIX III - LIST OF INDIRECT PARTICIPANTS APPENDIX IV - LIST OF TECHNICAL PARTICIPANTS WITH RESPECTIVE SETTLEMENT ARRANGEMENTS APPENDIX V - CBO GENERAL LEDGER ACCOUNTS APPENDIX V - CBO GENERAL LEDGER ACCOUNTS APPENDIX VI - REASONS FOR RETURN OF CREDIT TRANSFER APPENDIX VII - REASONS FOR RETURN OF DEBIT TRANSFER APPENDIX VIII TRANSACTION CODES PSD Page 5 of 67 ver

7 1. RULE 1 - INTRODUCTION 1.1 GENERAL Central Bank of Oman ( the Central Bank ) in its capacity as the central banking authority and regulator in the Sultanate of Oman and in accordance with the powers vested in it by the Banking Law issued by Royal Decree 114 of 2000 to regulate banking business hereby promulgates the following rules to govern the Automated Clearing House (ACH) in the Sultanate of Oman. 1.2 ACH PAYMENT SYSTEM ACH Payment System seeks to provide participants an electronic platform for presenting interbank retail payments in batches, to one another, in order to be netted by the system for calculating multilateral clearing balances for each of the participants and subsequent settlement, including those for future settlement dates. The payment instructions may include pre-authorised debit instructions, direct debit instructions or direct credit instructions. A Glossary of the key terms used in the Rules and other associated documents is furnished in Appendix OBJECTIVE The ACH system is intended to contribute to the efficient operation of the financial system in the Sultanate of Oman. The system is expected to increase security of payment processing, reduce associated risks, and to promote efficiency in terms of speed, cost and robustness. 1.4 MEMBERSHIP Membership of the ACH shall be mandatory to all commercial and specialized banks operating in the Sultanate of Oman, or any other entity as approved/directed by the Central Bank. Membership may be granted to entities (other than those for whom the membership is compulsory) as per the procedure laid down in Rule 2.2 below. 1.5 OWNERSHIP AND LICENSING The ACH system is operated by the Central Bank who licenses the Participants to use the ACH System strictly in accordance with the terms and conditions of the Membership Agreement and these Operating Rules. The Central Bank is empowered to regulate the operations and usage of the ACH as it deems fit. 1.6 OPERATING RULES PSD Page 6 of 67 ver

8 The rules shall govern the operations and the use of the ACH as well as the roles and responsibilities of the Participants and the Central Bank. 1.7 AMENDMENTS TO THE OPERATING RULES These operating rules can be amended when deemed necessary, in consultation with and with the consent of the Central Bank and the Operation Sub-Committee of the Payment Strategy Committee. Payment Systems Department of the Central Bank shall be responsible for implementing the amendments to the Rules upon authorization from the Central Bank. 1.8 USAGE OF ACH Compliance All Participants and the Central Bank shall comply with these Operating Rules ACH Utility Without prejudice to any laws of the Sultanate of Oman, all Participants shall use ACH for effecting inter-bank payments in Rial Omani. The ACH system is designed with business continuity plan capable of coping with all different scenarios of failure of any part of components. Participants should refer to Rule 13.4 for the relevant procedure to follow under each scenario of hardware, software or network failure Current Inter-bank Agreements Any current Inter-bank agreements relating to Payments, such as the Clearing House Rules, Repurchase Facility, etc. shall continue to remain in force except to the extent that they are in conflict with ACH operating rules. 2. RULE 2 - PARTICIPANT ACCESS 2.1 PARTICIPANT TYPES The ACH system supports the following types of participation Direct participant is the one who maintains a current account in the books of the Central Bank (CBO) system reflected by one (and only one) settlement account in the RTGS as well as a direct PSD Page 7 of 67 ver

9 communication link with the ACH system, using the Omantel BankNet network or SWIFT network and a participant platform, allowing direct data exchange with the system Indirect participant is the one who maintains a current account in the books of CBO reflected by one (and only one) settlement account in the RTGS but no direct communication link with the ACH system. His communication with the system shall be through the communication link of a direct participant with whom he may have a service agreement. It is to be noted that a direct participant represents the indirect ones only for transmission of payment instructions. Therefore the direct participant and his indirect participant are responsible for the settlement of their own respective clearing obligations Sub participant is an entity that has neither a communication link with the ACH system nor a settlement account in the RTGS. He sends his payment transfers to a direct or indirect participant who in turn submits them to the ACH system. This direct or indirect participant is also responsible for settlement of said payment transfers of the sub participant through its own account. A sub-participant should be registered in the system Technical participant is the one who may send ACH transactions via a direct communication link to the ACH system but has no settlement account in the RTGS. Its position shall be settled through the account of direct or indirect Participant to whom this technical Participant belongs and has service agreement with. In the initial period of ACH Production operations, only direct participation and subparticipation shall be allowed. CBO shall advise via circular if the other participant type will be supported in future. 2.2 PARTICIPANTS MEMBERSHIP Initial Member The Central Bank and all participants of RTGS system are initial Participants in ACH. The list of these participants is as indicated in Appendix II Admission of New Members The Central Bank may authorize the admission of new Participant in ACH provided that the Central Bank in its sole discretion deems that the new Participant meets its qualifying criteria and executes the related membership agreement. PSD Page 8 of 67 ver

10 2.2.3 Prerequisites for the Participants All initial and future direct as well indirect Participants shall be members of RTGS. All direct and technical participants shall have relevant systems, procedures and trained staff complement, meeting the criteria set by the Central Bank from time to time for participation in ACH. The Central Bank shall additionally monitor the continued maintenance of the specified criteria from time to time and Participants shall permit access to their operations and facilities to the Central Bank for the purpose of such monitoring. Participants shall endeavor to keep their systems updated and in synchronization with the Central Bank s Criteria Suspension/Expulsion The Central Bank shall have the sole discretion to suspend or expel a Participant temporarily or permanently if it deems in its sole opinion that the Participant has ceased to meet the qualifying criteria prescribed by it from time to time, or if the Participant is declared insolvent or its banking license is revoked by the Central Bank, or the Participant has breached any of the terms of agreement or the Participant fails to comply with the these operating rules or any other reason deemed appropriate by the Central Bank Participants Withdrawal A Participant may opt to withdraw from ACH by giving a formal 60 days advance written notice to the Central Bank and the Central Bank providing its consent for the withdrawal request. The Central Bank shall as appropriate direct the concerned participant to surrender its rights, systems, software and any other material that relates to ACH. The participant shall comply with these directions Obligations on cessation of membership In the event, a participant has been suspended or expelled or has withdrawn from ACH, all its pending payment messages shall be canceled. However, the cessation of the membership shall not absolve the participant of any liability for effecting those payments to the concerned parties. The participant shall also continue to remain liable for all its accrued and accruing obligations under these operating rules Revocation of Suspension The Central Bank may in its sole discretion decide to revoke the suspension of the participant. In such case the Central Bank shall send a notice to that effect to all the remaining participants Notice period for suspension, expulsion, withdrawal and revocation. a) The Central Bank shall notify the participant being expelled or suspended by sending a communication to that effect via ACH Web Monitor or by fax or a letter addressed to PSD Page 9 of 67 ver

11 the Senior Management of the Participant immediately. The notice shall be deemed delivered as soon as the ACH Web Monitor message is released or the fax is transmitted or the letter delivered at the counter of the participant. The other participants shall be advised about the suspension through a communication in similar manner immediately. b) The Central Bank shall notify all other participants about the withdrawal by a member by giving 7 days advance notice. c) The Central Bank shall notify other participants about the re-admission of a suspended or temporarily withdrawn participant as soon as possible by sending a communication to that effect. 2.3 PARTICIPANT IDENTIFICATION Each participant shall be represented on the ACH System with a unique identification code, known as the Participant BIC (Bank Identification Code). ACH shall register following additional information for participant identification purposes. Each direct, indirect, sub-participant or technical participant, on admission, shall furnish the following information for identification purpose at the system level: # Parameter Details 2 Participant BIC The same identification code (BIC) of participants in RTGS system shall be used. 3 ID of the Participant representing this participant For indirect participants, sub-participants and technical participants, it contains the bank code of the direct participant who will technically represent him in the system 4 Participant s BIC For Participants who are SWIFT members it is SWIFT BIC, and it is a special code in other cases 5 Participation mode For example, Direct participant, indirect participant, technical participant, sub-participant, etc. 6 Participant s Name of participant name 10 Address For possible paper mail 11 Legal address Registered address of the participant 12 Telephone Telephone number of the representative of the participant 13 Fax Fax number of the representative of the participant 14 Electronic address of the representative of the participant 15 Country Country name 16 Country Code International ISO code of the participant s country PSD Page 10 of 67 ver

12 2.4 RESPONSIBILITY OF DIRECT AND INDIRECT PARTICIPANTS Requirement for Participants Accounts All direct and indirect Participants of ACH, by virtue of being RTGS members shall have a Settlement Account in RTGS at the Central Bank. The conditions stipulated by the Central Bank from time to time shall apply for operation of the Settlement Account Responsibility for maintaining sufficient liquidity The Direct and Indirect Participants shall ensure that they are maintaining sufficient balances in their RTGS settlement accounts for effecting payments generated by their own clearing settlement debit as well as of those Technical Participants and sub-participants for whom they are acting as settlement agents. It is the responsibility of each Participant to monitor their accounts for the purpose of maintaining liquidity. (for ACH capability of facilitating the monitoring of clearing obligations, please refer to Rule 8) Settlement arrangements for Technical Participants The Direct or Indirect participants wherever acting as settlement agent for Technical Participants shall be responsible for completion of settlement on behalf of the Technical Participants by maintaining adequate funds in the settlement account Central Bank access to information on Clearing Transactions The Central Bank in its role as regulator and operator of ACH shall have full access and authority to generate transactions and access information on Participants accounts. The Central Bank shall however have no responsibility for monitoring accounts of the Participants. 2.5 TECHNICAL REQUIREMENTS FOR DIRECT AND TECHNICAL PARTICIPANTS All direct and technical Participants shall set up and maintain the systems and applications as per the ACH design requirements. The requirements specified in this behalf are as under: Network Connectivity The total availability of the system ACH depends on the availability of every link of network. The platform of the participant communicates with the ACH central server via a private network BankNet. In case of unavailability of participant link to the BankNet, participant can use SWIFT network if the participant has a SWIFT connection. In case that the participant does not have a SWIFT connection, the participant should connect via leased line/dial up line to the ACH. In standard setting, ACH allows to change the network for PSD Page 11 of 67 ver

13 communication any time during a business day. The CBO shall require an hour s notice for change of the communication mode at the host. ACH application provides same functions for transaction for both BankNet and SWIFT connectivity. System supports parallel operations of BankNet and SWIFT network Participant Platform The participants shall install the following hardware equipment for the participant platform which connects with ACH host system: An Application Server for ACH Participant A Database Server Controller PC Operator PC CBO shall define the hardware and software specifications of the above equipment. Participants shall ensure they will comply and maintain the above equipment as per instruction provided by CBO PKI Key Management Participants are required to adopt the PKI (Public Key Infrastructure) security as provided in the participant connectivity platform for sending and receiving messages with ACH system. Each user authorized by the participant will be responsible to own a key pair (public key and a private key) and key certificates Private and Public Key The public key is used to encrypt and verify the data. The private key is used to decrypt and sign the data. Each key contains the following parameters: abonent, description, date of key creation and date of key expiration. All parameters are integral parts of the key, so it is impossible to change them after key generation Certificate Certification is designed to prevent substitution of public keys by signing them with the certified key. The key signature with parameters on the certification key is called a certificate. The certificate may be saved with the key in a key base or in a file Working with Keys The participants shall be guided by the procedure described in the ACH System document User s Guide Key Manager provided to them. Using the KeyManager interface you can generate a new key, view the existing keys, set a key or a base as default, manage key PSD Page 12 of 67 ver

14 certificates. The participants should submit public and private keys generated to Central Bank for certification prior to the activation of keys for production use. Each user of the participant has sole responsibility to safe-keep the public key, private key and certificates information in secured physical medium, and ensure that the information will not be compromised by unauthorized personnel. 3. RULE 3 - SYSTEM OPERATIONS 3.1 TYPE OF OPERATIONS ACH System processes the following types of operations: Credit transfers from one participant to another: These are funds transfer from sending participant to customers of the receiving participant. The transfer support the following transaction types: o repayment of credit cards bills, sundry credits, standing credit operations, salary credits, dividend credits, inward remittance credits, pension credits, IPO subscriptions etc. Direct debits presented to the system by CBO e.g. transaction fees and/or other authorized parties e.g. court orders for requesting payment transfer from a participant. The transfer will be effected without the need of a pre- authorization from the paying Participant. Pre-authorized direct debit originating from a participant s customer (payee) to request payment transfer from another participant s customer (payer). The payer must have provided a pre-authorized debit authority to the payee s bank participant to debit through the payer s bank participant. The transfer support the following transaction types: o utility bills direct debit payments, repayment of installment loan/mortgage loan. Cancellation of a credit/debit transfer by a Sender Return of a credit/debit transfer by a Receiver during the permitted time schedule of a business day before settlement of the transfer occurs Reverse transactions (used for credit instruments only), issued by Receiver who wants to return the funds to the Sender after the credit transfers have been settled PSD Page 13 of 67 ver

15 Non-financial messages : o Enquiry by a participant about his current clearing balance: message addressed to the ACH system, to which the system responds in real time o Requests for status of a file/batch/individual transaction: message addressed to the ACH system, to which the system responds in real time o Free text messages and the replies thereto 3.2 ACH BUSINESS CALENDAR The Central Bank shall prepare Business Calendar for a year in ACH for Participants to follow. The Central Bank shall also declare and update the Calendar in the event of any unscheduled sudden bank holidays occurring (CBO will make the best effort to declare and update Calendar before the sudden holiday starts. All private sector banking days shall be the ACH working days unless the Central Bank issues a circular to the contrary. The Central Bank has the sole authority to declare holidays for ACH System. The date format in ACH shall follow the Gregorian calendar. 3.3 BUSINESS CYCLE A business cycle in the ACH commences with exchange session for transmission of payment (credit as well as debit) transfer instructions, proceeds through processing of these instructions by the ACH and working out the participant-wise net clearing balances in a dynamic manner, submission of these instructions to the receiving participants by the ACH at the end of specified clearing session, return of the unapplied transfers by the receiver, and closes with arriving at the settlement clearing balances and their settlement in the RTGS. Following graphic depicts the various stages in a typical ACH business cycle. PSD Page 14 of 67 ver

16 Part A Part N File Validation error notification KO ACH OK Validation Change-of-period notifications RTGS Acknowledgement on incoming file Creation of clearing transaction Acknowledgement on outgoing file End-of-day report End-of day procedures Clearing procedure Unwind procedure Clearing results Validation error notification Validation KO OK Possible to settle now? OK KO Debit confirmations Credit confirmations Settlement notification Participants Clearing Position report OK Putting transaction in a queue Cancellation notifications Cancellation notifications Change-of-period notifications Cancellation of clearing transaction 3.4 BUSINESS HOUR TIMETABLE CBO shall define the ACH operating hours in advance. Each new working day shall have its own value date in accordance to the Gregorian calendar. A message shall be broadcasted by the system to all the participants to inform them about the beginning and the end of every period. In the initial period of ACH production operations, CBO will operate ACH System with two exchange sessions and one end-of-the-day settlement session for both the exchange sessions. The participants shall be provided with the clearing results at the end of the each exchange session. Accordingly, normal Business Operating hours (Saturday to Thursday) for ACH are as indicated in the following table: PSD Page 15 of 67 ver

17 Activity at the ACH Hours Duration 1. Start of the day minutes 2. Business Day Initialization minutes 3. Exchange Session I minutes 4. Clearing for Session I minutes 5. Exchange Session II minutes 6. Clearing for Session II minutes 7. Exchange Return Session minutes 8 Pre-clearing (Adjustment) for minutes session II 9 Clearing for Exchange Return minutes Session 10 Settlement minutes 11 Cancellation of uncleared minutes instructions 12 Clearing Reports minutes 13 Archiving minutes 14 End of day Over time after the ACH system is in production operations and when needs arise, CBO reserve the right to increase the number of exchange sessions and number of settlement sessions within a business day cycle. In a multiple settlement day schedule, each exchange session shall be followed with its own independent settlement session. CBO reserves the right to alter the start, end time of each business period depending on the operating environment. Any changes to the value date or the timings for the system, shall be informed to the Participants through electronic mode or otherwise. Description of Activities in the ACH Start day Technical initialization of the clearing day, loading of the day s profile and system operations parameters with possibility to modify them Business Day Initialization Loading of participants debit caps with possibility to adjustment by CBO authorized staff. Exchange PSD Page 16 of 67 ver

18 The system will send a notification message to all participants to indicate the start or end of this period. Standard transmission of ACH transaction files and messages by the participants takes place. The system perform validation, clearing, debit cap management and bill-book management for all payments received. Exchange Return Participants are allowed to transmit of files containing payment instructions which are returned to the respective sender participants. Pre-clearing (Adjustment) The ACH system will send notification to all Participants about their net positions, arrangements for settlement funds by the participants and adjustment of Debit Caps. Clearing ACH system performs clearing of payment messages from all participants. At the end of the clearing process, ACH system transmit the clearing results files and bill book contents (outgoing files) to participants. Settlement Settlement of the ACH netting results in RTGS system for all participants. Cancellation At the end of business cycle, ACH system will automatically cancel any ACH transaction in held status. (which have not been cleared because of pending debit cap position adjustment). Clearing Reports ACH system will send the appropriate clearing session reports to each Participant. 3.5 CANCELLATION, RETURNS AND REVERSALS OF ACH TRANSACTION Cancellation After participants have transmitted their payment files to ACH system in the Exchange Session, participants may cancel any individual instructions in the payment files BEFORE the respective instruction is sent to the receiving participant. Only the sender participant is allowed to perform the cancellation and it can only take place within the same exchange session in which the payment is originally sent to ACH system Returns PSD Page 17 of 67 ver

19 Participant can only return of any payment instruction received but it must be done before the settlement of the instruction takes place. The receiver can return credit or debit transfer batches or individual instructions if the instructions must not be applied for various valid reasons Return of Credit Transfers Return of batches or individual instructions relating to credit transfers can take place only after the clearing results and the bill book contents have been sent to the participants. The return can be made only by the receiver of the instructions, Return of credit transfer must be submitted within the same day of original transmission of the credit transfer Return of Debit Transfers Return of debit transfer must take place prior to the expiry of the settlement delay period allowed for the respective debit transfer. The return can be made only by the receiver of the debit instruction, and can only occur in any normal or special exchange sessions before the settlement session starts at the end of the settlement day period Reversals Once the settlement for payment instruction processed in the previous exchange sessions has completed, the transfer of funds is irrevocable. If the receiver participant need to reverse any instruction AFTER the settlement has completed, the receiver shall liaise with the sender participant and agree on initiating a reverse transaction in the subsequent exchange sessions. CBO shall not mediate for resolution of any such dispute if occurring and the participants involved shall resolve the same according to legal banking practices. 3.6 PROCESSING FOR SUSPENDED /EXCLUDED PARTICIPANTS When the system receives transfer instructions presented by a suspended participant or destined to a suspended participant, it stores the operations in the database, until the status of the suspended participant changes to Active. Once the participant is changed to active status, the system process the transfer instructions as normal. If the status of participant remains as suspend at the end of the business day, the transfer instructions shall be rejected and ACH system will inform the participant accordingly. When the system receives transfer instructions presented by an excluded participant or destined to an excluded one, the system immediately reject the instructions. PSD Page 18 of 67 ver

20 3.7 END OF CLEARING SESSION OUTGOING FILES TO THE PARTICIPANTS At the end of each session, the system shall send to all participants the following information: Transfers composed by the system, following the same rules as incoming remittances (Please refer to RULE 4 below). (Instructions rejected by the system or cancelled by the sender are not included, to avoid confusion). Contents of the bill-book for the current day and following days (for future value dates). Position of the participant s clearing account as compared to his debit cap Summary of the session in terms of number of files/batches/transactions sent by and to this participant 3.8 SETTLEMENT MANAGEMENT After the system have sent the outgoing files to participants and all exchange sessions for current day have ended, the actual settlement shall occur in the RTGS, as follows: ACH system shall send a list of all clearing balances to the RTGS system by means of a SWIFT MT971 message (settlement request). RTGS system shall treat the MT971 message as one instruction on the principle of all or none. If even one balance cannot be settled for whatever reason, the whole message is rejected. The RTGS then checks if all debit balances can be settled, i.e. if the settlement accounts of the participants in debit position are sufficient to cover their debit balance. If so, the system immediately debits these accounts (against an internal management account). For participants with credit balances, RTGS system credits their settlement accounts for the balances. When the settlement is successful, RTGS system will send notification to ACH, as well as notifications of debit/credit to the participants (MT900/MT910). o If the settlement cannot be successfully performed because of a insufficient settlement account balance in ANY participant with a debit balance, RTGS shall queue the clearing transaction until the respective participant settlement account has sufficient funds to settle the clearing transaction. 3.9 END-OF-THE-DAY PROCESSING The end of day procedure is executed by ACH as follows, after the settlement period has completed.: No payment transfer message can be accepted by the system. Any message received by ACH will be rejected. PSD Page 19 of 67 ver

21 The transfer instructions which have been on held status will be rejected by system automatically. Statistical information about the day s activities are sent to the Operation Management Workplace and all participants. Technical maintenance processing is automatically performed by the system, including archiving System shall be ready for shutdown by CBO administrator FUTURE VALUE PAYMENTS Number of Future Business Days The ACH system currently accepts credit transfer instructions up to two business days in the future. The participants may accordingly send the credit transfer instructions in advance of the settlement date up to two business days. Such transfer instructions shall be reckoned by the ACH System for all purposes for processing, clearing and settlement on the due date as specified in submission. The Central Bank has the right to modify the future value date range by communicating via circular in advance Cancellation of Future Payments The sender can cancel a future dated credit transfer instructions in any exchange session before ACH System sends the instruction to the receiving participants on the future value date SPECIAL PROCESSING DAYS Business Hours for Ramadan ACH Business hours during Ramadan period shall be as follows: Activity at the ACH Hours Duration 1. Start of the day minutes 2. Business Day Initialization minutes 3. Exchange Session I minutes 4. Clearing for Session I minutes 5. Exchange Session II minutes 6. Clearing for Session II minutes 7. Exchange Return Session minutes PSD Page 20 of 67 ver

22 9. Pre-clearing (Adjustment) for minutes session II 10. Clearing for Exchange Return minutes Session 11. Settlement minutes 12. Cancellation of uncleared minutes instructions 13. Clearing Reports minutes 14. Archiving minutes 15. End of day Normal Holidays ACH System operations shall not be available on normal holidays Unscheduled Holidays In the event of a unscheduled holiday (not known earlier) being declared: the settlement date for the unsettled debit payment instructions shall be deferred to the next working day following the unscheduled holiday. similarly the credit transfer instructions due for settlement for the day of unscheduled holiday shall be deferred to the next working day following the unscheduled holiday MONITORING BY THE CENTRAL BANK The Central Bank shall monitor the activities of each Participant in the ACH System electronically and by physical inspection to ensure and be satisfied that the Participants are operating in the ACH strictly in accordance with the related agreements and rules that govern ACH as also to control the risk management aspects in the system that include (but are not limited) to credit and liquidity risk AUTHORITY OF THE CENTRAL BANK OF OMAN a) Controlling the installation, maintenance including updates, operations, security, and contingency arrangements of the Central System, the Gateways, the Web Monitor Link and the telecommunication links connecting to ACH between the Central Bank and the Participants. b) Day-to-Day control over the management of operations of the Central System and the technical aspects of ACH including the communication between Central System and the Gateways. PSD Page 21 of 67 ver

23 c) The Management of systems capacity and telecommunications traffic d) To regulate, administer and monitor ACH. 4. RULE 4 TRANSACTIONS PROCESSING 4.1 ACH FILE SUBMISSION PROCEDURE The ACH system provides a facility at the participant premises for participants to submit instructions for direct debit or direct credit payments via electronic network. The participants will prepare the debit and credit payment instructions as per the specifications prescribed in rule 4.2 below for transmission in accordance with the ACH business hour time table. 4.2 ACH FILE SPECIFICATION General ACH File specification follows a three-tier structure for submission of payment instructions as under: File Batch Payment At the apex level is the file. A file contains batches, which are sets of individual transaction instructions. PSD Page 22 of 67 ver

24 File Structure File header Batch header B atch trailer Batch header Batch Structure Batch Header ACH Detailed Record ACH Detailed Record ACH Detailed Record. B atch trailer ACH Detailed Record Batch header B atch trailer F ile trailer B t h F t Each file must contain the same type of instructions viz. presentation, cancellation return, etc. as under: From the sender: File containing new payment transfer instructions File with request for cancellation of a batch or individual payment instructions. From receiver: File containing returns of payments: Before Settlement File with reverse payments: After Settlement General Messages: In addition to payment instructions file, the following general messages can be sent to the ACH System: Request for Debit Cap change Transaction monitoring messages Text messages from one participant to another Broadcast messages from the Central Bank to the participants Unique key of a File The following group of fields uniquely identifies each file: Participant s BIC identifying the sender of file File reference number PSD Page 23 of 67 ver

25 In case of erroneous transfer (except the wrong value date error), it may be corrected by the sender and then resent with the same unique key. Nevertheless, to avoid any ambiguity in the correspondence between the Message Input Reference Number and transfer identification, it is recommended to resend such file with new unique key. It shall be noted that participant cannot resubmit the same file which has been accepted by system File/Batch/Message Formats The available message types for transmission to ACH system and their application are as follows: (Legend : CB the Central Bank) No. Message type Description 1. MT150 Presentation file: collection of batches to send as a whole 2. MT102 Batch: Multiple customer payment transfer. The only debit and credit accounts may be specified within same MT MT104 Batch: Direct Debit and Request for Debit Transfer 4. MTn98 Proprietary format message. It is used as envelope to send messages of proprietary types 5. MT199/ This message represents an e- TEXTMESSA mail sent from one Participant to To/From whom may be sent Participant ACH, ACH Participant; CB ACH, ACH CB Participant ACH, ACH Participant (Copy) within presentation file; CB ACH, ACH CB (Copy) within presentation file Participant ACH within presentation file; CB ACH within presentation file Participant ACH Participant; Participant ACH CB; CB ACH Participant Participant ACH Participant; PSD Page 24 of 67 ver

26 No. Message type Description To/From whom may be sent GE or MT999/ TEXTMESSA another one. CB may be issuer or receiver of this message as Participant ACH CB; CB ACH Participant GE well. 6. Set of system requests MT199 or Request to change corresponding parameter of the system. It doesn t contain field Participant ACH (restricted set); CB ACH (full set) MT999 :21:. 7. Set of system replies MT199 or MT999 Reply on related request. Reply contains field :21:. ACH Participant (restricted set); ACH CB (full set) 8. MT195/STAT Request for status of a file, batch or payment instruction Participant ACH; CB ACH 9. MT196/STAT Reply on request for a status of a file, batch or payment ACH Participant; ACH CB instruction 10. MT198 Request for status of payment instruction within a batch Participant ACH; CB ACH 11. MT198 Report on status of payment instruction within a batch ACH Participant; ACH CB 12. MT195/LIST Request for status of selected payment instructions within a Participant ACH; CB ACH file or batch 13. MT198/STAT Report on status of selected payment instructions within a ACH Participant; ACH CB batch 14. MT158 Report on status of selected payment instructions within a ACH Participant; ACH CB file 15. MT192 Request to cancel non-settled Participant ACH; PSD Page 25 of 67 ver

27 No. Message type Description (non-cleared) batch or payment instruction previously sent to the system 16. MT196/CANC Reply on request to cancel or reject non-settled (non-cleared) batch or payment instruction previously sent to the system 17. MT198 Individual cancellations within a batch. Requests 18. MT198 Individual cancellations within a batch. Reports 19. MT158 Cancellations with no request within a file 20. MT195/COPY Request for copy of a File, a Batch or a single Payment Instruction previously sent to the system 21. MT156 Copy of a File previously sent to the system 22. MT196/COPY Copy of a Batch previously sent to the system 23. MT196/COPY Copy of a single Payment Instruction previously sent to the system 24. MT198 Request for copy of selected payment instructions within a batch 25. MT198 Copy of selected payment instructions within a batch To/From whom may be sent CB ACH ACH Participant; ACH CB Participant ACH; CB ACH ACH Participant; ACH CB ACH Participant; ACH CB Participant ACH; CB ACH ACH Participant; ACH CB ACH Participant; ACH CB ACH Participant; ACH CB Participant ACH; CB ACH ACH Participant; ACH CB PSD Page 26 of 67 ver

28 No. Message type Description To/From whom may be sent 26. MT985/TTLS Request for totals of clearing activity during clearing session Participant ACH; CB ACH 27. MT985/TTLD Request for totals of clearing activity during current business Participant ACH; CB ACH day 28. MT985/TTLF Request for totals of clearing activity initiated by instructions Participant ACH; CB ACH of file 29. MT985/TTLV Request for totals of clearing activity during definite value Participant ACH; CB ACH date 30. MT986/TTLS Clearing Session Totals Report ACH Participant; ACH CB 31. MT986/TTLD Day totals report ACH Participant; ACH CB 32. MT986/TTLF File totals report ACH Participant; ACH CB 33. MT986/TTLV Value date totals report ACH Participant; ACH CB 34. MT985/STAT Account status request Participant ACH; CB ACH 35. MT985/TRNR Transaction Report request Participant ACH; CB ACH 36. MT985/SSCH Settlement Schedule request Participant ACH; CB ACH 37. MT986/STAT Reply to related account status request ACH Participant; ACH CB 38. MT986/TRNR Transaction report ACH Participant; ACH CB PSD Page 27 of 67 ver

29 No. Message type Description To/From whom may be sent 39. MT986/SSCH Settlement Schedule report ACH Participant; ACH CB 40. MT973 Netting request message Participant ACH; CB ACH 41. MT970 Netting Statement ACH Participant; ACH CB 42. MT972 Netting interim statement ACH Participant; ACH CB 43. MT971 Netting statement ACH Participant; ACH CB 44. MTn90 Advice of Charges, Interest and ACH CB Other Adjustments 45. MTn91 Request for Payment of ACH Participant Charges, Interest and Other Expenses 46. MTn96/ERRC This message is generated if error occurs in related request message processing. ACH Participant; ACH CB The instructions shall be submitted in the prescribed ACH message formats (Please refer to the document ACH System Message Formats) Details of Batch content Unique Key of a batch Each batch is uniquely identified by the following group of fields: Participant s BIC identifying the sender participant Batch reference number Value Date In case of errors occurred during a transmission, the Participant may resend a batch with the same unique key after the error has been rectified. In other cases, a new unique key should be used. PSD Page 28 of 67 ver

30 Constraints on Batch contents Batch must contain transactions in accordance with the following constraints: with the same value date with the same transaction type e.g. credit transfer or debit transfer for the same receiving participant Batches sent to the CBO must contain identification of CBO account in field :72: Transactions to CBO must be segregated into batches as per CBO General Ledger accounts (Appendix V) Unique Transaction Reference Each individual payment inside a batch is uniquely identified by the field :21: Each individual payment sent to the ACH system must have a unique transaction reference number (TRN). The system does not provide any scope for reuse of the same TRN for another message/transaction Identification of Destination Customer The primary identification to be used for the receiving participant s customer for application of payment instruction received shall be the account number Priority of ACH Messages Since ACH transactions are cleared and settled on deferred net settlement (DNS) basis, all transfer instructions accepted by the ACH for clearing and settlement enjoy the same priority. However, the net settlement arrived at for the accepted transactions shall have the priority 3 in the RTGS system. 4.3 VALIDATION PROCESS The transfer instructions submitted to ACH must pass the following validation tests, failing which these will be rejected by the system Format validation ACH verifies the validity of file and batch remittance header and trailer against the format residing in the system and rejects the whole file or batch as the case may be, if found not conforming. ACH then verifies the format of each transaction inside the batches. Each transaction is recognised as one of the prescribed message formats and that all the mandatory fields of the record are filled, and the data they contain is valid. If not the transaction is rejected and the batch is considered as partially accepted. The system recalculates the totals in number and amount of the valid operations inside the batch. Please refer to ACH Message Formats document for the detailed description of the contents of each element of the file structure. PSD Page 29 of 67 ver

31 4.3.2 Validation of the transactions The following items are verified under the validation process. Sending and receiving participants codes that have to be declared in the system and different from one another because the system does not accept intra-bank operations Status of the sending and receiving participants Reference of the transaction (TRN) (unique and correct sequence). The message bearing the duplicate TRN is rejected by the system. Currency of the transaction (at the beginning, only transactions in Omani Rials are accepted) Amount of individual credit transfer and direct debit operations (not exceeding the maximum amount fixed as a limit for such transactions) Aggregate amount of instructions contained in each credit transfer batch shall not exceed the debit cap limit applicable for the sender. Conformity to the presentation date. Validity as regards the time of the day when the transaction is received. For example, non-financial operations can be sent at any time of the day, while payment transfer instructions can only be accepted during the exchange period of each session Information of the participants Each time a transfer instruction or message is sent by a participant, the system immediately notifies him of the result of the checks (remittance accepted/partially accepted/rejected; individual batch accepted/partially accepted /rejected; individual transactions that are rejected with the rejection motive), in order for the sending participant to have time to correct the contents of his remittance and re-send it (with a different sequence number) to the system. 4.4 CANCELLATION OF PAYMENT MESSAGES Cancellation Policy A participant can cancel its previous sent remittance/batch/operation. All requests for cancellation of payment message input in ACH should be in a prescribed format and must have the TRN of the original payment message. Once a message is cancelled it cannot be resubmitted with the same TRN. All cancellation requests shall be entertained subject to the constraints in below Time Limit for Cancellation Any cancellation of a previously received file/batch/transaction must be received during the same session as of the original file/batch/transaction. PSD Page 30 of 67 ver

32 ACH system shall not be available for cancellation of any transaction after the relative exchange session has closed Cancellation Processing When the system receives a valid cancellation of a previously received file/batch/transaction, it verifies that: The sender of the cancellation is the same as the sender of the original instruction and that the cancellation is received during the same session as the original file/batch/transaction The instruction being cancelled does exist (its reference is correct and stored in the database). It retrieves the value date of the original instruction and calculates its settlement date and then reverses the original instruction in the bill book. The same happens for Debit Returns. After the validation process, the system verifies that: The sender of the rejection is the same as the receiver of the original instruction and that the rejection is received within the maximum rejection delay The instruction being rejected does exist (its reference is correct and stored in the database) It retrieves the settlement delay of the original instruction and calculates its settlement date and then reverses the original instruction in the bill book. This is done by the system in real time. Participants can review their current clearing position by sending a query to the system at any time. 5. Rule 5 Pre-Authorised Direct Debit 5.1 AUTHORISATION A participant may enter into an arrangement with its customers for the latter pre-authorising the former to entertain specific ACH debit instructions from certain clients through a sender participant. The receiving participant may act on such instructions if these conform to the terms under which these have been pre-authorised. PSD Page 31 of 67 ver

33 5.2 PROCESSING The arrangement of pre-authorisation of debit is outside the ACH system and CBO as operator of the system would have no responsibility or obligation for any consequences of such an arrangement nor such a pre-authorisation be registered in the ACH or validated before being sent to the receiving participant. Therefore all debit instructions shall be processed by ACH in the normal course for clearing and settlement. 5.3 DISHONOURED PREAUTHORISED DEBITS The pre-authroised debits which are dishonoured for payment for any valid reasons shall be returned to the ACH within the prescribed return discipline for debit transfer (Rule 6.2). 6. Rule 6 - Return Processing 6.1 RETURN OF CREDIT TRANSFER Introduction A Sender participant of the credit payment instructions is required to furnish correct and full mandatory details with each transaction adequate to enable the receiver participant to apply the credit to the beneficiary. It may still happen that the receiver participant is not able to apply the credit for incorrect or insufficient details of the beneficiary or the beneficiary s account is closed or account blocked for legal reasons etc. The receiver participant shall be obliged to return such a credit transfer to the sender through the ACH Time Limit for Return All inward credit transfers which cannot be applied by the receiver participant must be returned to the ACH for onward return to the sender as early as possible but latest before end of the Exchange Return session, failing which the system shall presume that the credit transfer has been successfully applied. In case the receiving participant fails to return a credit transfer during the exchange return session, the situation can only be remedied through a reversal of the transaction by submission as a new instruction through file/batch in a later exchange period. CBO as operator of ACH shall not be liable to any consequences resulting from the failure of receiver participant to return the unapplied credit transfer to the sender within the Exchange Return session. Participant shall send return of Credit transfer before the end of the Exchange Return Session within the same day of receiving the credit transfer Format of Return Item and Reasons for Return PSD Page 32 of 67 ver

34 Each batch inside a returns remittance contains a copy of mandatory fields of transactions that were previously part of the same batch and are required to be returned to the sender. In addition, the return transaction contains a copy of the original transaction being rejected. The list of valid return reasons for return of a credit transfer is furnished in Appendix VI. 6.2 RETURN OF DEBIT TRANSFER Introduction As in the case of credit transfer, a Sender participant of the debit payment instructions is required to furnish correct and full mandatory details with each transaction adequate to enable the receiver participant to apply the debit instruction to the account of the payer. It may still happen that the receiver participant is not able to apply the debit instruction for incorrect or insufficient details of the payer customer or the payer s account is closed or account blocked for legal reasons, or for insufficient funds or the debit is not authorized, etc. The receiver participant shall be obliged to return such a debit transfer to the sender through the ACH Time Limit for Return All the debit transfer instructions shall have a settlement delay period of one business day in order to provide time to the receiver participants to process the instructions. Debit transfer instructions which cannot be applied must be returned by the receiver as early as possible or latest in Exchange Return session before end of the settlement delay period, failing which the debit instructions are assumed to have been accepted for application by the receiver participant. Failure to return direct debit should be resolved by sender and receiver through mutual agreement and submission of new transfer for remedial action. CBO as operator of ACH shall not be held liable to any consequences resulting from the failure to return a dishonored debit transfer to the sender within the permitted time frame Format of Return Item and Reasons for Return Each batch inside a returns remittance contains a copy of mandatory fields of transactions that were previously part of the same batch and are required to be returned/reversed by the receiver. In addition the return transaction contains a copy of the original transaction being returned. The list of valid return reasons for return of a debit transfer is furnished in Appendix VII. The return instruction must cite the valid reason for return of a debit instruction Evidence of Dishonored Payment ACH provides functionality for sender and receiver participants to print return instruction together with digital signatures (at the Central Node with digital signature of Sender, on a Receiver side with a digital signature of Central Node). PSD Page 33 of 67 ver

35 The return instruction with associated digital signatures shall be acceptable evidence of a failure of payment in Central Bank jurisdiction. 7. Rule 7 Settlement Of Payment 7.1 TIME OF SETTLEMENT AND SETTLEMENT SCHEDULE After the net clearing positions have been arrived at during the clearing session on a business day and communicated to the respective ACH participants, the net settlement shall be submitted to the RTGS during the settlement session of the business day. For the time of settlement, please refer to the business day schedule of the day. PSD Page 34 of 67 ver

36 7.2 SETTLEMENT PROCESS Part B Part C RTS/X RTGS ClACH earing system Part A 1: Clearing results Validation KO 2: Validation error notification KO OK OK Possible to settle now? KO KO 3: Participants Clearing Position report Waiting for settlement OK 4: Debit confirmations OK 6: Settlement notification OK OK 5: Credit confirmations Cancellation of Clearing transaction 7: Cancellation notifications 8: Cancellation notification During exchange window of RTGS, the ACH submits a MT971 Message containing the Net position of Participants (credit or debit) (Step 1). RTGS validates this message and issues an error notification if it didn t pass through validation procedure. (Step2). If the validation is successful, the message is presented to Settlement as Net transaction. RTGS checks the availability of funds in Participants Accounts with Net debit positions and, once funds are available, debit and credit the Accounts of clearing Participants on an all-or-none basis. In case of lack of funds on any account, Net transaction is queued. (This transaction enjoys settlement priority number 3 in the RTGS. The system doesn t suspend ordinary settlement procedure during this period. If there are no sufficient funds to settle Net transaction on Settlement account(s) of any Participant(s), the system informs that Participant(s) by sending a special message (Step 3) to Participants that should cover their Debit positions. This message contains Net Debit position and Available balance of the Settlement account. 7.3 NOTIFICATION OF SETTLEMENT For reconciliation purpose, the Central Bank shall print a copy of the clearing transaction which shows the net debit or credit settlement amount of each participant. After settlement, each Participant, whose Account was debited/ credited receives appropriate debit/credit notification (e.g., MT900/MT910) (Steps 4, 5 and 6). The system shall produce appropriate advice to the Clearing system when the clearing results are settled. PSD Page 35 of 67 ver

37 7.4 FAILURE OF SETTLEMENT If one Participant cannot fund their account and fulfill obligation, the Central Bank shall not unwind and cancel all clearing transactions for that Participant immediately but shall provide the following options for remedying the situation: The failing participant borrows funds from the interbank market; The failing participant requests for liquidity via Repo in RTGS (please refer to the RTGS Operating Rules for liquidity support under intra-day repo). The options have to be explored within the settlement session. TABLE OF RTGS MESSAGES IN THE SCHEME Sequential number of SWIFT message Name of message in the diagram message in the diagram type 1 MT971 Clearing transaction 2 MT996 Validation error notification 3 MT986 Participants Clearing Position report 4 MT900 Debit confirmation 5 MT910 Credit confirmation 6 MT296 Settlement notification 7 MT296 Cancellation notification 8 MT971 Cancellation notification 8. Rule 8 Debit Cap Management 8.1 SETTING UP OF DEBIT CAP The CBO ACH system administrator shall set maximum debit cap limits for each participant at the start of the business day based on an assessment with regards to the participant s credit risk profile. The ACH system administrator can modify maximum debit cap for each participant for the current day. 8.2 MONITORING OF THE DEBIT CAP PSD Page 36 of 67 ver

38 As the system post amounts to each participant s clearing bill-book, it calculates the current clearing balance. When a participant has a debit clearing balance, the system checks if it is close or exceeds his debit cap. When the debit clearing balance reaches 80% of the debit cap, the system sends an alarm to the system s administrator at the host and to the concerned participant on his participant s platform. At any time during the session the system will inform Participant (on the basis of Participant s request) about Debit Cap applied, details of batches that debit its position and credit its position and total net position. This position is provisional since it may become worst e.g., if another Participant cancels a batch which credits the position of the Participant, or may become better if e.g. credit transfer from another Participant is accepted by the system. During the pre-clearing session (when cancellations are not allowed) the system will calculate current positions and inform Participants about current net debit or credit for today s batches. Participant can compare against their Debit Caps and request CBO to increase Debit Cap, if necessary, by sourcing funds for settlement purposes (cf. Rule 7.4). At the beginning of the session or day, if a participant s clearing balance is already close to the debit cap or beyond it, as a result of operations sent to the system on previous sessions or days, an alarm is sent to the concerned participant and the system administrator. All incoming operations concerning this participant s clearing account are stored for processing until the debit cap has available balance. 8.3 MODIFICATION IN DEBIT CAP The Participant may send to RTGS system a transaction that will reserve additional amount of funds for clearing purposes and therefore gives a possibility to Participant to increase Participant s Debit Cap in clearing system. In case of Participant desires to raise its Debit Cap, it shall be made through RTGS System as Repo request using MTn98 message. This message will contain clear identification of the purpose of Repo operation. CBO reserve the right to decide to approve an increase of the debit cap in accordance with the Participant settlement balance the Repo request received. When CBO increases the debit cap of a participant, the ACH system will process all batches held and of which the total are within the increased limit. 8.4 PAYMENT INSTRUCTIONS IN EXCESS OF THE DEBIT CAP At the end of the pre-clearing session, if certain payment instructions are held because of the debit cap being exceeded, the system cancels all the held instructions and informs the sender and the receiver. PSD Page 37 of 67 ver

39 9. Rule 9 - Finality of Payment 9.1 OBLIGATIONS OF THE SENDER PARTICIPANT Responsibility for correct beneficiary/payer details It shall be the customer s responsibility to provide the Sending Participant with sufficient, correct and clear information to enable the Receiving Participant to identify his customer unequivocally Unique identification of Receiver s Customer The sending Participant shall be responsible for transmitting correctly the details provided to it by its customer, in field 59 of MT 102 or MT 104 as the case may be. However, the Sender Participant shall not be liable for any errors or incompleteness in the information provided by its customer. 9.2 OBLIGATIONS OF THE RECEIVING PARTICIPANT Unique identification of beneficiary/payer The Receiving Participant of a credit transfer, upon receiving notification of settlement of credit transfer payment message, must credit the Beneficiary with same-day value as soon as possible, after due process of identification of beneficiary/payer. On the other hand, the receiving participant upon receiving and validating a debit transfer instruction, shall debit the payer customer as soon as possible within the due date for settlement i.e. a settlement delay of one business day Inability to execute payment If the Receiving Participant is unable to execute a Payment Message for legitimate reasons, it is the responsibility of the Receiving Participant to contact the Sending Participant for clarification or return the transfer as per the Rule DEFINITION OF FINALITY Once the Settlement account of the sending participant has been debited for credit transfer or credited for debit transfer (at the same time, the receiving participant will have been credited for credit transfer, or debited for debit transfer), the payment for credit transfer or debit transfer via ACH system is deemed final. PSD Page 38 of 67 ver

40 9.4 RETURN OF FUNDS Once an ACH payment is settled in RTGS and reached finality, any request for return of funds should follow the same rules as defined for RTGS operations. 10. Rule 10 Security Controls 10.1 ENCRYPTION OF MESSAGE TRANSMISSION The data exchange between ACH and its workplaces, central and remote nodes as well as external systems is implemented via the messages. They are submitted in the XML-format. As a rule, they consist of two parts. The first (service) part contains sender and receiver names, message priority and other system information, conform to the first, second and third S.W.I.F.T. message blocks. The second (informative) part of the XML-report contains the information in the format conforming to the S.W.I.F.T. message block 4. There may be several such units in the message. Operator creates the message, signs its informative part and passes the message to the controller, who approves the message as well as signs it completely (both service and informative parts), and sends it to the ACH. To begin the message exchanging process with ACH, the user should connect to a system. To process it, the user should enter the login and password. A login and password should be registered in central system node. Besides, this user should be granted to connect to the system only from the computer having definite IP-address. Login and password are placed in the message, which is signed by a secret user key. At the moment of sending, message is encrypted by means of the session key, which itself is encrypted by the receiver public key (ACH) and added to the sent message. The login, password, access rights and computer IP-address, from which one attempts to connect, are checked up by the ACH. In case of the contents of the sent message meeting the requirements, user receives a command to connect. For all messages described above, the length of the private and public key is 1024 bits, session key length is 128 bits. Session key is generated by a special crypto component each time for each message. The Central Bank is authorized to perform certification to the public key for each Participant. The Participant shall be responsible for securing and the protection of their private key. PSD Page 39 of 67 ver

41 Central Bank will not be liable for any damage or financial loss to a participant caused by any compromise on the private key information of the participant PKI SECURITY The system security is described in the RTGS Security Approach document made available to the participants. The participants shall be guided by the process described therein ACCESS CONTROL ACH identifies and authenticates each user interacting with the system, whether he is an employee of a participant or CBO staff, by verifying the identifier that is being used and the password. The user s digital signature is stored in the system together with each transaction he performs. The information about user logons/logoffs or incoming and outgoing messages is stored in the database with associated timestamps, physical source identification as well as the acknowledgement message of the system.. A forced logoff facility after a certain period of inactivity (time out) shall be used by participant. The maximum duration of an idle period is configurable both by the Participant for his own site and by the system s administrator. The functions and rights of each participant shall be maintained by CBO using ACH Access Right Manager: o to distribute responsibilities according to type of Participant and User of Participant within ACH; o to assign Access Rights for each Participant independently and according to his role in the system; o to adjust Access Rights for each Participant independently; o to change Access Rights assigned to Participant; o to audit Access Rights previously assigned to Participants PARTICIPANT WORKSTATIONS Identity and digital signatures of all users of the participant s workstation who communicates with a system and/or signs remittances/batches are stored at the Central node together with the time-stamp and processing results of the batch/remittance. Therefore the participants are identified by way of digital information about them stored in the central node. PSD Page 40 of 67 ver

42 It is the responsibility of the participants to ensure that their staff in ACH shall protect the public and private key information, certificate and passwords information and safeguard against compromise by unauthorised users at their end. 11. RULE 11 - TESTING, CERTIFICATION AND CHANGE CONTROL 11.1 PARTICIPANT PRE-REQUISITE Each participant is required to perform all necessary modifications to its own systems linked to the ACH systems at its own expense, and ensure implementation and adherence to all relevant procedures as may be required SERVICE LEVEL SPECIFICATION The Central Bank may from time to time specify the service levels to be provided by ACH and determine the service levels of the participants systems, used in relation to the ACH CERTIFICATION REQUIREMENT Any new Participant has to fulfil the following steps prior to connecting to the ACH System before the live operations: a) Complete the ACH Mandatory Business Case Testing b) Submit the Declaration for the Participant Certification (Document to be provided separately by the Central Bank) c) Sign and submit the Membership Agreement for the Provision of CBO National Payment Service 11.4 PARTICIPANTS RESPONSIBILITY Each participant has the following responsibilities: a) To develop their internal systems for linking to / from ACH and the maintenance, security and reliability (including back-up and contingency arrangements) of such systems at its own cost. b) To operate, administer and monitor ACH installations at the participants site c) Day to day responsibility for operating its ACH equipment at participants site, which include Application Server, Database Server, Controller PC, Operator PC and the interface between its own host system and ACH system. PSD Page 41 of 67 ver

43 11.5 AUTHORITY OF EFFECT CHANGE No participant has the authority to make changes of any nature to the ACH systems or install / use any software or any part of the ACH systems without the prior written approval of the Central Bank MANDATORY REPORTING BY PARTICIPANT Each participant is required to advise the Central Bank immediately of any event, which may effect its role of function as a Participant in ACH, including any known or planned disconnection from ACH, or any significant changes to its host system interface to ACH, its organization structure, or environment INTERNAL OPERATING GUIDELINE AND PROCEDURE Each participant and the Central Bank shall prepare and implement its own internal guidelines and procedures, to ensure that they are compliant with the Operating Rules laid down. Each participant shall submit a copy of such internal guidelines to the Central Bank for approval before commencing use of the ACH OPERATIONS BY PARTICIPANTS Each participant shall operate the areas of ACH, in line with its control and responsibilities, as laid down in the control documents CHANGE CONTROL ACH changes The Central Bank is authorized to make any changes to ACH and to the Control Documents, and advise the participants accordingly, giving reasonable notice to all participants before the changes are implemented. The Central Bank may also provide directions for the safe and timely implementation of changes and for accurate and timely up-date and distribution. Changes may also include additions and enchantments, and shall be binding on all the participants. Participants may propose changes to these operating Rules to the Central Bank, for its consideration and approval however the Central Bank shall not be obliged to implement any such change Implementation of changes Each participant shall ensure that its internal procedures and systems have the capability to deal effectively with all such changes to the control documents. PSD Page 42 of 67 ver

44 Advice of changes These Operating Rules are issued by the Central Bank as a control document, to named individuals of each participant, who shall also receive advice of future enhancements or updates. Each Participant is responsible for keeping the Central Bank advised of the correct contact name and address details for receiving such change advice. 12. RULE 12 - FEES AND CHARGES 12.1 TRANSACTION FEES AND CHARGES The Participant shall pay the fees and charges in the amounts and manner prescribed by the Central Bank, which may be amended by the Central Bank at its own discretion, from time to time, as when deemed appropriate. Central Bank reserves the right to define and impose such transaction fees at any time, and will announces the tariff and fees information to all participants by circular COLLECTION OF FEE AND CHARGES Central Bank reserves the right to collect the fees and charges from participant via the RTGS system. Central Bank will advise the procedure and billing time via circular to all participants. 13. RULE 13 - EMERGENCY CONDITION 13.1 AUTHORITY The Central Bank has the special authority to perform the appropriate action under the emergency conditions, including but not limited to the provisions of Rule 16 sub-section REQUEST FOR EXTENSION Should there be a need for Extension of the ACH Service to any of the Participants, the participants must complete the following steps: a) Log a Call with the Help Desk b) Send a written request with authorized signature to the Manager, Payment Systems Department by fax for authorization of the extension. PSD Page 43 of 67 ver

45 The Central Bank has the sole discretion to approve or reject the extension request FAILURE OF CLEARING SETTLEMENT In the event any Participant cannot fulfill its Clearing Settlement obligations, the Central Bank will inform the Participant accordingly. It is the responsibility of the Participant to provide the funding and complete the settlement on the value date BUSINESS CONTINUITY The Business Continuity Plan is as follows, Participant s must follow the procedures as per the cases provided hereunder in the event of any of the follows failures, malfunctions etc occur Case 1: Failing of the BankNet at the Central Node The ACH central system administrator must immediately inform all the participants by broadcasting the message via Web monitoring. In case of malfunction of the Web monitoring components, the managers have to use the other means: telephone and fax to inform all participants. Participants should switch to the SWIFT Network. In case of decision to work via SWIFT network: The participant establishes connection via SWIFT network: In this case the ACH Central mode administrator shall change the mode of the participating communication activating "SWIFT Network". If malfunction of BankNet happens during the period of exchange, the participant must, having been reconnected, acquire situation of its operations at the ACH system level: files/batches sent and received, bill-book and debit positions. In case of loss of operation, the Participant can resend to the system the copy of every lost order. ACH verifies the copy of payment orders of participants. ACH supports the same message types both for BankNet and SWIFT network. The same functionalities are implemented for the processing of the messages via these channels of communication. So, no special action should be necessary from the ACH message exchange point of view. To resume the operations via BankNet, CBO administrator shall change the channel of communication to "Private network" Case 2: Failing of S.W.I.F.T. and Private network on Central Bank site The Participant must bring forward the physical document of the Payments to the Central Bank, Payment Systems Department for inputting the messages. In the Future the same will PSD Page 44 of 67 ver

46 be done thru inputting the messages thru the Service Bureau operated by the Central Bank, and the Central Bank will advise the procedure accordingly when the Service Bureau is available Case 3: Failing of the ACH Central Site The ACH central system administrator shall immediately inform all the participants by broadcasting the message via Web monitoring; Web-monitoring components can function in spite of the ACH malfunction system exchange. In case of malfunction of the Web monitoring components, the managers have to use the other means: telephone and fax to inform all participants. CBO will activate the ACH Disaster Recovery (DR) site and resume processing. The participants must send messages to the DR site. In switching the service on the backup site, the participants must reconcile their positions according to the algorithm represented in Case Case 4: Failing of the BankNet on Participant site Participant should switch to the SWIFT Network or to Dial-up lines for connecting to ACH system. The participant establishes connection via SWIFT network: In this case the ACH Central mode administrator must change the mode of the participating communication activating "SWIFT Network". After the switching and reconnection, the participants must reconcile their positions according to the algorithm represented in Case RULE 14 DISCIPLINE 14.1 AUTHORITY The Central Bank has the special authority to take necessary timely action on the Participants to ensure efficient operation of the ACH SUSPENSION OF PARTICIPANT The Central Bank shall have the sole discretion to suspend or expel a participant temporarily or permanently if it deems in its sole opinion that the participant has ceased to meet the qualifying criteria prescribed by it from time to time, or if the participant is declared insolvent or its banking license is revoked by Central Bank, or the participant fails to comply with the operating rules and regulations of ACH or any other reason deemed appropriate by the Central Bank. PSD Page 45 of 67 ver

47 14.3 SUSPENDED PARTICIPANTS OBLIGATION In the event a participant has been suspended from ACH, all its pending payment messages shall be cancelled but the suspended participant shall continue to be liable for making payments to the concerned parties. The suspended participant shall also remain liable for all its accrued and accruing obligations under ACH rules and regulations. The Central Bank shall direct the suspended participant to surrender its rights, systems, software and any other material related to ACH SUSPENSION NOTIFICATION The Central Bank shall notify in writing the Participant being suspended by sending a communication to that effect electronically or by fax or a letter addressed to the Senior Management of the Participant immediately. The notice shall be deemed delivered as soon as the electronic message is released or the fax is transmitted or the letter delivered at the counter of the bank. The other participants shall be advised of the suspended through a similar communication immediately. The Central Bank shall notify all other participants about the withdrawal by a participant by giving 7 days advance notice. The Central Bank shall notify other participants about the re-admission of a suspended or temporarily withdrawn participant as soon as possible by sending a communication to that effect. 15. RULE 15 - DEFAULT PROCESSING 15.1 AUTHORITY The Central Bank has the authority to suspend a defaulting Participant, as per the provisions prescribed in these operating rules or as per the Banking Law NOTIFICATION OF DEFAULT This is governed by clause number 7 of the Agreement for the Provision of the Central Bank of Oman National Payment Systems Service agreement document PARTICIPANT OBLIGATION This is governed by clause number 8 sub section 8.2 of the Agreement for the Provision of the Central Bank of Oman ACH Service agreement document. PSD Page 46 of 67 ver

48 16. RULE 16 - OBLIGATION TO LAW (MISCELLANEOUS PROVISION) 16.1 CENTRAL BANK OF OMAN Notwithstanding anything to the contrary stated in the ACH Rules or any of the reference documents, the Central Bank and its officers, employees and/or agents shall not be liable to the Participants or any other third party for any losses and damages or expenses incurred by them directly or indirectly from any of the following: Delay caused due to breakdown, malfunctioning or deficiency of ACH system including hardware, software, telecommunication and electrical systems. Partial or complete disruption or failure of ACH to provide all or any other services provided by ACH. For the losses caused due to failure of the participants systems. The negligence, fraud, dishonesty, misconduct, unfamiliarity or omission of the participant or its official or employee in the use of ACH. However, the Central Bank shall be liable for Losses caused due to gross negligence or willful misconduct of its officers, employees or any other person acting under the direction of the Central Bank and has been found guilty of a reckless act or omission, or of intentional misconduct, proved in a final decision made by a competent court in the Sultanate of Oman FRAUD Any loss arising due to fraud originated at the Participant s business shall be borne by the relevant Participant. Central Bank is authorized to interrupt any transaction should Central Bank identify any suspicion of money laundering activities relating to a particular transaction FORCE MAJEURE The Central Bank or any Participant 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 ACH arising directly or indirectly from circumstances beyond its or his reasonable control, without limitation, strike, lockout, equipment malfunction, government action, riot and war CENTRAL BANK PERSONNEL PSD Page 47 of 67 ver

49 Nothing in this rule (15) shall prejudice the liability to the Central Bank or officers, employees or agents of the Central Bank for their acts or omissions as specified by the laws of the Sultanate of Oman OFFICERS, EMPLOYEES AND AGENTS The Central Bank retains the benefit of Rule 16 subsection 16.1 and 16.2 for itself and for the benefit of its officers, employees and agents EMERGENCIES If any malfunction, breakdown, or interruption or any emergency affects ACH or its operations, transactions shall be handled in accordance with the directions of the Central Bank. Without limiting the discretion of the Central Bank, the Central Bank may extend the hours of operations of ACH or reduce, pause any Participant as provided in Section 4.9, direct the use of contingency facilities or close down ACH in whole or in part. the Central Bank shall not be liable for any directions so given PARTICIPANTS ACT AS PRINCIPALS Each participant shall be liable as principal in respect of its payment messages ASSIGNMENTS No Participant shall assign all or any of its rights or obligations under the Control Documents. The Reference Documents bind the successors of each Participant DISPUTE SETTLEMENT In the event of any unresolved disputes or claims arising between any persons in relation to these Operating Rules or any directives issued pursuant to them, the complainant may submit the dispute or claim for investigation and decision by the Central Bank s Banking Control Department GOVERNING LAW The Laws of the Sultanate of Oman govern these Operating Rules. 17. RULE 17 - CONTACT 17.1 HELP-DESK PSD Page 48 of 67 ver

50 Should there be any change the Central Bank will advise the Participant the contact number of the Payment Systems Department System Help Desk via or publishes them on the web-monitoring site of the ACH System CONTACT DETAILS Tel. Nos , , Ext 2024, 2025, 2026, 2027 Fax: Should there be any change in the contact details (Telephone & Fax No & Address) of the Payment Systems Department Manager and the In-Charge of the ACH System, Central Bank will advise the Participant via circulars, or by publishing them on the website of the Central Bank. 18. Appendices 18.1 Appendix I- Glossary 18.2 Appendix II List of Direct Participants 18.3 Appendix III - List of Indirect Participants 18.4 Appendix IV - List of Technical Participants with respective Settlement arrangements 18.5 Appendix V - CBO General Ledger Accounts 18.6 Appendix VI - Reasons for return of credit transfer 18.7 Appendix VII - Reasons for return of debit transfer 18.8 Appendix VIII Transaction Codes PSD Page 49 of 67 ver

51 18.1 APPENDIX I- GLOSSARY Term Definition Ref 1. ACH Payment System ACH Payment System is part of National Payment System being developed by the Central Bank in the Sultanate of Oman. The ACH system is an electronic platform which facilitates its participants a facility for presenting interbank retail payments in batches, to one another, in order to be netted by the system for calculating multilateral clearing balances for each of the participants and subsequent settlement, including those for future settlement dates. The payment instructions may include pre-authorised debit instructions, direct debit instructions or direct credit instructions. 2. Administrator/System Administrator A user role established in the ACH with responsibility to perform all daily maintenance of system parameters, participant /user/account information, business rules in order to suit operational requirements of the ACH participants. 3. Bank identifier code (BIC) A universal method of identifying financial institutions in order to facilitate the automated processing of telecommunication messages in financial environments. 4. BankNet A computer data communication network in Oman which adopts the Multi-Packet Label Switching (MPLS) technology. The BankNet is operated by Omantel and it provides services of sending/receiving multimedia information electronically amongst the subscribers Business Calendar Business Cycle Refer to Rule 3 Section 3.3 Business Hour Timetable Cancellation/cancelled A calendar of operating and non-operating(holidays) days of a payment system. The details and timings of various activities to be conducted during the day in the operation of a system on a business day. A mechanism whereby some or all transfers to/from a participant are excluded from the settlement process, effected at the instruction issued by either the sending participant, or authorized personnel of the ACH system PSD Page 50 of 67 ver

52 Term Ref 9. Clearing Account 10. Clearing Balance 11. Clearing house 12. Clearing system 13. Clearing/clearance 14. Commercial Banks 15. Credit transfer 16. Customer operator. Definition An account maintained by the ACH System for each participant in which debit or credit instructions are posted as and when received and validated by the system to arrive at the clearing balance. A net position of payment instructions drawn by or drawn on a member on or by other members, accumulated upto that point of time during a business day. This refers to the existing Clearing House Department of CBO, which is responsible for clearing and settlement of cheque, ATM and various Government transactions in Oman. A set of procedures whereby financial institutions present and exchange data and/or documents relating to funds or transfers to other financial institutions at a single location (clearing house). The process of transmitting, reconciling and, in some cases, confirming payment orders prior to settlement, the netting of payments for calculation of final positions for settlement. The banks operating in the Sultanate of Oman and licensed by the CBO to carry on the normal banking business subject to the conditions of licensing. (Also refer to Speciliased Banks) A payment order or possibly a sequence of payment orders made for the purpose of placing funds at the disposal of the beneficiary. Both the payment instructions and the funds described therein move from the bank of the payer/originator to the bank of the beneficiary, possibly via several other banks as intermediaries and/or more than one credit transfer system. A private person or an institution, on whose behalf (ordering customer) or in whose account (destination customer), a payment (debit or credit)is effected. PSD Page 51 of 67 ver

53 Ref Term Daily settlement Debit Cap Debit Transfer Decryption Default Deletion Digital signature Encryption Definition Completion of settlement on the day of value of all payments accepted for settlement. A limit on a participant s net debit position at any time of an operating day in the ACH. An instruction for debiting the designated payer s account for the purpose of placing funds at the disposal of the issuer of instruction. While the instruction moves from the bank of the issuer/originator of the instruction, funds described therein move from the bank of the payer to the bank of issuer/originator of instruction. The use of cryptographic algorithms to decode cipher text data into clear text which was earlier encrypted to prevent unauthorized observation. (See also encryption) Failure to complete a funds transfer according to its terms for reasons that are not technical or temporary, usually as a result of bankruptcy. Default is usually distinguished from a failed transaction. A mechanism whereby some or all transfers to/from a defaulting participant are excluded from the settlement process. In a netting scheme, other participants bilateral and/or multilateral net positions are recalculated. A string of data generated by a cryptographic method that is attached to a message to ensure its authenticity as well as to protect the recipient against repudiation by the sender. The use of cryptographic algorithms to encode clear text data (plaintext) into cipher text to prevent unauthorized observation. (see also decryption) 25. Exchange Transmission of permitted payment instructions between the participants and a system (e.g. ACH) 26. Exchange Session A pre-defined time-period during which the exchange of payment instructions takes place. PSD Page 52 of 67 ver

54 Ref Term Failure of settlement Field Final Final settlement Finality Financial liability Format Format validation Definition An event of net settlement ACH transaction which cannot be settled in the RTGS for want of adequate funds in one or more of the participant s settlement accounts in the RTGS. A data element(s) for which the identification, description and value representation has been predefined. Each data element constitutes an indivisible unit. Where a field consists of more than one data element, each forms a subfield. Fields may be:. Fixed length or variable length. Mandatory or optional. Restricted in the characters that may be used. A field can appear only once in a message, unless the rules specify otherwise. Some fields consist of several subfields Irrevocable and unconditional. Settlement which is irrevocable and unconditional. The discharge of an obligation by a transfer of funds that have become irrevocable and unconditional. Settlements in payment systems which are both unconditional and irrevocable are designated as final. Any liability that is a legal obligation to deliver cash or another financial instrument to another enterprise or to exchange financial instruments with another enterprise under conditions that are potentially unfavorable. The rules of layout, e. g, for a message type or field within a message type. That part of the processing which checks that a message format conforms to the message type rules. The checks include, among others: presence of mandatory fields absence of forbidden fields field length restrictions PSD Page 53 of 67 ver

55 Term Ref 35. Intraday liquidity 36. Key 37. Key length 38. Key management 39. Liability 40. Liquidity 41. Liquidity risk 42. Membership 43. Message type (MT) Definition character restrictions Funds that can be accessed during the business day, usually to enable financial institutions to make payments in real time. A unique series of digits used in combination with a cryptographic algorithm. The number of bits comprising an encryption key. The design of the life cycle of keys and the relationships between keys, which are used in a computer system for cryptographic purposes. Alternatively, when referring to a system in operation, the processes by which cryptographic keys used in a computer system are generated, stored and updated. A present obligation of the enterprise arising from past events, the settlement of which is expected to result in an outflow from the enterprise of resources embodying economic benefits. State of availability of funds and arrangements there for, vis-à-vis a settlement obligation, in the settlement account of a participant. The risk that a counter party (or participant in a settlement system) will not settle an obligation for full value when due. Liquidity risk does not imply that a counter party or participant is insolvent since it may be able to settle the required debit obligations at some unspecified time thereafter. Membership is a process whereby a prospective participant of a clearing an settlement system is evaluated on application on an eligibility criteria and allowed access to such a system if found eligible subject to compliance with the discipline prescribed in this behalf. The specification of each S.W.I.F.T. message by a three digit number showing the major area (category), the function (group), and the specific details (format). There is a set of rules for each message type. PSD Page 54 of 67 ver

56 Term Ref 44. National Payment System 45. Net position Definition Payment System existing and being developed/established in the Sultanate of Oman by the Central Bank. Please also see Payment System. A participant's net credit or net debit position in a netting system is the sum of the value of all the transfers it has received up to a particular point in time less the value of all transfers it has sent. If the difference is positive, the participant is in a net credit position; if the difference is negative, the participant is in a net debit position. The net credit or net debit position at settlement time is called the net settlement position. These net positions may be calculated on a bilateral or multilateral basis (see also net settlement, net settlement system) Net settlement Netting Obligation Participant The settlement of a number of obligations or transfers between or among counterparties on a net basis. See also Netting. An agreed setoff of mutual positions or liabilities between business partners or participants in a payment system. Netting reduces a large number of individual positions or liabilities to a smaller number of positions or liabilities. Netting can take different forms; these claims are legally enforceable to a varying extent in case of default by a participant (see also multilateral netting). A duty imposed by contract or law. A party that participate in the settlement activities operated by the ACH system. (See also RULE 2.1) 50. Payment message/instruction/order An order or message to transfer funds (in the form of a monetary claim on a party) to the account of the beneficiary. The order may relate either to a credit transfer or to a debit transfer Payment system Protocol A payment system consists of a set of instruments, banking procedures and, typically, inter-bank funds transfer systems that ensure the circulation of money. Procedures for the interchange of electronic messages between communicating devices. PSD Page 55 of 67 ver

57 Ref Queuing Receiver Term Definition A risk management arrangement whereby transfer orders are held pending by the originator/deliverer or by the system until sufficient cover is available in the originator s/deliverer s clearing account or under the limits set against the payer; in some cases, cover may include unused credit lines or available collateral. See also Caps. The participant receiving a message as identified by its registered address in the header of the message. 55. Repurchase agreement or REPO An agreement with a commitment by the seller to buy a security back from the purchaser at a specified price at a designated future date Request RTGS Security Settlement Settlement Agent Speciliased Banks Message sent to ACH to receive answer on status of the file/batch/individual transaction, etc. Real Time Gross Settlement System In relation to a Payment System, it involves protection from unauthorized physical as well logical access to the systems, live and stored data and data in transmission. A process of paying the obligations by the payers to the receivers in a Payment and Settlement System. A participant in the Payment System which undertakes to settle the obligations of another participant through its own settlement account in a Payment System. The banks operating in the Sultanate of Oman and licensed by the CBO to carry on the select banking business subject to the conditions of licensing. (Also refer to Commercial Banks) 62. S.W.I.F.T. Society for Worldwide Interbank Financial Telecommunication: a cooperative organization created and owned by banks that operates a network which facilitates the exchange of payment and other financial messages between financial institutions (including broker-dealers and securities companies) throughout the world. A S.W.I.F.T. payment message is an instruction to transfer funds; the exchange of funds (settlement) subsequently takes place over a PSD Page 56 of 67 ver

58 Term Ref 63. Sender 64. Sending bank 65. Sequence number 66. Server 67. Session key 68. Settlement 69. Settlement account 70. Settlement date 71. Settlement risk 72. Settlement system 73. Systemic risk Definition payment system or through correspondent banking relationships. The party sending a message as identified by its registered address in the header of the message. See Sender. A number attributed sequentially to a message and attached to it to prevent the duplication or loss of messages. A computer that provides services through a network to other computers. A cryptographic key which is used for a limited time, such as a single communication session or transaction, then discarded. The actual fulfillment of the clearing obligations, i.e. the transfer of the banks with net debit position to the banks with net credit position is called settlement. This transfer is carried out via a central counterparty. An account held by a direct participant in a CBO RTGS system for the purpose of processing payments. The date on which the parties to funds transfer transaction agree that settlement is to take place. The intended date is sometimes referred to as the contractual settlement date. A general term used to designate the risk that settlement in a transfer system will not take place as expected. This risk may comprise both credit and liquidity risks (see also credit risk/exposure, liquidity risk, A system used to facilitate the settlement of transfers of funds or financial instruments. The risk that the failure of one participant in a transfer system, or in financial markets generally, to meet its required obligations will cause other participants or financial institutions to be unable to meet their obligations (including settlement obligations in a PSD Page 57 of 67 ver

59 Term Ref 74. Tag 75. TCP/IP 76. Text (text block) 77. Text message 78. Transaction Reference Number 79. Transaction Type Code 80. Transfer 81. Value Date 82. Value date Definition transfer system) when due. Such a failure may cause significant liquidity or credit problems and, as a result, might threaten the stability of financial markets. A two digit identifier of a field, sometimes followed by a letter. It marks the presence and start of the field. A letter indicates the format option chosen for the field. Transmission control protocol/internet protocol: a set of commonly used communications and addressing protocols; TCP/IP is the facto set of communications standards of the internet. The part of a message which is enclosed between the header and the trailer. Free format message (MTn99). In RTPS text messages are also used for proprietary requests and reports. This field specifies the reference assigned by the Sender to unambiguously identify the message. A short abbreviated description or a code number to describe in brief category of a transaction. A code avoids a lengthy description in storage transmission process thereby saving on the storage and transmission space. Operationally, the sending (or movement) of funds or securities or of a right relating to funds or securities from one party to another party by (i) conveyance of physical instruments/money; (ii) accounting entries on the books of a financial intermediary; or (iii) accounting entries processed through a funds and/or securities transfer system. The act of transfer affects the legal rights of the transferor, transferee and possibly third parties in relation to the money balance, security or other financial instrument being transferred. Day on which a payment is due to be credited or debited to the receiving or paying participant in the payment system. The date on which funds are at the disposal of the Receiver. See also Day of Value, Settlement date PSD Page 58 of 67 ver

60 Ref 83. XML Term Definition Extensive Markup Language, which is a standards for describing data information by computer application software in a way which will facilitate exchange or sharing of information between different computer systems. It is a formal recommendation from the World Wide Web Consortium (W3C), and is similar to the HTML language of Web pages. Like HTML. XML contains markup symbols to describe the contents of data information. PSD Page 59 of 67 ver

61 18.2 Appendix II List of Direct Participants Bank Name Direct Participants Alliance Housing Bank Bank Melli Iran Bank Muscat Bank Dhofar Bank of Baroda Bank of Beirut Bank Saderat Iran Central Bank of Oman Habib Bank Limited HSBC Bank Middle East Ministry of Finance Muscat Stock Exchange Muscat Depository & Securities Registration Co National Bank of Abu Dhabi National Bank of Oman Oman Arab Bank Oman Development Bank Oman Housing Bank Oman International Bank State Bank of India Standard Chartered Bank Central Bank Departments CBO Payment Systems Department Finance Department Human Resources Department Banking Development Department Clearing House Accounting Department CBO Salalah Branch CBO Sohar Branch BIC ALLIOMRXXXX MELIOMRXXXX BMUSOMRXXXX BDOFOMRUXXX BARBOMMXXXX BABEOMRXXXX BSIROMRXXXX CBOMOMRUXXX HABBOMRXXXX BBMEOMRXXXX MOFOOMRXXXX XMUSOMM1XXX MDSROMR1XXX NBADOMRXXXX NBOMOMRXXXX OMABOMRUXXX ODBLOMRUXXX OHBLOMRXXXX OIBAOMMXXXX SBINOMRXXXX SCBLOMRXXXX CBOMOMRURTG CBOMOMRUFID CBOMOMRUHRD CBOMOMRUBDD CBOMOMRUCLH CBOMOMRUACC CBOMOMRUSAL CBOMOMRUSOH PSD Page 60 of 67 ver

62 18.3 Appendix III - List of Indirect Participants Indirect Participants State General Reserve Fund Ministry of Finance Customs Revenue Ministry of Finance Wadi AlDhika C/A Switch Suspense Account UAE Switch Account BIC SGRFOMRUXXX CUSTOMRUXXX WADIOMRUXXX ATMSOMRUXXX UAESOMRUXXX PSD Page 61 of 67 ver

63 18.4 Appendix IV - List of Technical Participants with respective Settlement Arrangements NIL PSD Page 62 of 67 ver

64 18.5 Appendix V - CBO General Ledger Accounts GL Account Code Description BIC of participant Transaction Type Code CURRENCY Cash Withdrawals and Cash CBOMOMRU 002/003 Deposit Operations FOREX Outgoing and Incoming Foreign CBOMOMRU 004/005 Transfers REPO REPO CBOMOMRU 007/015 Operations(Inception/Maturity) and Buy Back Operations REPOMSM MSM Transactions CBOMOMRU GOVTSEC Trading Operations(Inception, CBOMOMRU 008 Maturity) of T-Bills, OGDB,Coupon, Maturity) CDBKS Trading Operations(CD CBOMOMRU 021/022 issue/maturity) PAYROLL Pay Roll Transactions CBOMOMRU BKSFEES Collection of Banking Fees eg. CBOMOMRU 017 Licence fees BILLS Finance Bills Payment CBOMOMRU TBDISC Discounting with CBO CBOMOMRU BDIS Banking Deposit Insurance CBOMOMRU 022 Scheme PENSION Pension Funds CBOMOMRU 023 PSD Page 63 of 67 ver

65 18.6 Appendix VI - Reasons for return of credit transfer S. No. Reason description Code 1 Beneficiary Account Closed/Transferred 31 2 Beneficiary Account Blocked/Frozen 32 3 Beneficiary account number does not exist 33 4 Beneficiary details inadequate 34 5 Beneficiary reported deceased 35 6 RESERVED 36 7 RESERVED 37 8 RESERVED 38 9 RESERVED Others 40 PSD Page 64 of 67 ver

66 18.7 Appendix VII - Reasons for return of debit transfer S. No. Reason description Code 1 Insufficient funds/not arranged for/exceeds arrangement 1 2 Refer to payer (for reasons other than insufficient funds) 2 3 Effects not cleared may be presented again 3 4 Debit authority has not matured may be presented again 4 5 RESERVED 5 6 Debit authority revoked by the payer 6 7 RESERVED 7 8 Payer s account number does not exist 8 9 RESERVED 9 10 RESERVED RESERVED Payer s Account Closed/Transferred/Frozen Payer reported deceased RESERVED RESERVED RESERVED Payer s details inadequate Debit authorization required RESERVED RESERVED RESERVED RESERVED RESERVED RESERVED RESERVED RESERVED RESERVED RESERVED RESERVED Others 30 PSD Page 65 of 67 ver

67 18.8 Appendix VIII Transaction Codes CODE TRANSACTION PURPOSE 1 Alimonies 2 Allowances 3 Bills payment to vendors/companies 4 Corporate to Corporate Payments 5 Corporate to Customer Payment 6 Court Order 7 Credit Card Payment 8 Custodian/Nominees 9 Custom Duties 10 Customer to Corporate Payments 11 Customer to Customer Payment 12 Deposit Operations 13 Dividends 14 Foreign Currency Payments 15 Government Payments 16 Insurance Payments 17 Interest Payments 18 IPO 19 IPO Refund 20 Loan Disbursement 21 Loan Repayments 22 Market Shares Payment 23 Membership 24 Mortgage Payment 25 Monthly Salary 26 Advance/Leave Salary 27 Overtime Payment 28 End of the Service Benefits 29 Pension Payments 30 Bonus 31 Rent or Lease 32 Reversal of Credit/Debit transfer 33 Savings 34 Schools Fees 35 Service Payments 36 Social Payments 37 Tax Payments 38 Utility Payments 39 Others PSD Page 66 of 67 ver