Operating Rules for ACH Participants

Operating Rules for ACH Participants ver 6.01.01

Table Of Contents 1. RULE 1 - INTRODUCTION... 6 1.1 General...6 1.2 ACH Payment System...6 1.3 Objective...6 1.4 Membership...6 1.5 Ownership and Licensing...6 1.6 Operating Rules...6 1.7 Amendments to the Operating Rules...7 1.8 Usage of ACH...7 2. RULE 2 - PARTICIPANT ACCESS... 7 2.1 Participant Types...7 2.2 Participants Membership...8 2.3 Participant Identification...10 2.4 Responsibility of Direct and Indirect Participants...11 2.5 Technical Requirements for Direct and Technical Participants...11 3. RULE 3 - SYSTEM OPERATIONS... 13 3.1 Type of Operations...13 3.2 ACH Business Calendar...14 3.3 Business Cycle...14 3.4 Business Hour Timetable...15 3.5 Cancellation, Returns and Reversals of ACH transaction...17 3.6 Processing for suspended /excluded participants...18 3.7 End of Clearing Session Outgoing files to the Participants...19 PSD Page 1 of 67 ver 6.01.01

3.8 Settlement Management...19 3.9 End-of-the-Day Processing...19 3.10 Future Value Payments...20 3.11 Special Processing Days...20 3.12 Monitoring by the Central Bank...21 3.13 Authority of the Central Bank of Oman...21 4. RULE 4 TRANSACTIONS PROCESSING... 22 4.1 ACH File Submission Procedure...22 4.2 ACH File Specification...22 4.3 Validation Process...29 4.4 Cancellation of Payment Messages...30 5. RULE 5 PRE-AUTHORISED DIRECT DEBIT... 31 5.1 Authorisation...31 5.2 Processing...32 5.3 Dishonoured Preauthorised Debits...32 6. RULE 6 - RETURN PROCESSING... 32 6.1 Return of Credit Transfer...32 6.2 Return of Debit Transfer...33 7. RULE 7 SETTLEMENT OF PAYMENT... 34 7.1 Time of Settlement and settlement schedule...34 7.2 Settlement Process...35 7.3 Notification of Settlement...35 7.4 Failure of Settlement...36 7.5 Table of RTGS messages in the scheme...36 PSD Page 2 of 67 ver 6.01.01

8. RULE 8 DEBIT CAP MANAGEMENT... 36 8.1 Setting up of Debit Cap...36 8.2 Monitoring of the Debit Cap...36 8.3 Modification in Debit Cap...37 8.4 Payment instructions in excess of the Debit Cap...37 9. RULE 9 - FINALITY OF PAYMENT... 38 9.1 Obligations of the sender participant...38 9.2 Obligations of the receiving participant...38 9.3 Definition of Finality...38 9.4 Return of Funds...39 10. RULE 10 SECURITY CONTROLS... 39 10.1 Encryption of Message Transmission...39 10.2 PKI Security...40 10.3 Access Control...40 10.4 Participant Workstations...40 11. RULE 11 - TESTING, CERTIFICATION AND CHANGE CONTROL... 41 11.1 Participant Pre-requisite...41 11.2 Service Level Specification...41 11.3 Certification Requirement...41 11.4 Participants Responsibility...41 11.5 Authority of Effect Change...42 11.6 Mandatory Reporting by Participant...42 11.7 Internal operating guideline and procedure...42 11.8 Operations by Participants...42 11.9 Change Control...42 PSD Page 3 of 67 ver 6.01.01

12. RULE 12 - FEES AND CHARGES... 43 12.1 Transaction Fees and Charges...43 12.2 Collection of Fee and Charges...43 13. RULE 13 - EMERGENCY CONDITION... 43 13.1 Authority...43 13.2 Request for Extension...43 13.3 Failure of Clearing Settlement...44 13.4 Business Continuity...44 14. RULE 14 DISCIPLINE... 45 14.1 Authority...45 14.2 Suspension of Participant...45 14.3 Suspended Participants obligation...46 14.4 Suspension Notification...46 15. RULE 15 - DEFAULT PROCESSING... 46 15.1 Authority...46 15.2 Notification of Default...46 15.3 Participant Obligation...46 16. RULE 16 - OBLIGATION TO LAW (MISCELLANEOUS PROVISION)... 47 16.1 Central Bank of Oman...47 16.2 Fraud...47 16.3 FORCE MAJEURE...47 16.4 Central Bank Personnel...47 16.5 Officers, employees and Agents...48 16.6 Emergencies...48 16.7 Participants Act as Principals...48 PSD Page 4 of 67 ver 6.01.01

16.8 Assignments...48 16.9 Dispute Settlement...48 16.10 Governing Law...48 17. RULE 17 - CONTACT... 48 17.1 Help-Desk...48 17.2 Contact Details...49 18. APPENDICES... 49 18.1 Appendix I- Glossary...50 18.2 APPENDIX II LIST OF DIRECT PARTICIPANTS... 60 18.3 APPENDIX III - LIST OF INDIRECT PARTICIPANTS... 61 18.4 APPENDIX IV - LIST OF TECHNICAL PARTICIPANTS WITH RESPECTIVE SETTLEMENT ARRANGEMENTS... 62 18.5 APPENDIX V - CBO GENERAL LEDGER ACCOUNTS... 62 18.5 APPENDIX V - CBO GENERAL LEDGER ACCOUNTS... 63 18.6 APPENDIX VI - REASONS FOR RETURN OF CREDIT TRANSFER... 64 18.7 APPENDIX VII - REASONS FOR RETURN OF DEBIT TRANSFER... 65 18.8 APPENDIX VIII TRANSACTION CODES... 66 PSD Page 5 of 67 ver 6.01.01

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 1. 1.3 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 6.01.01

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 1.8.1 Compliance All Participants and the Central Bank shall comply with these Operating Rules. 1.8.2 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. 1.8.3 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. 2.1.1 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 6.01.01

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. 2.1.2 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. 2.1.3 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. 2.1.4 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 2.2.1 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. 2.2.2 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 6.01.01

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. 2.2.4 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. 2.2.5 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. 2.2.6 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. 2.2.7 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 2.2.8 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 6.01.01

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 E-Mail 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 6.01.01

2.4 RESPONSIBILITY OF DIRECT AND INDIRECT PARTICIPANTS 2.4.1 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. 2.4.2 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). 2.4.3 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. 2.4.4 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: 2.5.1 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 6.01.01

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. 2.5.2 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. 2.5.3 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. 2.5.3.1 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. 2.5.3.2 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. 2.5.3.3 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 6.01.01

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 6.01.01

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 6.01.01

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 6.01.01

Activity at the ACH Hours Duration 1. Start of the day 08.00 08.15 15 minutes 2. Business Day Initialization 08.15 08.30 15 minutes 3. Exchange Session I 08.30 10.00 90 minutes 4. Clearing for Session I 10.00 10.15 15 minutes 5. Exchange Session II 10.15 11.30 75 minutes 6. Clearing for Session II 11.30-11.45 15 minutes 7. Exchange Return Session 11.45-12.00 15 minutes 8 Pre-clearing (Adjustment) for 12.00-12.15 15 minutes session II 9 Clearing for Exchange Return 12.15-12.30 15 minutes Session 10 Settlement 12.30 13.00 30 minutes 11 Cancellation of uncleared 13.00 13.05 5 minutes instructions 12 Clearing Reports 13.05 13.15 10 minutes 13 Archiving 13.15 13.45 30 minutes 14 End of day 13.45 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 6.01.01

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 3.5.1 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. 3.5.2 Returns PSD Page 17 of 67 ver 6.01.01

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. 3.5.2.1 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. 3.5.2.2 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. 3.5.3 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 6.01.01

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 6.01.01

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. 3.10 FUTURE VALUE PAYMENTS 3.10.1 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. 3.10.2 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. 3.11 SPECIAL PROCESSING DAYS 3.10.3 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 08.30 08.45 15 minutes 2. Business Day Initialization 08.45 09.00 15 minutes 3. Exchange Session I 09.00 10.15 75 minutes 4. Clearing for Session I 10.15 10.30 15 minutes 5. Exchange Session II 10.30 11.30 60 minutes 6. Clearing for Session II 11.30-11.45 15 minutes 7. Exchange Return Session 11.45-12.00 15 minutes PSD Page 20 of 67 ver 6.01.01

9. Pre-clearing (Adjustment) for 12.00-12.15 15 minutes session II 10. Clearing for Exchange Return 12.15-12.30 15 minutes Session 11. Settlement 12.30 13.00 30 minutes 12. Cancellation of uncleared 13.00 13.05 5 minutes instructions 13. Clearing Reports 13.05 13.15 10 minutes 14. Archiving 13.15 13.45 30 minutes 15. End of day 13.45 3.13.2 Normal Holidays ACH System operations shall not be available on normal holidays. 3.13.3 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. 3.12 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. 3.13 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 6.01.01

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 4.2.1 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 6.01.01

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 6.01.01

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. 4.2.2 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 MT102 3. 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 6.01.01

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 6.01.01

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 6.01.01

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 6.01.01

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). 4.2.3 Details of Batch content 4.2.3.1 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 6.01.01

4.2.3.2 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) 4.2.4 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. 4.2.5 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. 4.2.6 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. 4.3.1 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 6.01.01

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. 4.3.3 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 4.4.1 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 4.4.2 below. 4.4.2 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 6.01.01

ACH system shall not be available for cancellation of any transaction after the relative exchange session has closed. 4.4.3 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 6.01.01