PAYMENT SYSTEMS
D E PA R T M E N T
Operating Rules for RTGS Participants
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
TABLE OF CONTENTS
1. RULE 1 - DEFINITIONS
9
1.1
Introduction – General
9
1.2
RTGS Payment System
9
1.3
Objective
9
1.4
Membership
9
1.5
Operating Rules
9
1.6
Amendments of Operating Rules
10
1.7
Usage of RTGS
1.7.1
Compliance
1.7.2
RTGS Utility
1.7.3
Current Interbank Agreement
10
10
10
10
1.8
11
Reference Documents
2. RULE 2 - PARTICIPANT ACCESS
12
2.1 Participants
2.1.1
Membership
2.1.2
Admission of New Members
2.1.3
Prerequisites for the Participants
2.1.4
Suspension/Expulsion
2.1.5
Participants’ Withdrawal
2.1.6
Obligations on cessation
2.1.7
Revocation of Suspension
2.1.8
Notice period for suspension, expulsion, withdrawal and revocation.
12
12
12
12
12
13
13
13
13
2.2
Participant Accounts
2.2.1
Requirement for Participants Accounts
2.2.2
Collateral for Intraday Borrowings
2.2.3
Responsibility for maintaining sufficient liquidity
2.2.4
The Central Bank as a Participant
2.2.5
Record of Evidence
2.2.6
Cash Management Tool
14
14
14
14
15
15
15
2.3
15
PSD
Network Availability
Page 1
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
3. RULE 3 - SYSTEM OPERATIONS
16
3.1
Business Cycle
16
3.2
Business Timetable (Business day scheduling)
16
3.3
Interbank Transfer (Types of payment messages and operations
supported by RTGS)
22
3.4
Third Party Transfer (Customer Transfer)
23
3.5
Clearing Settlement
23
3.6 Cash Withdrawal and Deposit
3.6.1 Cash Withdrawal operation
25
26
3.7
Queue Management
29
3.8
Repurchase (Repo) (Intra day liquidity facilities)
30
3.9
Buy-back
30
3.10 Inquiry
3.10.1
Requests and management of reports
3.10.2
Management the current and proposed balances
30
30
31
3.11
31
Report (WEB Monitoring Workplace)
3.12 Future Value Payment (Future value dates: number of days in advance,
cancellation policy)
32
3.13 Timing
3.13.1
Cut-off Time
3.13.2
System Closure
32
32
33
3.14
33
Holiday Processing (Settlement on holidays)
3.15 Ownership & Licensing
3.15.1
Authority of the Central Bank of Oman
3.15.2
Monitoring by the Central Bank
33
34
34
4. RULE 4 - TRANSACTIONS
34
4.1
Categories of Payment Messages
34
4.2
Responsibility of Participants
35
PSD
Page 2
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
4.3
Payment Message Qualification
4.3.1
Time of Payment
4.3.2
Execution of Payment
4.3.3
Advice
4.3.4
Use of Routing Code
35
36
36
36
36
4.4
Transaction Reference Number (TRN)
4.4.1
TRN
4.4.2
Duplication
4.4.3
Cancellation of Payment Messages
37
37
37
37
4.5
Beneficiary Details
4.5.1
Obligations of the remitting Participant
4.5.2
Responsibility for correct Beneficiary details
4.5.3
Identification of Beneficiary
4.5.4
Money Laundering
38
38
38
38
38
4.6
Message Format
4.6.1
Message Formats
4.6.2
Priority of Messages
4.6.3
Details of Message Content
4.6.4
Unique key of transfers
4.6.5
Unique key of requests
39
39
43
43
44
44
4.7 Transaction Type Code
45
4.8
Irrevocability of Payment Message
4.8.1
Effect
4.8.2
Revocation of Payment Message
45
46
46
4.9
Queuing and Assignment of Priorities
4.9.1
Queuing
4.9.2
Setting and Amending Priorities of Payment Messages
4.9.3
Priority Codes
46
46
47
47
4.10
47
Participants non-availability
4.11 Responsibility of Receiving Participants
4.11.1
Payment Messages with Correct Beneficiary Account Number
4.11.2
Inability to Execute Payment
4.11.3
Value to Correct Beneficiary
4.11.4
Incorrect Account Number
4.11.5
Return of Payments
47
47
48
48
48
48
4.12 Interbank Payment
4.12.1
Definition
49
49
PSD
Page 3
Version 06.01.01
Central Bank of Oman
4.12.2
4.12.3
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Single Payments
Message Format
49
49
4.13 Customer Payment
4.13.1
Definition
4.13.2
Value date
4.13.3
Message Format
49
49
50
50
4.14 Same Day Value
4.14.1
Definition
4.14.2
Input Time
50
50
50
4.15 Future Value
4.15.1
Definition
4.15.2
Settlement
4.15.3
Time of Settlement
4.15.4
Queuing on Value Date
4.15.5
Notification of Settlement
4.15.6
Cancellation
4.15.7
Priority Change
50
50
51
51
51
51
51
51
4.16 Free Format Messages (Proprietary Messages)
4.16.1
Definition
4.16.2
Non Value Transactions
4.16.3
Control
4.16.4
Broadcast or Individual Messages
52
52
52
52
52
5. RULE 5 - PAYMENT TRANSMISSION
52
5.1
52
Transmission of Messages
5.2
Security – Encryption and Authentication
5.2.1
Common Principles
53
54
5.3
Payment Message Flow Scheme
5.3.1 Direct Participant to another Direct Participant
5.3.2
Direct Participant on Behalf of its Branch
5.3.3
Direct Participant to Another Direct Participant for its Branch
55
55
57
58
RULE 6 - LIQUIDITY MANAGEMENT
59
6.1
Intraday Repo with the Central Bank
6.1.1
Rules and Procedures
6.1.2
Repo requests to be initiated by the Participant Bank
6.1.3
Eligible Securities
6.1.4
Treasury Bills and the Central Bank Certificates of Deposit
6.1.5
Government Development Bonds
59
60
60
60
61
61
PSD
Page 4
Version 06.01.01
Central Bank of Oman
6.1.6
6.1.7
6.1.8
6.1.9
6.1.10
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Amount
Charges
Valuation
Usage of Intrday Repo Funds
Repo Threshold
61
61
61
61
62
6.2
Buy-Back of Intraday Repo with the Central Bank
6.2.1
Rules and Procedure
6.2.2
Authority of the Central Bank
62
62
63
6.3
Other Types of Repo (Inception & Reversal)
6.3.1
Rules and Procedures
6.3.2
Authority of the Central Bank
63
63
64
6.4
Settlement Process for REPO & Buyback transactions
64
6.4.1
Repo with the Central Bank using T-bill and the Central Bank CDs 64
7. RULE 7 - QUEUING MANAGEMENT
91
7.1
Principle of Queuing System
91
7.2
Priority Schemes
93
7.3
Queue Cancellation
94
7.4
Repriority of Queue
95
7.5
Grid Lock Resolution
95
7.6
End of Day
96
8. RULE 8 - CENTRAL BANK OF OMAN PAYMENT
96
8.1
General
8.1.1
Central Bank Transaction
96
96
8.2
Payments from Central Bank to Participants
8.2.1
Incoming Forex Payment
8.2.2
Treasury & Monetary Operations Payment
8.2.3
Central Bank Bills Payment
8.2.4
Payroll
8.2.5
Bank Deposit Insurance Scheme
8.2.6
Pension Fund
97
97
97
98
99
99
99
8.3 Payments from Participant to Central Bank
8.3.1
Outgoing Forex Payment
8.3.2
Treasury & Market Operations Payment
PSD
Page 5
100
100
101
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
8.3.3
Banking Fees payment to Central Bank
8.3.4
8.3.5
Bank Deposit Insurance Scheme
Pension Fund
102
102
102
9. RULE 9 - FINALITY OF PAYMENT
103
9.1
Definition of Finality
103
9.2
Irrevocability of Transfer
103
9.3
Dispute relating to Returns of Funds
104
10. RULE 10 - TESTING, CERTIFICATION AND CHANGE CONTROL
104
10.1
Participant Pre-requisite
104
10.2
Service Level Specification
104
10.3
Certification Requirement
105
10.4
Participants’ Responsibility
105
10.5
Basic Requirement of RTGS
105
10.6
Authority to Effect Change
106
10.7
Mandatory Reporting by Participant
106
10.8
Internal operating guideline and procedure
106
10.9
Operations by Participants
106
10.10
Change Control
10.10.1
RTGS changes:
10.10.2
Implementation of changes:
10.10.3
Advice of changes
107
107
107
107
11. RULE 11 - FEES AND CHARGE
107
11.1
108
Transaction Fees and Charges
11.2 Collection of Fee and Charges
108
11.2.1
MTn90: Advice of Charges, Interest and Other Adjustments
108
11.2.2
MTn91: Request for Payment of Charges, Interest and Other Expenses
108
12. RULE 12 - EMERGENCY CONDITION
PSD
Page 6
109
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
12.1
Authority
109
12.2
Request for Extension
109
12.3
Failure of Clearing Settlement
109
12.4 Business Continuity
109
12.4.1
Case 1: Failing of the Private Network at the Central Node
110
12.4.2
Case 2: Failing of S.W.I.F.T. and Private network on Central Bank site
111
12.4.3
Case 3: Failing of the RTGS Central Site
111
12.4.4
Case 4: Failing of WEB monitoring
111
12.4.5
Case 5: Failing of the Private Network on Participant site
112
13. RULE 13 - DISCIPLINARY
112
13.1
Authority
112
13.2
Suspension of Participant
113
13.3
Suspended Participant’s obligation
113
13.4
Suspension Notification
113
13.5
Re-admission
114
14. RULE 14 - DEFAULT PROCESSING
114
14.1
Authority
114
14.2
Notification of Default
114
14.3
Participant Obligation
114
15. RULE 15 - OBLIGATION TO LAW (MISCELLANEOUS PROVISION) 114
15.1
Central Bank of Oman
114
15.2
Fraud
115
15.3
Force Majeure
115
15.4
Central Bank Personnel
116
15.5
Officers, employees and Agents
116
15.6
Emergencies
116
PSD
Page 7
Version 06.01.01
Central Bank of Oman
15.7
15.8
15.9
15.10
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Participants Act as Principals
116
Assignments
116
Dispute Settlement
116
Governing Law
117
16. RULE 16 - CONTACT
118
16.1
Payment Systems Department Help-Desk
118
16.2
Contact Details
118
17. APPENDICES
119
Appendix 1
RTGS Participants
120
Appendix 2
Repo Operations
121
Appendix 3
Interbank Repo Operations
123
Appendix 4
Buy-Back Operations
126
Appendix 5 Request for Buy-Back transaction initiated by Participant
(Interbank REPO)
128
Appendix 6 Automated request for Buy-Back operation sent by RTGS to
Monetary Operations Domain
130
Appendix 7
Participant
(Interaction with MDSRC) REPO transaction initiated by
132
Appendix 8 (Buy-back operations) Request for Buy-Back transaction initiated
by Participant
134
Appendix 9
MDSRC
Automated request for Buy-Back operation sent by RTGS to
136
Appendix 10
Glossary of Terms
138
Appendix 11
Contacts Details
153
PSD
Page 8
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
1. Rule 1 - Definitions
1.1
Introduction – General
Central Bank of Oman (“the Central Bank”) in its capacity as the 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 Real Time Gross Settlement System (RTGS) in the
Sultanate of Oman.
1.2
RTGS Payment System
The Real Time Gross Settlement System (RTGS) is to provide Real Time
electronic funds transfer system with finality for all payments made by
the Participants on their own behalf or on behalf of their Customers for
the payments effected through the RTGS.
1.3
Objective
The RTGS payment system is intended to contribute to the efficient
operation of the financial system in the Sultanate of Oman. The payment
system (RTGS) is expected to enhance liquidity, 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 RTGS shall be mandatory to all commercial and
specialized banks operating in the Sultanate of Oman, or any entity as
approved/directed by the Central Bank.
1.5
Operating Rules
The rules shall govern the operations and the use of the “RTGS” as well
as the roles and responsibilities of the Participants and the Central Bank.
PSD
Page 9
Version 06.01.01
Central Bank of Oman
1.6
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Amendments of Operating Rules
These operating rules can be amended when deemed necessary, with the
consultation and consent of the Central Bank and the Operation SubCommittee of the Payment Strategy Committee.
Payment Systems Department of the Central Bank shall be responsible
for implementing the amendment to the document upon authorization
from the Central Bank.
1.7
1.7.1
Usage of RTGS
Compliance
All Participants and the Central Bank shall comply with these Operating
Rules.
1.7.2
RTGS Utility
Without prejudice to any laws of the Sultanate of Oman, all Participants
shall use RTGS for effecting interbank payments in Rial Omani. The
RTGS system is designed with business continuity plan which cope with
all different scenario of failure of any part of components, Participant
should refer to Rule 12.4 for the different procedure to follow under each
scenario of hardware, software or network failure.
1.7.3
Current Interbank Agreement
Any current Interbank agreements relating to Payments, such as the
Clearing House Rules, Repurchase Facility shall continue to remain in
force except to the extent that they are in conflict with these operating
rules.
PSD
Page 10
Version 06.01.01
Central Bank of Oman
1.8
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Reference Documents
The Operating Rules make reference to the following documents
(hereafter referred as “Reference Documents”) as a guideline for usage of
the RTGS:
a)
b)
c)
d)
PSD
RTGS Message Format
Payment Processing Schemes
Inquiry Processing Schemes
Dedicated Business Processing Schemes
Page 11
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
2. Rule 2 - Participant Access
2.1 Participants
2.1.1
Membership
RTGS membership for all commercial and specialized banks is
compulsory. A list of members is attached as Appendix 1.
2.1.2
Admission of New Members
The Central Bank may authorize the admission of new Participant in
RTGS provided that the Central Bank in its sole discretion deems that the
new Participant meets its qualifying criteria and executes the related
National Payment Service agreement, if not already done.
2.1.3
Prerequisites for the Participants
All initial and future Participants shall have relevant systems, procedures
and trained staff meeting the criteria set by the Central Bank from time to
time for participation in RTGS. The Central Bank shall additionally
monitor the 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 Criteria.
2.1.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
PSD
Page 12
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
license is revoked by the Central Bank, or the Participant fails to comply
with the operating rules of RTGS or any other reason deemed appropriate
by the Central Bank.
2.1.5
Participants’ Withdrawal
A Participant may opt to withdraw from RTGS 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 RTGS. The
participant shall comply with these directions.
2.1.6
Obligations on cessation
In the event the participant has been suspended or expelled or has
withdrawn from RTGS, all its pending payment messages shall be
canceled, however, the concerned participant shall continue to have
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.1.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 serve a
notice to that effect to all the remaining participants
2.1.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 electronically
or by fax or a letter addressed to the Senior Management of the
Bank/Participant immediately. The notice shall be deemed
delivered as soon as the electronic message is released or the fax is
PSD
Page 13
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
transmitted or the letter delivered at the counter of the bank. The
other participants shall be advised about the suspension through a
similar communication 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 readmission of a suspended or temporarily withdrawn participant as
soon as possible by sending a communication to that effect.
2.2
2.2.1
Participant Accounts
Requirement for Participants Accounts
It is mandatory for all Participants of RTGS to maintain a Settlement
Account at the Central Bank. The conditions stipulated by the Central
Bank from time to time shall apply for operation of the Settlement
Account.
2.2.2
Collateral for Intraday Borrowings
The Central Bank may stipulate the requirement of collateral for making
available the facility of Intraday borrowing in the accounts of the
participants. All participants shall comply with the stipulation.
2.2.3
Responsibility for maintaining sufficient liquidity
The Participants shall ensure that at any given time they are maintaining
sufficient balances in their accounts for effecting payments generated by
them including clearing settlement debit. It is the responsibility of each
Participant to monitor their settlement accounts for the purpose of
maintaining liquidity and complying with the Rules of RTGS. The
Central Bank shall have no responsibility for monitoring accounts of the
Participants.
PSD
Page 14
Version 06.01.01
Central Bank of Oman
2.2.4
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
The Central Bank as a Participant
The provisions of section 2.2.3 above shall not apply to the Central Bank
in its capacity as a Participant.
2.2.5
Record of Evidence
The account maintained by the Participant in the books of the Central
Bank is the evidence of the Participant’s clearing account and shall be
binding on the Central Bank and the Participant in the absence of
manifest error.
2.2.6
Cash Management Tool
RTGS shall provide account reporting and enquiry facilities operating in
real-time environment to the Participant, which shall provide to each
Participant an immediate visibility of the position in its account at the
Central Bank. This facility shall enable the Participant to manage its
liquidity. The Central Bank in its role as regulator and Operator of RTGS
shall have full access and authority to generate transactions and access
information on Participants accounts.
2.3
Network Availability
The total availability of the system RTGS depends on the availability of
every link of network. The platform of the participant communicates with
the RTGS 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 RTGS. In standard realization
RTGS allows to change the network for communication any time during
PSD
Page 15
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
a business day, participant must inform the Central Bank of alteration of
parameters of the participant by the authorized personnel of the Central
Bank, in one hour advance notice.
The processing of messages is independent of types of networks used for
their transport within the V-shaped model.
RTGS application provides same functions for transaction for both
SWIFT and private network connectivity. System supports parallel
operations of SWIFT and private network.
3. Rule 3 - System Operations
3.1
Business Cycle
a)
RTGS shall advise Participants of the business days of RTGS
operations. All private sector banking days shall be the RTGS
working days unless the Central Bank issues a circular to the
contrary. The Central Bank has the sole authority to declare
holidays for RTGS System. The date format in RTGS shall follow
the Gregorian calendar.
b)
RTGS shall define the operating timings in advance, any change in
the timing shall be informed to the Participants in advance. Each
new working day shall have its own value date in accordance to the
Gregorian calendar. Any changes to the value date or the timings
for the system, shall be informed to the Participants through
electronic mode or otherwise.
3.2
Business Timetable (Business day scheduling)
Business day administration
The Central Bank shall perform the RT Business Day Administration
Workplace in RTGS for Participants to follow. This workplace allows to
PSD
Page 16
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
input the days off in the calendar of the system and can be used to declare
special bank holidays (not known before).
The administrator of the business day can if necessary suspend a period
or a business day and resume it back. A message is broadcast to all the
participants to inform them about these events. All the payments accepted
during suspension are rejected.
Normal Business day schedule: (Saturday to Thursday)
The Normal Business Operating hours of the RTGS are as indicated in
the following Tables
Table 1. Normal Business Working day schedule of the RTGS System
Legend : CT= Customers Transactions, IT= Inter Bank
Transactions, GLO =General Ledger Operation, BB=Repo BuyBack,
FRX=Foreign Exchange Transaction, CWD= Currency Withdrawal,
FVD=Forward Value Transaction, CLT=Clearing Transaction
‘+’ indicates, access to RTGS permitted
System start
1.
2.
3.
Adjustment of balances with
General Ledger
Exchange
period
for
Customer and Interbank
payments
(incl.
REPO
operations).
Notification of Participants
about Net positions. Covering
by Participants their Net
PSD
CLT
FVD
CWD
FRX
BB
REPO
GLO
Timi
ng
CBO
Period in RTGS system
IT
N
N
CT
‘-‘ indicates, access to RTGS not permitted
08:00 - - - - - - - - - 08:15
08:15 - - - + - - - - - 08:30
08:30 + + + - + + + + + +
12:00
Page 17
Version 06.01.01
Central Bank of Oman
4.
12:30
5.
13:00
13:00
6.
13:15
Unsettled
Payments 13:15
7. cancellation
13:20
Statement reports
13:20
8.
13:30
End-of-day
reconciliation 13:30
9. with Participants
14:00
Archiving
14:00
10.
14:30
11. System stop
14:30
CLT
FVD
+ + + + +
CWD
-
FRX
BB
GLO
CBO
12:00 + + + 12:30
REPO
Debit positions. Settlement of
Clearing transaction in RTGS
system
Exchange
period
for
Customer and Interbank
payments
(excl.
REPO
operations).
Notification of Participants
about Net positions. Covering
by Participants their Net
Debit positions. Settlement of
Clearing transaction in RTGS
system
Exchange
period
for
Interbank payments and BuyBack operations
Automated
Buy-back
transaction
Timi
ng
IT
Period in RTGS system
CT
N
N
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
-
+ -
-
-
+ -
-
+ +
-
-
-
-
-
+ -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+ -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
The business day schedule is subject to change by Central Bank
authorities.
PSD
Page 18
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
The Central Bank reserves the right to alter the start, end time of each
business period depending on the operating environment. The Central
Bank shall communicate by a circular, broadcast or equivalent
communication means if there is a change in the business hours for a
specific date.
System start
1.
2.
3.
4.
Adjustment of balances with
General Ledger
CLT
FVD
CWD
FRX
BB
08:30 - - - - - - - - - 08:45
08:45 - - - + - - - - - 09:00
09:00 + + + - + + + + + +
12:00
Exchange
period
for
Customer and Interbank
payments. (incl. REPO
operations).
Notification of Participants
about
Net
positions.
Covering by Participants
their Net Debit positions.
Settlement
of
Clearing
transaction in RTGS system.
Exchange
period
for 12:00 + + + Customer and Interbank payments
(excl.
REPO 12:30
operations).
Notification of Participants
about
Net
positions.
Covering by Participants
their Net Debit positions.
Settlement
of
Clearing
transaction in RTGS system.
PSD
REPO
GLO
Timi
ng
CBO
Period in RTGS system
IT
N
N
CT
Table 2. RTGS Ramadan Working day schedule.
Page 19
-
+ + + + +
Version 06.01.01
Central Bank of Oman
FVD
-
-
+ -
-
+ +
-
-
-
-
-
+ -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+ -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
CLT
CWD
+ -
FRX
BB
-
CBO
REPO
12:30
5.
13:00
13:00
6.
13:15
Payments cancellation
13:15
7.
13:20
Statement reports
13:20
8.
13:30
End-of-day
reconciliation 13:30
9. with Participants
14:00
Archiving
14:00
10.
14:30
11. System stop
14:30
GLO
Exchange
period
for
Interbank payments and
Buy-Back operations
Automated
Buy-back
transaction
Timi
ng
IT
Period in RTGS system
CT
N
N
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Description of the periods of a Business day
System start
Period is launched in offline mode of the system during which the system tests
connections and issues an alarm for the administrator in case of problem.
Adjustment of balances with General Ledger
Further the balances of accounts are updated from an interface with general ledger.
When this processing is ended, the system shall be opened to exchanges.
Exchange periods for Customer and Interbank payments (including
Repo)
During these periods the participants can exchange their interbank
transfers and transfers of their customers.
After receiving of Net transaction RTGS tries to settle it, Net transactions
generated by clearing system include Cheque Clearing and ATM Switch.
In case of this transaction is queued, RTGS issues notifications to
Participants having not enough funds to cover their Net Debit positions.
PSD
Page 20
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Participants must cover their Net Debit positions to allow settlement of
Clearing transaction.
Participants can perform Repo to request Intraday liquidity for their
settlement accounts.
• Exchange periods for Customer and Interbank payments
(Excluding Repo)
The functions allowed during this period are the same as previous period
in exception that the Repo request is not allowed.
• Exchange periods for Interbank payments
During these periods the participants can exchange their interbank
transfers only.
Automated Buy-back transaction
System generates reports on Settlement Accounts of the participants
which have outstanding Repo’s not bought back.
• Unsettled Payment Cancellation
During this period, all unsettled payments which are queued in the RTGS
shall be automatically cancelled before End of the Day process starts.
Statement reports
The Central Bank shall report to the Central Bank General Ledger the
details of settled transactions that have taken place on the Settlement
Accounts of participants.
End-of-day reconciliation with Participants
The period during which the Participant inquires/requests from the
system the statements of their RTGS transactions for the current business
day.
If the participant cannot reconcile their daily payments with the statement
report from RTGS, they should immediately inform Central Bank
Payment Department for further investigation. Central Bank Payment
Department will provide instruction on a case by case basis to ensure that
the Participant can identify the possible cause of error and take the
corrective action such that Participant can continue normal processing on
the next business day.
Archiving
PSD
Page 21
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Archiving is to perform housekeeping of history transactions and data so
they are backup to online archive database or external storage.
System stop
System shall shutdown and the current business day shall end.
3.3
Interbank Transfer (Types of payment messages
and operations supported by RTGS)
RTGS manages the following types of payment instructions:
• Credit transfers between two participants (including the Central Bank
operations) corresponding to high-value/urgent payment instructions
or secondary payments related to these transactions. The sending
participants issue individual credit transfers that can be of two types:
the general financial institution transfer (MT202 S.W.I.F.T.
Messages), and the customer transfer (MT103 S.W.I.F.T. Messages).
• The Central Bank operations containing payment instructions input by
Central Bank staff and involving participant’s settlement accounts.
They could be related to the Central Bank Forex Settlement,
fees/penalty collection, payroll payments, monetary policy transfers,
other payments entered by the Central Bank departments (MT202).
• Enforcement collections are transfer operations initiated by the Central
Bank staff on the basis of third party's order (e.g. a judicial authority)
in order to transfer funds from one participant’s settlement account to
another settlement account (MT202).
• The settlement of the authorized net systems balances (mass payments
clearing system, cash part of the securities operations), based on
MT971 messages.
MT103, MT202 are the main payment instruments for credit transfers.
Each instruction may include additional information that specifies the
purpose of the transaction, e.g. the operation code, DVP/PVP details,
etc.). As a rule, field :72: is used for these purposes.
PSD
Page 22
Version 06.01.01
Central Bank of Oman
3.4
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Third Party Transfer (Customer Transfer)
Please refer above 3.3 for guidance.
3.5
Clearing Settlement
PartC
PartB
RTS/X
PartA
Clearing
system
1: Clearing results
Validation
KO
2: Validation
error notification
KO
OK
OK
KO
Possible
to settle
now?
KO
3: Participants
Clearing
Position
report
Waiting
for
settlement
OK
4: Debit
confirmations
OK
5: Credit
confirmations
OK
6: Settlement
notification
OK
Cancellation
of Clearing
transaction
7: Cancellation
notifications
8: Cancellation
notification
During exchange window, the Central Bank Clearing House 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. The
system doesn’t suspend ordinary settlement procedure during this period.
PSD
Page 23
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
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.
Clearing settlement includes ATM Settlement, Cheques for different
branches shall have the same high priority.
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.
If one Participant cannot fund their account and fulfill obligation, the
Central Bank shall not rewind and cancel all clearing transactions for that
Participant. The options for remedial action in this situation are:
1) The Central Bank demand the Participant borrows funds from the
interbank market;
2) Participant to request for liquidity via Repo.
Table of messages in the scheme
Sequential number of
SWIFT
Name of message in the
message in the
message type
diagram
1
MT971
Clearing transaction
2
MT996
Validation error notification
3
MT986
Participants Clearing Position
diagram
PSD
Page 24
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Sequential number of
SWIFT
Name of message in the
message in the
message type
diagram
diagram
report
4
MT900
Debit confirmation
5
MT910
Credit confirmation
6
MT296
Settlement notification
7
MT296
Cancellation notification
8
MT971
Cancellation notification
3.6 Cash Withdrawal and Deposit
Three Central Bank settlement accounts shall be set up for cash
withdrawal/deposit at Muscat, Sohar, Salalah respectively. When a
branch of a participant needs to perform cash withdrawal from the
corresponding Central Bank branch, it shall arrange through its head
office to send cash withdrawal request to RTGS. Participant presents
document to the Central Bank branch to withdraw funds after settlement
takes place between participant settlement account and Central Bank
branch account. Vice versa for Cash deposit (Central Bank branch
transfers funds from Central Bank branch account to participant's
settlement account via RTGS). For transfer of funds between any two
Central Bank branches, the sending branch sends request to RTGS as
normal payment message. The currency shall be Omani Rial (OMR) only.
The denomination for cash withdrawal/deposit (e.g. number of 20 OMR
notes, 10 OMR notes, etc.) should be indicated in MTn98 message
narrative fields.
PSD
Page 25
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
3.6.1 Cash Withdrawal operation
DPA
C urrency
D epartment
R T S/X
1: R eq uest fo r
cash withd raw al
2: C ash W ithd rawa l
rejectio n
KO
Valid atio n
OK
3: C ash W ithd rawal
C onfirma tio n
4: T ransfer
KO
KO
5: Validatio n
erro r notificatio n
6: S ettlement
d elay no tificatio n
Valid ation
OK
KO
KO
P ossib le
to settle
no w?
W aiting
fo r
settlement
OK
KO
OK
7: Deb it
co nfirmatio n
10 : C ancellatio n
notificatio n
OK
End -o f-day
canc ellatio n
8: T ransfe r
OK
9: C red it
c onfirmatio n
OK
Business scheme description
1) Direct Participant A sends a Request for Cash withdrawal to Currency
Department via RTGS (MT298). RTGS checks the syntax of this
message and routes this message to the Currency Department
application (Step 1). As general rule, the cash withdrawal is requested
for the next business day. Request for today is an exception,
2) The Currency Department application validates the Participant’s
request and notifies this Participant about the result of the validation.
3) Direct Participant A sends a payment request to RTGS (MT202) with
Cash Withdrawal Transaction Type Code. Upon receiving of this
order the system shall debit Settlement Account of this Participant and
PSD
Page 26
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
credit Settlement account of Central Bank (Step 4). This order should
contain reference to Cash withdrawal confirmation (from step 3),
4) RTGS validates this message and notifies Direct Participant A in case
of rejection of the request due to errors found during validation
procedure (MT296) (Step 5),
5) If the transfer is sent for today business day RTGS tries to settle this
request and notifies Direct Participant A in case of the request is
queued or suspended (MT296) (Step 6). The request for the next
business value day is put in a queue for the next business day,
6) The system presents the payment request for settlement. This payment
request is settled immediately if there are enough funds on account
and there are no payment requests with the same or higher priority
staying in a queue to this account. If this payment may not be settled
immediately, it is queued. After settlement of the payment request
Direct Participant A receives Confirmation of Debit (MT900) (Step 7)
7) Central Bank Currency Department receives a copy of payment
request (MT202) and Confirmation of Credit (MT910) (Steps 8-9). To
receive cash the Participant should present to Cash desk at the Central
bank the voucher containing related transfer Transaction reference
number (from step 4) and related Cash withdrawal confirmation
reference number (from step 3).
8) If this payment request remains queued or suspended at the end-of-day
it is cancelled automatically. Direct Participant A receives appropriate
notification (MT296) (Step 10).
Table of messages in the scheme
Sequential number
of message in the
diagram
1
2
3
SWIFT message
type
Name of message at the
diagram
MT298
MT298
MT298
4
5
6
MT202
MT296/ERROR
MT196/WAIT
Request for cash withdrawal
Cash Withdrawal Rejection
Cash Withdrawal
Confirmation
Transfer
Validation error notification
Settlement delay
PSD
Page 27
Version 06.01.01
Central Bank of Oman
7
8
9
10
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
notification
Debit confirmation
Transfer
Credit confirmation
Cancellation notification
MT900
MT202
MT910
MT196/CANC
3.6.2 Cash Deposit operation
Currency
Department
DP A
RTS/X
1: Transfer
KO
KO
2: Validation
error notification
Validation
OK
KO
OK
3: Settlement
delay notification
KO
Possible
to settle
now?
OK
Waiting
for
settlement
KO
OK
4: Debit
confirmation
7: Cancellation
notification
5: Transfer
OK
6: Credit
confirmation
OK
End-of-day
cancellation
Business scheme description
1) Currency Department sends a payment request to RTGS (MT202)
with Cash Deposit Transaction Type Code. This payment request
debit special account of Central bank intended for Cash Deposit
operations and credit Settlement Account of Direct Participant A (Step
1),
2) RTGS validates this message and notifies Central Bank Currency
Department in case of rejection of the request due to errors found
during validation procedure (MT296) (Step 2),
3) RTGS tries to settle this request and notifies Central Bank Currency
Department in case of the request is queued or suspended (MT296)
(Step 3),
PSD
Page 28
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
4) After settlement of the payment request Central Bank Currency
Department receives Confirmation of Debit (MT900) (Step 4),
5) Direct Participant A receives a copy of payment request (MT202) and
Confirmation of Credit (MT910) (Steps 5-6),
Table of messages in the scheme
Sequential number
SWIFT message
of message in the
type
diagram
1
MT202
2
MT296/ERROR
3.7
3
MT196/WAIT
4
5
6
7
MT900
MT202
MT910
MT196/CANC
Name of message at the
diagram
Transfer
Validation error
notification
Settlement delay
notification
Debit confirmation
Transfer
Credit confirmation
Cancellation notification
Queue Management
Transaction may be executed if:
• all accounts that must be debited have enough available balance to
execute all the debited entries of the transaction;
• debited accounts are not lock for debit;
• credited accounts are not locked for credit
• other restrictions are not applicable.
If a payment cannot be settled because the debit participant does not have
sufficient funds in the settlement account, the payment will be put in a
queue. The payment in the queue will be processed according to their
priority value and their time of creation (Priority + FIFO) order. Priority
is a positive integer from 1 to 99, which is used to arrange the payment in
a queue
PSD
Page 29
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Transactions are executed according to the “priority+FIFO” principle: the
transactions with the same priority value are put in a queue according to
the time of their processing, “First In First Out”.
3.8
Repurchase (Repo) (Intra day liquidity facilities)
The Intraday liquidity facilities are set up by Monetary Operations
Domain and MDSRC application.
The basic rules for included REPO functionality are listed below:
• Each payment transaction is associated with “Transaction Type code”
that defines the nature of this transaction and determines the way of its
processing;
• REPO and Buy-back transactions have their own Transaction Type
codes;
• As a rule, each Buy-back transaction is referred to related REPO
transaction by using additional information within payment order (as a
rule, fields :21: and :72: in the SWIFT message);
3.9
Buy-back
Please refer above in 3.8 for Buy-back rules
3.10
3.10.1
Inquiry
Requests and management of reports
The system allows the participants to address requests on the state of
processing of a given payment, to acquire a copy from it, to show
payments in queue, to acquire details of account status, etc.
Participant platforms shall accept the notifications on settlements that
they issued, the answers to their requests, the orders of payment accepted
for their accounts, the notifications of debit and credit, and also the
PSD
Page 30
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
unsolicited messages broadcasted by the system to a particular participant
or to all the participants.
3.10.2 Management the current and proposed balances
Message exchange between the system and the participants allows to
receive all the necessary information to manage the balances of the
accounts. The statistical management of balances is included in the
standard installation.
3.11
Report (WEB Monitoring Workplace)
This workplace uses a standard Web browser to monitor accounts, queues
and other financial information. As a rule, this workplace is installed at
the Participant’s sites.
The following functions are provided by Web Monitoring workplace:
• View list of published downloads - user can download published
information, which belongs either to him particularly or to all users
• View list of messages (event alerts) sent by system - either private or
common;
• View RTGS Business Days list and their statuses;
• Download of offline reports
• Get list of accounts of current user participant;
• View account summary of specified own account;
• View transactions on specified account with wide range of filtering:
o Transaction type;
o Transaction owner;
o Transaction status;
• View details of selected transaction;
• View list of RTGS participants with opportunity to sort list by each
information field;
• View selected participant common information;
PSD
Page 31
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
• View current Business Day schedule;
• View list of value dates for selected Business Day Period;
• View broadcast messages
3.12
Future Value Payment (Future value dates:
number of days in advance, cancellation policy)
The RTGS provides a Value Date checking function for all Payment
Instructions. Payments with current Value Date are transmitted to the
settlement engine immediately after authorization. The RTGS shall
accept future Value Date payments and store them for settlement on the
value date. The number of future value date allowed is 2 business days
Two future business days shall be set up initially (actual date shall be
added accordingly if there is any non-business holidays in between).
The Central Bank has the right to modify the future value date range by
communicating via circular in advance .
3.13
Timing
Please refer to 3.1 & 3.2 above. Additionally this timetable is subject to
change by the Central Bank. The Central Bank shall send a broadcast
message informing the participants of the change in the Business Day
Time Table)
3.13.1
Cut-off Time
The Central Bank has the right to cut-off the system at the
specified cut-off time, and cancel or forward the queued
transactions with insufficient liquidity for next working day
business cycle.
PSD
Page 32
Version 06.01.01
Central Bank of Oman
3.13.2
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
System Closure
The Central Bank reserves the right to close the RTGS System or
parts of it for the purposes of maintenance, technical corrections, or
installation/enhancements of systems, or other reason that the
Central Bank deems fit.
3.14
Holiday Processing (Settlement on holidays)
The Central Bank shall allow payments of the following Transaction type
codes to be processed for settlement on Fridays or Holidays:
Transaction Type code
004
005
Description
Outgoing forex payment
Incoming forex payment
When the business day cycle on a business day before Friday or Holiday
is completed, the Central Bank shall perform settlement with Friday or
Holiday value date using a special business day schedule. After the
special business day schedule is completed, the Central Bank shall close
the system. System shall only be started again on the next business day.
Participants need to be aware of this arrangement, as they shall need to
ensure their settlement accounts have sufficient fund at the end of
Thursday business day.
Similar procedure shall be adopted for processing other transaction type
payments due on any scheduled holidays. Further, in case of unscheduled
holidays (not known before), the forward value payments maturing on
such holidays shall also be settled in the similar manner.
3.15
Ownership & Licensing
The RTGS system is operated by the Central Bank who licenses the
Participants to use the RTGS Systems strictly in accordance with the
terms and conditions of the Operating Rules laid down in this regard. The
Central Bank is empowered to regulate the operations and usage of the
RTGS as it deems fit.
PSD
Page 33
Version 06.01.01
Central Bank of Oman
3.15.1
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Authority of the Central Bank of Oman
a)
b)
c)
d)
3.15.2
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
RTGS between the Central Bank and the Participants.
Day-to-Day control over the management of operations of
the Central Systems and the technical aspects of RTGS
including the communication between Central System and
the Gateways.
The
Management
of
systems
capacity
and
telecommunications traffic.
To regulate, administer and monitor RTGS.
Monitoring by the Central Bank
a)
b)
c)
Monitoring the activities of each Participant in the RTGS
System electronically and by physical inspection.
To be satisfied that the Participants are operating the RTGS
strictly in accordance with the related agreements, rules and
regulations that govern RTGS.
Control the risk management aspects in the system that
include but are not limited to credit and liquidity risk.
4. Rule 4 - Transactions
4.1
Categories of Payment Messages
RTGS shall handle the following types of Payment Messages:
a)
b)
PSD
Payment messages favouring customers or Inter-bank
Payment Messages for Same-day or forward value as per
provisions mentioned in this section
Page 34
Version 06.01.01
Central Bank of Oman
c)
4.2
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
The value date on the Payment Message at the time it is
processed by RTGS shall define whether the payment is for
same-day value or future value, and the relevant payment type
to be used in notifying the Receiving Participant.
Responsibility of Participants
It is the responsibility of each Participant to ensure that it generates the
correct payment messages that meet the Operating Rules of RTGS.
4.3
Payment Message Qualification
To process the messages in RTGS they shall have the following prerequisites:
a)
b)
c)
d)
e)
PSD
Messages should have payment currency as Omani Rials or any
other currency as authorized from time to time by the Central
Bank.
The Messages are unconditional payment orders subject only to
availability of sufficient funds in the Settlement Account of the
payor participant.
The Payments are for a value date, which is a valid Business
Day as defined by RTGS. In case of Forward payment
messages, such payment messages shall be processed on the due
value date (refer to paragraph f) below
The messages must be compliant with relevant SWIFT Message
Type format rules.
The payments are favouring or for an account of the
Participants with RTGS.
Page 35
Version 06.01.01
Central Bank of Oman
f)
4.3.1
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
The payments are for a value date, not earlier than the date of
entry, and not later than 2 Business days after the date of entry
excluding the date of entry.
Time of Payment
The amount specified in a Payment Message sent by a Sending
Participant shall be executed by RTGS immediately on its
acceptance by RTGS or, in the case of a queued or paused Payment
Message, when it is unqueued or unpaused provided it is not
cancelled. In the case of a forward value Payment Message, it shall
be executed at the beginning of the exchange period on the forward
value day concerned.
4.3.2
Execution of Payment
Payment Messages sent by a sending Participant shall be executed
in RTGS by debiting the amount to the Sending Participants
Settlement Account and Crediting the amount to the concerned
Receiving Participant’s Settlement Account. As between the
Sending and Receiving Participants the debit and credit constitute
unconditional payment of the amount specified in the Payment
Message.
4.3.3
Advice
The Sending and Receiving Participant shall be advised of the
execution of Payment Messages by RTGS.
4.3.4
Use of Routing Code
While sending a Payment Message in RTGS, the Sending
Participant must ensure that the correct SWIFT ID or Bank (See
Appendix 1) are quoted in Account with Institution field (57) for
PSD
Page 36
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
the appropriate Bank with which the beneficiary maintains account.
In the event the payment is favouring the receiving Participant field
(58) should contain the above details.
Central Bank will not be responsible for any consequence resulted
from delay in processing due to a sending participant inputting
erroneous field information. When Central Bank decides to
commence billing to participants for using RTGS system, Central
Bank reserves the right to charge a special penalty fee to the
sending participant for such an error.
In case, a Central Bank Department is the benefiaciary of the
payment, the correct control account (refer to Rule 8) must be
mentioned.
4.4
4.4.1
Transaction Reference Number (TRN)
TRN
Every message entered in RTGS must have a unique TRN that
cannot be repeated for any other message input in RTGS.
4.4.2
Duplication
RTGS shall reject any payment message that has the same TRN as
previously received on the same value date. A notice to the effect
shall be sent to the concerned participant. A transaction bearing the
TRN of a previously entered transaction on the same value date
shall be rejected by RTGS under intimation to sending Participant.
Where the message with duplicated TRN is similar in all respect it
shall be assumed to be a duplicate message and the messages shall
be ignored by RTGS and no notification shall be sent.
4.4.3
PSD
Cancellation of Payment Messages
Page 37
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
All requests for cancellation of payment message input in RTGS
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.
4.5
4.5.1
Beneficiary Details
Obligations of the remitting Participant
The remitting Participant must ensure that sufficient and clear
information is available in the Payment Message to facilitate the
Receiving Participant to identify the Beneficiary unequivocally,
however, the Sending Participant shall not be liable for any errors
or incompleteness in the information provided by its customer.
4.5.2
Responsibility for correct Beneficiary details
It shall be the remitters responsibility to provide the Sending
Participant with sufficient, correct and clear information to enable
the Receiving Participant to identify the Beneficiary unequivocally.
The sending Participant shall be responsible for transmitting
correctly the details provided to it by the customer.
4.5.3
Identification of Beneficiary
The Receiving Participant shall identify the Beneficiary of the
funds based on account number and in the absence of an account
number, by the name, address and any other identification details
provided in the payment message.
4.5.4
PSD
Money Laundering
Page 38
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Participants must comply with the Central Bank’s regulations and
the laws of the Sultanate of Oman for prevention of money
laundering and include details of the Beneficiary and Remitter in
each Payment Message.
4.6
Message Format
4.6.1
Message Formats
The message format shall support a SWIFT V-shape topology.
SWIFT BIC code (11 characters or 8 characters for HQs) should be
adopted as a unique identification code of the Participants. The
SWIFT BIC comprises an 8-character bank code and a 3-character
branch code. There are a few participants which are not yet
S.W.I.F.T members. As such, a SWIFT compatible BIC shall be
adopted for these Participants.
Participant using RTGS workplaces with GUI interface shall have
templates for proprietary messages [refer to RTGS Operator
Workplace, User’s Guide. And RTGS Controller Workplace,
User’s Guide].
For those participants who are not SWIFT members, they should
inform the Central Bank Payment Department in case they have
applied for a new SWIFT BIC code and become a SWIFT member
in future. Payment Department of the Central Bank will reconfigure the participant information in the RTGS and advise all
participants of any change
The system supports the following message set (Table ).
Table 3. List of message types in the system.
Legend: CB=Central Bank
No.
Message
type
1.
MT103
PSD
Description
To/From whom
should be sent
Single customer payment transfer
Page 39
Participant RTGS,
RTGS P i i
Version 06.01.01
Central Bank of Oman
No.
Message
type
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Description
To/From whom
should be sent
RTGS Participant
(Copy);
CB RTGS,
RTGS CB (Copy)
MT202
General Financial Institution transfer
Participant RTGS,
RTGS Participant
(Copy);
CB RTGS,
RTGS CB (Copy)
MT900
Debit confirmation. Confirms debiting of
an account when related transfer is settled
using RTGS service. Separate payment
within
clearing
service
is
not
accompanied with MT900 notification.
The only MT900 is generated and sent to
each Participant who has Net Debit
position at the end of clearing session.
Credit confirmation. Confirms debiting of
an account when related transfer is settled
using RTGS service. Separate payment
within clearing service is not accompanied with MT910 notification. The only
MT910 is generated and sent to each
Participant who has Net Credit position at
the end of clearing session.
Request to reject of non-settled (noncleared) transfer previously sent to the
system
Request for a status of transfer
RTGS Participant,
RTGS CB
2.
3.
MT910
4.
MT192 or
MT292
5.
6.
7.
8.
9.
MT195/STAT
or
MT295/STAT
MT195/DUPL
or
MT295/DUPL
MT195/PRTY
or
MT295/PRTY
MT985/STAT
10. MT985/SQDC
PSD
RTGS Participant,
RTGS CB
Participant RTGS;
CB RTGS
Participant RTGS;
CB RTGS
Request to get a copy of transfer Participant RTGS;
previously sent to the system
CB RTGS
Request to change a priority of non- Participant RTGS;
settled transfer
CB RTGS
Account status request
Participant RTGS;
CB RTGS
Request for RTGS payments queue Participant RTGS;
summary information and Clearing
Page 40
Version 06.01.01
Central Bank of Oman
No.
Message
type
MT920
11.
MT196/CANC
or
MT296/CANC
MT196/STAT
13.
or
MT296/STAT
MT196/DUPL
14.
or
MT296/DUPL
MT196/PRTY
15.
or
MT296/PRTY
MTn96/ERRC
16.
12.
17.
18.
19.
MT986/STAT
MT986/SQDC
MT986/PCPR
20.
21.
MT941
MT942
MT940
22.
MT950
23.
PSD
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Description
To/From whom
should be sent
Clearing CB RTGS
summary information and
payments not cleared yet
Request to get an account balance report
(MT942) or interim transaction report
(MT941)
Reply on request to reject of non-settled
(non-cleared) of transfer previously sent
to the system
Reply on a request for a status of transfer
Participant RTGS;
CB RTGS
RTGS Participant;
RTGS CB
RTGS Participant;
RTGS CB
Reply on request to get a copy of transfer RTGS Participant;
previously sent to the system
RTGS CB
Reply on request to change a priority of RTGS Participant;
non-settled transfer
RTGS CB
This message is generated if error occurs RTGS Participant;
in related request message processing.
RTGS CB
Reply to related account status request
RTGS Participant;
RTGS CB
Reply on related request for RTGS RTGS Participant;
payments queue summary information RTGS CB
and Clearing payments not cleared yet
Notification for Participant having no RTGS Participant
enough funds to cover their Net Debit
position
Interim transaction report that is RTGS Participant;
generated by related MT920 request
RTGS CB
Account balance report that is generated RTGS Participant;
by related MT920 request
RTGS CB
Final Statement report on all settlement RTGS Participant;
operation with specified account within a RTGS CB
current business day. Includes RTGS
payments only. Contains payment details.
Final Statement report on all settlement RTGS Participant;
operation with specified account within a RTGS CB
current business day. Includes RTGS
payments only
Page 41
Version 06.01.01
Central Bank of Oman
No.
Message
type
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Description
To/From whom
should be sent
MT971
24.
25.
26.
27.
28.
29.
30.
31.
Net balance positions from Clearing Net system RTGS
systems or other Net system (e.g.
Depository or Stock exchange) for
operations performed on net basis.
MT971
An answer to that system(s) in case of RTGS Net system
related transaction is rejected.
MT101
Request for payment transfer
Participant RTGS
Participant
MTn90
Advice of Charges, Interest and Other RTGS CB
Adjustments
MTn91
Request for Payment of Charges, Interest RTGS Participant
and Other Expenses
MTn98
Proprietary format message. It used as Participant RTGS
envelope to send messages of proprietary
Participant;
types
Participant RTGS
CB;
CB RTGS
Participant
These messages are free format messages. Participant RTGS
MT199/
TEXTMESSA CBO may also be issuer or receiver of this
Participant;
GE or MT999/ message. MT999 cannot be used for Participant RTGS
which
have
financial
TEXTMESSA messages
CB;
implications of any type.
GE
CB RTGS
Participant
Set of system
Request to change corresponding Participant RTGS
requests MT199 parameter of the system. It doesn’t (restricted set);
or MT999
contain field :21:.
CB RTGS (full set)
Set of system
replies MT199
32.
or MT999
Reply on related request. Reply contains RTGS Participant
field :21:.
(restricted set);
RTGS CB
(full
set)
Participant should follow the message format document in the [RTGS
Message Formats. User’s Handbook].
PSD
Page 42
Version 06.01.01
Central Bank of Oman
4.6.2
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Priority of Messages
The obligatory field :113: of the block 3 contains transfer priority.
Priority with value in the range 1-99 is assigned to RTGS payments that
shall be processed on “individual” basis.
For transfers sent to RTGS priority value should be assigned according to
the rules applied for the different types of the orders. (Refer to Rule 7.2)
Participant is associated with a list of priorities that Participant is allowed
to specify in the payment orders. In case of any Participant sends to the
system a transfer with priority not assigned to him, this transfer shall be
rejected during validation procedure.
4.6.3
Details of Message Content
This main information is the message 4 block. The fields to be used are
listed below.
Field :20: contains Transaction Reference Number. This field, in
conjunction with Participant’s BIC and Value Date of transfer composes
a unique key of transfer (see item 0).
Field :32A: contains Value Date, Currency Code and Amount.
The following fields (:50a:, :52a:, :53a:, :54a:, :56a:, :57a: , :58a, :59a)
contain information about the institutes which are used in the payment
process chain.
Fields :52a:, :53a:, :54a:, :56a:, :57a:, :58a: may contain letters A or D to
substitute the letter "a" after a field number. Option “A” is used when an
institution specified in the field is represented as BIC registered in
SWIFT; and option “D” is used otherwise.
Field :59a: should be filled according to Central Bank regulations. Option
“A” is used when an institution specified in the field is represented as
BIC registered in SWIFT; and no option is used otherwise.
Field :70: contains details of Payment.
PSD
Page 43
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Field :72: contains Sender to Receiver information. If a Participant sends
transfer to RTGS, this field may contain the purpose of payment to notify
RTGS about way of processing of this payment.
Field :72: shall be copied to the receiving Participant.
The following keyword may be used in this field:
1. /BNF/<information> for general purpose information
from Sender to Beneficiary.
2. /CODTYPTR/ shall be used to define transaction type
code to specify the payment instruction processing in
specific way [the list of codes is given in 4.7
3. /GLC/<Account_number> may be used in case of
transaction that credits Central Bank Settlement Sub
Account in the General Ledger. For GL account numbers
please refer to Rule 8.
4.6.4
Unique key of transfers
Each transfer is uniquely identified by the following group of fields:
a) Participant’s BIC, identifying the issuer of transfer
b) Transaction Reference Number (Field :20:)
c) Value Date (first 6 symbols of field :32A: or field :30:).
In case the transfer is not accepted by the system due to validation error it
may be corrected by Participant and then resent with the same unique key
except the “wrong value date” error. Nevertheless it is a good way to
resend such transfer with new unique key to avoid possible ambiguity in
the correspondence between Message Input Reference and transfer
identification.
4.6.5
Unique key of requests
Each request is uniquely identified by the following group of fields:
PSD
Page 44
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
a) Reference of request (Field :20:)
b) Participant’s BIC, identifying the issuer of request;
c) Current business day.
In case of erroneous request it should be corrected by Participant and then
resent with another reference of request.
4.7 Transaction Type Code
The /CODTYPTR/ keyword in field :72: shall be used to define
transaction type code to specify the payment instruction processing in
specific way.
Participants are authorized to use the following transaction type codes in
sending payment to RTGS system.
Trans
type code
1
2
4
8
17
18
21
22
23
Description
Ordinary transfers
Cash Withdrawal operations
Outgoing foreign transfers
Auction payment for T-bill and Government Development
Bond
Collection of Banking Fees e.g. License fees
Finance Bills Payment
Auction payment for CD
Bank Deposit Insurance Scheme
Pension Fund
Apart from above, the other transaction type codes are reserved to be
used by Central Bank only.
4.8
PSD
Irrevocability of Payment Message
Page 45
Version 06.01.01
Central Bank of Oman
4.8.1
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Effect
As soon as the payment message is sent it creates a binding
obligation on the Sending Participant to pay the Receiving
Participant the amount specified in the Payment Message in
accordance with these Operating Rules.
4.8.2
Revocation of Payment Message
Not withstanding the Provisions of Section 4.8.1 the Sending
Participant may cancel Payment Messages sent by it at any time
until the transaction is executed in RTGS by debit to its account.
The latest time by which a customer may request a Sending
Participant to revoke a Payment Message is such earlier time as
may be agreed between the customer and the Sending Participant
or, in the absence of agreement, not later than close of business on
the Business Day preceding the value date for the payment
concerned.
4.9
4.9.1
Queuing and Assignment of Priorities
Queuing
Except where it is expressly provided in these Operating Rules and
that queuing shall not apply to a particular Payment Message, when
sufficient liquidity is not available in a Sending Participant’s
Account with the Central Bank the Payment Messages for that
Participant shall be queued by RTGS until sufficient liquidity is
available. If sufficient liquidity is not available prior to the close of
the Operational Phase or the Business Day, and the Sending
Participant does not cancel the payment messages, the Central
Bank shall cancel the queued Payment Messages and shall not be
liable to the Sending or Receiving Participant for this action. The
payments relating to Clearing Settlements shall be excluded from
this provision.
PSD
Page 46
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Participant should perform a reconciliation of their daily total
payment transactions via RTGS, by checking statement of
messages, which are sent to them by RTGS at the end of each
business day.
4.9.2
Setting and Amending Priorities of Payment Messages
The Sending Participant may change the priority of the sequence in
which its queued Payment Messages are to be paid by RTGS. Each
Participant is responsible for managing its entry of Payment
Messages and other instructions and for the queuing of its Payment
Messages.
4.9.3
Priority Codes
The priority codes are assigned by:
a)
b)
4.10
Central Bank for Central Bank transactions
The Sending Participant for its originating payment
message
Participants non-availability
A Participant’s non-availability, other than by reason of its suspension,
does not affect the ability of other Participants to send Payment Messages
to it.
4.11
Responsibility of Receiving Participants
4.11.1 Payment Messages with Correct Beneficiary Account Number
The Receiving Participant upon receipt of payment message with
correct account number in the “Beneficiary Customer” field (Field
59), must credit the Beneficiary with same-day value as soon as
possible after receipt of notification of payment from RTGS, but
PSD
Page 47
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
not later than the end of the exchange period of the same Business
Day.
4.11.2
Inability to Execute Payment
If the Receiving Participant is unable to execute a Payment
Message, it is the responsibility of the Receiving Participant to
contact the Sending Participant for clarification.
4.11.3
Value to Correct Beneficiary
The Receiving Participant shall ensure that the value of the
payment is given to the correct Beneficiary as per the details in the
relevant Payment Message.
4.11.4
Incorrect Account Number
The Receiving Participant except in the case where the account
number is not provided, or is not correct for the Beneficiary stated
in “Beneficiary Customer” field (Field 59) must credit the
Beneficiary’s account as soon as possible but not later than 12.00
noon on the next business day. If the Receiving Participant is
unable to credit the Beneficiary by the afore-mentioned time, they
must return the payment not later than 12.00 noon one business day
after the value date stated in the payment message, without liability
for use of funds compensation.
4.11.5
Return of Payments
When a Receiving Participant is returning a payment to the
Sending Participant, either because it could not identify the account
or it was a payment to be collected which was not collected within
10 calendar days, the following rules apply:
a)
PSD
The message type must be an interbank payment.
Page 48
Version 06.01.01
Central Bank of Oman
b)
c)
4.12
4.12.1
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
The original transaction reference number (TRN) in (field
20) must be entered in field 21 (Related Reference).
The original TRN to be quoted in the field 72 (Sender to
Receiver Information) along with reason for
rejection/return.
Interbank Payment
Definition
An Interbank Payment Message format is used when the sending
participant and the Beneficiary are Participants.
4.12.2
Single Payments
Inerbank Payment Messages can be single, same-day or for future
value up to two working days.
4.12.3
Message Format
Interbank Payments Messages must follow SWIFT message format
rules set out in the RTGS Message Format User Handbook.
4.13
4.13.1
Customer Payment
Definition
A payment is a customer Paymentwhen either the remitter or the
Beneficiary or both are not RTGS Participants.
PSD
Page 49
Version 06.01.01
Central Bank of Oman
4.13.2
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Value date
Customer Payment Messages can be single, same-day or future
value date for up to two days.
4.13.3
Message Format
Customer Payment Messages must follow SWIFT message format
rules set out in the RTGS Message Format Specification.
4.14
4.14.1
Same Day Value
Definition
The same day value payments are those which are expressed to be
executed on the day of transmission of payment message.
4.14.2
Input Time
Same-day value Payment Messages can only be entered during the
exchange period of the Business Cycle that matches the value date
of the transaction.
4.15
4.15.1
Future Value
Definition
Future value payments are those which have a value date after the
day of payment message transmission.(Also refer to Rule 4.3(f)).
PSD
Page 50
Version 06.01.01
Central Bank of Oman
4.15.2
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Settlement
Future value Payment Messages are not final until they are paid on
their value date.
4.15.3
Time of Settlement
Subject to these Operating Rules, RTGS shall attempt to settle a
future value payment at the start of the exchange period on the
future date when the payment is matured.
4.15.4
Queuing on Value Date
Maturing forward Payment Messages may be queued at the Central
System on their value date if the Sending Participant does not have
sufficient liquidity to allow the debit to be applied to its Account.
4.15.5
Notification of Settlement
Both Sending and Receiving participants shall be notified when the
payment is settled.
4.15.6
Cancellation
A future value Payment Message can be cancelled by the Sending
Participant, or by the Central Bank at any time up to its debit to the
Participant’s Settlement Account by RTGS. Forex related
transactions due for settlement on Fridays or holidays and other
transactions due for payment on holidays (scheduled or
unscheduled) must be cancelled by 12.00 noon on the business day
preceding the settlement day.
4.15.7
PSD
Priority Change
Page 51
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
The Sending Participant, can change the priority of a future value
Payment Messages up to the time of their debit by RTGS to its
Settlement Account.
4.16
4.16.1
Free Format Messages (Proprietary Messages)
Definition
RTGS provides the Participants with a free format message transfer
function to and from the Central Bank using the Proprietary
Messages.
4.16.2
Non Value Transactions
The Free Format Messages (Proprietary Messages) are non value
transactions and do not alter the Participants’ Settlement Account.
4.16.3
Control
Free Format Messages (Proprietary Messages) are not subject to
cancellations.
4.16.4
Broadcast or Individual Messages
The Central Bank may use the Free Format Messages (Proprietary
Messages) to be sent to the individual Participant or to all
Participants simultaneously.
5. Rule 5 - Payment Transmission
5.1
PSD
Transmission of Messages
Page 52
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Participants must use SWIFT format messages to send and receive
transfers, transactional and information queries, requests and reports.
The main principles of the RTGS message exchange are developed in
such a way that a complete on-line enquiry system is implemented by use
of the basic set of S.W.I.F.T. messages.
Private network “BankNet” shall be the primary network for transmission
and S.W.I.F.T. network shall be backup network.
All traffic via private networks is encrypted. Any message transferred via
a private network must be signed with at least 2 digital signatures. For
messages sent via S.W.I.F.T. network all security features are provided
by S.W.I.F.T.
Participants shall use the following communication software to access the
Central Bank RTGS:
•
File Adapter; Usage of file/message transfer via private
networks. RTGS includes simple checker workplace that
support this type of transfer;
•
Operator / Controller Workplace; involves double
keyboarding of each payment and proper verification of each
entry (as an option). Interaction with RTGS is based on
online messaging using secure proprietary application
protocol over TCP/IP;
•
Use a S.W.I.F.T. terminal installed on the Participant’s site
for back up;
Whatever is the chosen solution for payment instruction generation and
management, access to account position and to activity statistics is
provided through a web application running at RTGS central site.
Participants access this application from any workstation using a standard
browser and the necessary authentication tools through the private
network.
5.2
PSD
Security – Encryption and Authentication
Page 53
Version 06.01.01
Central Bank of Oman
5.2.1
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Common Principles
The data exchange between RTGS 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, third
and fifth 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
RTGS.
To begin the message exchanging process with RTGS, 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 (RTGS) 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 RTGS. In case message
meets these requirements, user receives a command to connect.
For all messages described above, the length of the secret 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.
PSD
Page 54
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
The Central Bank is authorized to perform certification to the public key
for each Participant. The key should be presented to Central Bank for
certification at six monthly intervals as per the schedule communicated to
the participants. The Participant shall be responsible for securing and the
protection of their private key. 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.
5.3
Payment Message Flow Scheme
5.3.1 Direct Participant to another Direct Participant
DPA
DPB
RTS/X
1: Transfer
KO
KO
2: Validation
error notification
Validation
OK
KO
3: Settlement
delay notification
KO
Settle
or reject
mode?
KO
Possible
to settle
now?
OK
OK
Waiting
for
settlement
OK
OK
4: Debit
confirmation
7: Cancellation
notification
KO
End-of-day
or timeout
cancellation
5: Transfer
OK
6: Credit
confirmation
OK
Direct Participant A sends a payment order to RTGS (MT202 or MT103).
RTGS validates this message and notifies Direct Participant A in case of
rejection of the order due to errors found during validation procedure
(MT296 or MT196).
RTGS tries to settle this order and notifies Direct Participant A in case of
the order is queued or suspended (MT296 or MT196) because of
PSD
Page 55
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
insufficient funds. This message is sent to Direct Participant A only if this
Participant has “Queue notification” flag “on” in the database.
After settlement of the payment order Direct Participant A receives
Confirmation of Debit (MT900). This message is sent to Direct
Participant A only if this Participant has “MT900” flag “on” in the
database.
Direct Participant B receives a copy of payment order (MT202 or
MT103).
Direct Participant B receives Confirmation of Credit (MT910). This
message is sent to Direct Participant B only if this Participant has
“MT910” flag “on” in the database.
If this payment order remains queued or suspended at the end-of-day it is
cancelled by RTGS automatically. Direct Participant A receives
Cancellation notification (MT296 or MT196).
Sequential
SWIFT
Name of message at the diagram
number
of message type
message in the
diagram
1
MT103
or Transfer
MT202
2
MTn96
Validation error notification
3
MTn96
Settlement
delay
notification
(optional)
4
MT900
Debit confirmation (optional)
5
MT103
or Transfer
MT202
6
MT910
Credit confirmation (optional)
7
MTn96
Cancellation confirmation
PSD
Page 56
Version 06.01.01
Central Bank of Oman
5.3.2
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Direct Participant on Behalf of its Branch
Branch A
DPA
Payment order
Preparation
of RTS/X
transfer
DPB
RTS/X
1: Transfer
KO
Validation
KO
2: Validation
error
notification
KO
3: Settlement
delay
notification
OK
KO
Settle
or reject
mode?
KO
Possible
to settle
now?
OK
OK
Waiting
for
settlement
OK
OK
4: Debit
confirmation
End-of-day
or timeout
cancellation
7: Cancellation
notification
KO
5: Transfer
OK
6: Credit
confirmation
OK
Branch of Direct Participant presents payment order to Direct Participant
A. Direct Participant prepares transfer to the RTGS and sends this
payment order from its premises. This payment order contains the
following information:
• field 52a contains identification of branch;
• field 53a contains identification of Direct Participant.
Sequential
SWIFT
Name of message at the diagram
number
of message type
message in the
diagram
1
MT103
or Transfer
MT202
2
MTn96
Validation error notification
3
MTn96
Settlement
delay
notification
(optional)
4
MT900
Debit confirmation (optional)
5
MT103
or Transfer
MT202
6
MT910
Credit confirmation (optional)
PSD
Page 57
Version 06.01.01
Central Bank of Oman
7
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
MTn96
5.3.3
Cancellation notification
Direct Participant to Another Direct Participant for its Branch
DPA
RTS/X
DPB
Branch B
1: Transfer
KO
KO
2: Validation
error notification
Validation
OK
KO
3: Settlement
delay notification
KO
Settle
or reject
mode?
KO
Possible
to settle
now?
OK
OK
Waiting
for
settlement
KO
OK
4: Debit
confirmation
7: Cancellation
notification
OK
End-of-day
or timeout
cancellation
KO
5: Transfer
6: Credit
confirmation
Printing
of RTS/X
transfer
8: Printed
copy
of transfer
OK
OK
The description of the scheme is given below:
Payment order with type MT103 contains the following information:
• field 53a contains identification of Direct Participant A
• field 56a contains identification of Direct Participant B
• field 57a contains identification of branch B.
Payment order with type MT202 contains the following information:
• field 53a contains identification of Direct Participant A
• field 57a contains identification of Direct Participant B
• field 58a contains identification of branch B.
RTGS checks that branch specified in field 58a “belongs” to Direct
Participant specified in filed 57a.
Sequential
PSD
SWIFT
Name of message at the diagram
Page 58
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
number
of message type
message in the
diagram
1
MT103
or Transfer
MT202
2
MTn96
Validation error notification
3
MTn96
Settlement
delay
notification
(optional)
4
MT900
Debit confirmation (optional)
5
MT103
or Transfer
MT202
6
MT910
Credit confirmation (optional)
7
MTn96
Cancellation notification
Rule 6 - Liquidity Management
6.1
Intraday Repo with the Central Bank
The Central Bank may provide an Intraday liquidity facility to the
licensed banks participating in the RTGS to facilitate settlement of their
RTGS transactions on the terms and conditions to be decided by the
Central Bank at its sole discretion. The facility shall be available in form
of intra day repurchase agreement (intraday repo) in Treasury Bills,
Government Development Bonds and the Central Bank CDs. The
Intraday repo shall have to be reversed (buy back) during the prescribed
RTGS Exchange Period by the participant bank. Any Intraday repos that
are not reversed shall get converted into overnight repos, which shall be
charged a penal interest at the rate as may be decided by the Central Bank
at its sole discretion. The participant banks are expected to use the
Intraday repo facility strictly to overcome their temporary liquidity
requirements during the RTGS Exchange Period.
Participants will have to enter into an agreement with the Central Bank
for availing of the Intraday repo facility and as also the other types of
repo transactions that will be processed and settled through RTGS.
PSD
Page 59
Version 06.01.01
Central Bank of Oman
6.1.1
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Rules and Procedures
Other than the specific Rules stated in this document, the Intrday repos
shall be governed by the “Rules and Procedures” established by the
Central Bank TMOD from time to time in this regard.
Banks desirous of availing of the Intraday repo facility can approach the
Treasury, Investment and Monetary Operations Department, hereafter
referred as “TMOD” of the Central Bank through the RTGS between the
beginning of the RTGS business day and up to the end of Exchange
(including Repo) business period. The banks can request for reversal of
the Intraday repo anytime during the working hours of the RTGS for the
day up to the end of the Exchange Interbank (Including Buy-Back)
Business Period. Any outstanding Intraday repo’s at the end of the RTGS
Business Period shall get converted into overnight repos. Such overnight
repos shall attract penal interest, at the rate to be decided by the Central
Bank from time to time.
6.1.2
Repo requests to be initiated by the Participant Bank
The participant banks are expected to monitor their balances in the
RTGS, and issue request for Intraday repo as and when required.
6.1.3
Eligible Securities
The Central Bank at its discretion may decide the securities/collateral that
shall be eligible for the Intraday liquidity facility. For the present,
Government of Oman Treasury Bills and Development Bonds and the
Central Bank Certificates of Deposits shall be eligible instruments for the
Intraday repos. Participant bank are advised to maintain sufficient balance
of the eligible securities for meeting their Intraday liquidity requirement.
PSD
Page 60
Version 06.01.01
Central Bank of Oman
6.1.4
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Treasury Bills and the Central Bank Certificates of Deposit
The request for the Intraday repo in Treasury Bills and the Central bank
Certificate of Deposits are to be sent through the RTGS directly to
TMOD.
6.1.5
Government Development Bonds
The request for Intraday repo, involving the Government Development
Bonds are to be submitted to TMOD, CBO through Muscat Depository
and Securities Registration Company (MDSRC), through the RTGS.
6.1.6
Amount
A minimum amount of R.O. 250,000 and in multiples of R.O. 50,000 for
any single transaction. Banks can avail of any amount up to their holding
of eligible securities. The Central Bank may impose limit of the amount
and also alter the amount/limit at it discretion
6.1.7
Charges
The Central Bank may levy charge for the Intraday repo facility by the
repo amount/timing or per repo transaction. The charges shall be
communicated to the Participants via a circular.
6.1.8
Valuation
The securities accepted for repo shall be valued at the face value and no
margin shall be applied. The Central Bank may at its discretion change
the valuation method and decide to impose margins.
6.1.9
PSD
Usage of Intrday Repo Funds
Page 61
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
The RTGS shall use the funds, availed of by the Participant bank through
Intraday repo, for settlement of transactions in the defined priority order.
The Intraday repo funds shall not be used for settlement of any specific
payment ignoring the defined priority order.
6.1.10
Repo Threshold
The Central Bank may, at its discretion, prescribe a ‘threshold for
reversal of Intraday repo’, i.e. the minimum balance in the participant
bank’s RTGS settlement account to be left after reversal of the Intraday
repo. The ‘threshold for reversal on Intraday repo’ shall be set at ‘zero
balance amount’. The Central bank reserves the right to alter the
minimum balance required at anytime.
6.2
6.2.1
Buy-Back of Intraday Repo with the Central Bank
Rules and Procedure
The Participants that avail the Intraday repo facility shall be expected to
reverse it on that day itself. They can do so during the course of the day
prior to the automated Buy Back business period. In case of failure by
any Participant to send the request for the reversal, the system shall
generate a report of the outstanding repos that need to be bought back. If
sufficient balance to reverse the Intraday repo is not available in the
settlement account of the Participant, the Intraday repo shall be converted
into overnight repo, which shall attract a penal interest rate of the Central
Bank repo rate prevailing on that day plus 200 basis points.
The Participant will have to reverse the converted overnight repo
immediately at the start of RTGS on the next business day. Failure to
reverse the repo may lead to denial of Intrday repo facility to the
Participant and/or imposition of any other penalty as may be decided by
the Central Bank.
Participants are expected to avail of the Intraday liquidity facility for
intra-day needs for funds for RTGS purpose. The Central Bank shall be
PSD
Page 62
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
monitoring the use of this facility by banks and, if in view of the Central
Bank any Participant is found to be indiscriminately using the facility, the
Central Bank may initially caution the Participant. Repeated acts of
indiscrimate use of Intrday repo facility and/or frequent failures to reverse
the Intrday Repo shall attract severe penalties, including denial of the
Intraday liquidity facility or suspension from the RTGS of the Participant
or any other penalty, as may be decided by the Central Bank.
6.2.2
Authority of the Central Bank
The Central is authorized to debit a participant account upon receipt of
the Buyback request from the participant. The debit amount shall be in
accordance with the agreed Purchase and repurchase prices in the details
of the Repo transaction referred to by the Buyback request.
6.3
Other Types of Repo (Inception & Reversal)
Besides Intraday Repo transaction, the RTGS support the settlement
transactions for the following types of Repo activities:
1. Overnight Repo (Inception and Reversal) with the Central Bank for
duration ranging from one to 28 days, involving the T-Bills, GDBs
and the Central Bank CDs.
2. Interbank Repo (Inception and Reversal) between two participants
of at least one day durtion, involving T-Bills, GDBs and the
Central Bank CDs.
6.3.1
Rules and Procedures
The rules and procedures for the above Repo activities shall follow the
current Rules document for the same items as defined by TMOD of the
Central Bank, except for the part involving settlement of funds, which
will follow the processing steps in section 6.4.
The processing steps for settlement of funds for Overnight Repo (item 1
above) must follow the steps in sections 6.4.1, 6.4.2, 6.4.3 and 6.4.4.
PSD
Page 63
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
The processing steps for settlement of funds for Interbank Repo (item 2
above) must follow the steps in section 6.4.5, 6.4.6, 6.4.7 and 6.4.8.
6.3.2
Authority of the Central Bank
For Interbank Repo (inception and reversal), the Central Bank is
authorized to debit a buyer participant account and credit a seller
participant account upon receipt of request from both the buyer
participant and seller participant. The debit and credit amount shall be in
accordance with the agreed Purchase and repurchase prices in the details
of the Interbank REPO (inception and reversal) requests from the
participants.
6.4
Settlement Process
transactions
6.4.1
CDs
for
REPO
Repo with the Central Bank using T-bill and the
&
Buyback
Central Bank
The following process flow for settlement of Repo transactions shall
apply to :
Intraday Repo with the Central Bank for T-Bill and CDs
Overnight Repo (inception) with the Central Bank for T-Bill and CDs
PSD
Page 64
Version 06.01.01
Central Bank of Oman
Central
Central
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
CBO TMOD
RTS/X
Bank
Part
PartAA Bank
1: Request for REPO
KO
2: Collateral rejection
OK
3: Collateral information ACK
KOValidation
OK
Blocking of
Securities
4: REPO transaction
OK Validation
OK
Possible
to settle
now?
KO
OK
OK
OK
8: REPO
transaction
KO
KO
6: Settlement
delay notification
OK
5: Validation
error notification
7: Settlement
delay notification
Waiting
for
settlement
9: Debit confirmation
OK
12: Settlement
notification
10: REPO
transaction
OK
11: Credit confirmation
13: Cancellation
notification
End-of-day
Cancellation
14: Cancellation
notification
OK
Business scheme description
1) The Participant issues the request for REPO operation to RTGS.
RTGS checks the syntax of this message and routes this message to
TMOD authorized for providing of REPO against securities this
Participant intends to use for REPO (Step 1),
2) TMOD validates the Participant’s request and notifies this Participant
about the result of the validation. Again, to do this, the Central Bank
TMOD sends message to RTGS, and RTGS routes the message to the
related Participant (Step 2 or Step 3),
3) The Central Bank TMOD blocks the securities that should be involved
with the REPO operation and issues the corresponding payment order
to RTGS (Step 4). As a rule, the REPO transactions have a higher
priority levels than ordinary payment orders,
4) RTGS accepts this payment order, validates and tries to settle it. Error
notification is issued in case unsuccessful validation (Step 5),
5) The Participant and the Central Bank TMOD are notified about the
settlement of the REPO transaction (Steps 6-12),
6) At the end-of-day RTGS automatically cancel all REPO transactions
remain unsettled with appropriate notifications sent to parties involved
(it may happen in exceptional situations only, Steps 13-14).
PSD
Page 65
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Table of messages in the scheme
Sequential number of
SWIFT message
message at the diagrams
type
1
MT598
2
MT598
3
MT598
4
5
6, 7
8
9
10
11
12
13, 14
MT202
MT296/ERROR
MT296/WAIT
MT202
MT900
MT202
MT910
MT296/SETL
MT296/CANC
Name of message at the
diagram
Collateral information
Collateral rejection notice
Collateral information ACK
notice
REPO transaction
Validation Error notification
Settlement Delay notification
REPO transaction
Debit confirmation
REPO transaction
Credit confirmation
Settlement notification
Cancellation notification
Repo Request Message Format
Participants must send a MT598 message with the following fields
format to the Central Bank to request for Repo (as in Step 1 of above
business scheme):
Field description
Sender
Tag
Format
20
16x
12
77E
59a
3!n
503
CRLF
4!a2!a2!c[3!c] Always this value:
CBOMOMRUTMD
4!a2!a2!c[3!c] Always this value:
Participant BIC
34x
10/112/1,2
Receiver
Transaction Reference
Number
Sub-message Type
54a
Allotment number
PSD
21C
Page 66
Example
Always this value:
Participant BIC
Always this value:
CBOMOMRURTG
P-REPO-1
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Field description
Face value (in OMR)
Purchase Price (in OMR)
Pricing rate (% p.a)
No. of days
Interest amount for 365
days
Repo date
Tag
33B
32B
36
38A
36A
Format
3!a15d
3a!15d
12d
3n
12d
Example
OMR2000000,
OMR2000000,
0,50000
0
0,
30
Repurchase price
Remark
34B
70
6!n
050625
(YYMMDD)
3!a15d
OMR2000000,
34x
1.5m,0.5m
Note:
No. of days indicate if it is intraday (=0) or overnight (>0)
6.4.2
Buyback of Repo using T-bill and CDs with the Central Bank
The following process flow for settlement of Buyback transactions shall apply to:
Buyback of Intraday Repo with CBO for T-Bill and CDs
Overnight Repo (reversal) with CBO for T-Bill and CDs
Request for Buy-Back transaction initiated by Participant
PSD
Page 67
Version 06.01.01
Central Bank of Oman
RTS/X
PartA
Central
Bank
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
CBO
TMOD
1: Request for buy-back
KO
OK
2: Buy-back
rejection
Validation
OK
3: Buy-back notification ACK
OK
4: Buy-back transaction
OK
KO
Validation
Possible
to settle
now?
8: Buy-back transaction
OK
9: Debit confirmation
OK
10: Buy-back transaction
OK
11: Credit confirmation
Status
KO
KO
7: Settlement
delay notification
6: Settlement
delay notification
OK
KO
5: Validation Error
Notification
Waiting
for
settlement
OK
13:Cancellation
notification
OK
End-of-day
cancellation
12: Settlement
Notification
14: Cancellation
notification
Buy-back settlement:
Securities leg
OK
Business scheme description
Any Participant may issue a request for a Buy-back operation to RTGS.
This request is validated by RTGS and routed to the Central Bank TMOD
for further validation and processing (Step 1),
In case of a validation error, the Participants receive “technical rejection”
answer with an error description (Steps 2) or Buy-back acknowledgement
(Step 3),
In case of positive acknowledgement Monetary Operations Domain
issues a corresponding Buy-back transaction to RTGS (Step 4). RTGS
accepts this transaction, validates it and tries to settle it according to the
normal queuing technique. As a rule, Buy-back transactions have a higher
priority level than ordinary payment orders (Steps 6-12),
Buy-Back operations remain unsettled at the end-of-day are cancelled
automatically with appropriate notifications sent to parties involved
(Steps 13-14).
PSD
Page 68
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Table of messages in the scheme
Sequential number of
SWIFT message type
message in the
diagram
1
MT598
2
MT598
3
MT598
4
MT202
5
MT296/ERROR
6, 7
MT296/WAIT
8
MT202
9
MT900
10
MT202
11
MT910
12
MT296
13,14
MT296/CANC
Name of message in the
diagram
Request for Buy-Back
Buy-back rejection
Buy-back notification ACK
Buy-back transaction
Validation Error notification
Settlement Delay notification
Buy-back transaction
Debit confirmation
Buy-back transaction
Credit Confirmation
Settlement notification
Cancellation notification
Buyback Request Message Format
Participants must send a MT598 message with the following fields
format to the Central Bank to request for Buyback (as in Step 1 of above
business scheme)
Field description
Sender
Tag
Format
20
16x
12
77E
59a
3!n
504
CRLF
4!a2!a2!c[3!c Always this value:
CBOMOMRUTMD
]
4!a2!a2!c[3!c Always this value:
Participant BIC
]
16x
P-REPO-1
Receiver
Transaction Reference
Number
Sub-message Type
54a
Repo reference
PSD
20
Page 69
Examples
Always this value:
Participant BIC
Always this value:
CBOMOMRURTG
P-BB-1
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Field description
Allotment number
Face value (in OMR)
Purchase Price (in OMR)
Pricing rate (% p.a)
Tag
21C
33B
32B
36
Format
34x
3!a15d
3!a15d
12d
Examples
10/112/1,2
OMR2000000,
OMR2000000,
0,50000
No. of days
38A
3n
0
Interest amount for 365
days
Repo date
36A
12d
0,
30
Repurchase price
Remark
34B
70
6!n
050625
(YYMMDD)
3!a15d
OMR2000000,
34x
1.5m,0.5m
6.4.3
Repo with CBO using GDB via MDSRC
The following process flow for settlement of Repo transactions shall apply to
Intraday Repo with the Central Bank for GDB
Overnight Repo (inception) with the Central Bank for GDB
REPO transaction initiated by Participant
PSD
Page 70
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
CBO
CBO
TMOD
TMOD
MSM/
MDSRC
RTS/X
1: Request for REPO
2: Collateral rejection
KO
3: Collateral information ACK
OK
OK
6: Authorization
request
OK Validation
4: REPO transaction
KO
7: Authorization
reply
5: Validation
error notification
OK Is transaction
authorized?
Central
Central
Bank
Bank
OK
OK
OK
OK
KO Validation
OK
Possible
to settle
now?
8: Authorization
rejection
KO
KO
KO
10: Settlement
delay notification
9: Settlement
delay notification
11: REPO
transaction
KO
Block
Securities
Part.
Part.Bi
Bi
Waiting
for
settlement
12: Debit confirmation
OK
13: REPO
transaction
15: Settlement
notification
14: Credit confirmation
End-of-day
cancellation
16: Cancellation
notification
17: Cancellation
notification
Business scheme description
The Participant issues the request for REPO operation to RTGS. RTGS
checks the syntax of this message and routes this message to the MDSRC
(Step 1),
The MDSRC validates the Participant’s request and notifies this
Participant about the result of the validation. Again, to do this, the
MDSRC sends message to RTGS, and RTGS routes the message to the
related Participant (Step 2 or Step 3),
The MDSRC blocks the securities that should be involved with the REPO
operation and issues the corresponding REPO transaction to RTGS (Step
4). As a rule, the REPO transactions have a higher priority levels than
ordinary payment orders,
RTGS accepts this REPO transaction and validates it. Error notification is
issued in case unsuccessful validation (Step 5),
Authorization request is sent to the Central Bank TMOD (Step 6). The
authorization reply (Step 7) is returned as the answer. If the transaction is
not authorized, the authorization rejection is sent to MDSRC and related
REPO transaction is cancelled (Step 8),
PSD
Page 71
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
If the authorization is made RTGS tries to settle REPO transaction. The
Participant, Central Bank and the MDSRC application are notified about
the settlement of the REPO transaction (Steps 9-15),
At the end-of-day RTGS automatically cancel all REPO transactions
remain unsettled to the next day processing (it may happen in exceptional
situations only, Steps 16-17).
Table of messages in the scheme
Sequential number of SWIFT message
Name of message at the diagram
message at the
type
diagrams
1
MT598
Request for REPO
2
MT598
Collateral rejection notice
3
MT598
Collateral information ACK
notice
4
MT202
REPO transaction
5
MT296/ERROR
Validation Error notification
6
MT296/AUTH
Authorization request
7
MT295/AUTH
Authorization reply
8
MT296/ERROR
Authorization rejection
9, 10
MT296/WAIT
Settlement Delay notification
11
MT202
REPO transaction
12
MT900
Debit confirmation
13
MT202
REPO transaction
14
MT910
Credit confirmation
15
MT296/SETL
Settlement notification
16, 17
MT296/CANC
Cancellation notification
Repo Request Message Format
Participants must send a MT598 message with the following fields
format to MDSRC to request for Repo using GDB (as in Step 1 of above
business scheme):
Field description
Sender
Tag
Format
Receiver
PSD
Page 72
Example
Always this value:
Participant BIC
Always this value:
CBOMOMRURTG
Version 06.01.01
Central Bank of Oman
Field description
Transaction Reference
Number
Sub-message Type
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Tag
20
Format
16x
12
77E
59a
3!n
503
CRLF
4!a2!a2!c[3!c] Always this value:
MDSROMR1XXX
4!a2!a2!c[3!c] Always this value:
Participant BIC
34x
10/112/1,2
3!a15d
OMR2000000,
3a!15d
OMR2000000,
12d
0,50000
3n
0
12d
0,
54a
Allotment number
Face value (in OMR)
Purchase Price (in OMR)
Pricing rate (% p.a)
No. of days
Interest amount for 365
days
Repo date
21C
33B
32B
36
38A
36A
Repurchase price
Remark
34B
70
30
Example
P-REPO-1
6!n
050625
(YYMMDD)
3!a15d
OMR2000000,
34x
1.5m,0.5m
Note:
1. No. of days indicate if it is intraday (=0) or overnight (>0)
6.4.4
Buyback of Repo using GDB with the Central Bank via MDSRC
The following process flow for settlement of Buyback transactions shall
apply to:
Buyback of Intraday Repo with the Central Bank for GDB
Overnight Repo (reversal) with the Central Bank for GDB
Buy-back operations
Request for Buy-Back transaction initiated by Participant
PSD
Page 73
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
RTS/X
PartA
MDSRC
1: Request for buy-back
Cbo
tmod
KO
KO
2: Buy-back
rejection
Validation
OK
OK
3: Buy-back notification ACK
4: Buy-back transaction
7: Authorization
reply
OK
Validation
KO
5: Validation Error
Notification
8: Authorization
rejection
Validation
KO
OK Possible
Central
Bank
to settle
now?
KO
OK
11: Buy-back transaction
OK
12: Debit confirmation
OK
13: Buy-back transaction
OK
14: Credit confirmation
KO
KO
9: Settlement
delay notification
10: Settlement
delay notification
Waiting
for
settlement
OK
16: Cancellation
notification
End-of-day
cancellation
15: Settlement
Notification
17: Cancellation
notification
OK
Buy-back settlement:
Securities leg
OK
6: Authorization
request
Business scheme description
Any Participant may issue a request for a Buy-back operation to RTGS
(Step 1). This request is validated by RTGS and routed to MDSRC for
further validation and processing. RTGS optionally may perform reconciliation with REPO operation and rejects a Buy-Back request if
corresponding REPO operation was not found in RTGS database (“REPO
re-conciliation” process),
In case of a validation error, the Participants receive “technical rejection”
answer with an error description (Steps 2),
Otherwise, MDSRC acknowledges Buy-Back request (Step 3) and issues
a corresponding Buy-back instruction to RTGS (Step 4),
RTGS accepts this payment order and validates it. Error notification is
issued in case unsuccessful validation (Step 5),
Authorization request is sent to the Central Bank TMOD (Step 6). The
authorization reply (Step 7) is returned as the answer. If the transaction is
not authorized, the authorization rejection is sent to MDSRC (Step 8),
If the authorization is made RTGS tries to settle Buy-Back transaction.
As a rule, the Buy-Back transactions have a higher priority levels than
ordinary payment orders (Steps 9-14),
Buy-Back operations remain unsettled at the end-of-day are moving to
the next day with appropriate notifications sent to parties involved (Steps
15-16),
PSD
Page 74
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
It is the responsibility of MDSRC to perform Overnights (or perform
other operations accordingly to pre-defined arrangements) if some of
REPO operations are not returned by related Buy-backs due to lack of
funds on Participant’s Settlement account or any other reasons.
Table of messages in the scheme
Sequential number
SWIFT
of message in the
message type
diagram
1
MT598
2
MT598
3
MT598
4
MT202
5
MT296/ERROR
6
MT296/AUTH
7
MT295/AUTH
8
MT296/ERROR
9, 10
MT296/WAIT
11
MT202
12
MT900
13
MT202
14
MT910
15
MT296
16,17
MT296/CANC
Name of message in the diagram
Request for Buy-Back
Buy-back rejection
Buy-back notification ACK
Buy-back transaction
Validation Error notification
Authorization request
Authorization reply
Authorization rejection
Settlement Delay notification
Buy-back transaction
Debit confirmation
Buy-back transaction
Credit Confirmation
Settlement notification
Cancellation notification
Buyback Request Message Format
Participants must send a MT598 message with the following fields format to
MSM/MDSRC to request for Buyback using GDB (as in Step 1 of above business
scheme):
Field description
PSD
Tag
Format
Page 75
Examples
Version 06.01.01
Central Bank of Oman
Field description
Sender
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Tag
Format
20
16x
12
77E
59a
Receiver
Transaction Reference
Number
Sub-message Type
Examples
Always this value:
Participant BIC
Always this value:
CBOMOMRURTG
P-BB-1
Repo reference
Allotment number
Face value (in OMR)
Purchase Price (in OMR)
Pricing rate (% p.a)
20
21C
33B
32B
36
3!n
504
CRLF
4!a2!a2!c[3!c] Always this value:
MDSROMR1XXX
4!a2!a2!c[3!c] Always this value:
Participant BIC
16x
P-REPO-1
34x
10/112/1,2
3!a15d
OMR2000000,
3!a15d
OMR2000000,
12d
0,50000
No. of days
38A
3n
0
Interest amount for 365
days
Repo date
36A
12d
0,
30
Repurchase price
Remark
34B
70
6!n
050625
(YYMMDD)
3!a15d
OMR2000000,
34x
1.5m,0.5m
54a
6.4.5
Interbank Repo using T-bill and CDs
The following process flow for settlement of Buyback transactions shall
apply to Interbank Repo for T-Bill and CDs.
When the Seller Participant and Buyer Participant has agreed to a Repurchase
Transaction in either Treasury Bills or the Central Bank Certificates of Deposit, both
PSD
Page 76
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Participants must send the request message directly to the Central Bank TMOD for
validation and processing.
L iq u idity
d ep a rtm e nt
P art B
RTPS
1: R eq uest for
R E P O «S ell »
M atc hing
2: Req ue st for
RE P O «B uy »
OK
3: C ollateral r eje ctio n
KO
5: R E PO tra nsa ctio n
OK
V alid atio n
P o ssible
to settle
no w ?
OK
OK
10: C redit
co nfir m atio n
11: R E PO tra nsa ctio n
KO
OK
6: V alid atio n
E rror notific atio n
KO
KO
8: S ettle me nt
dela y notific atio n
W aiting
for
settle me nt
KO
E nd -o f-d a y
or tim eo ut
ca ncellatio n
OK
13: Settle m e nt
notificatio n
12: D e bit
co nfir m atio n
15: C a nc ellatio n
notificatio n
14: C a nc ellatio n
notificatio n
Delivery
Securities
7: S ettle me nt
dela y notific atio n
9: R E PO tra nsa ctio n
OK
V alid atio n
Unblock
securities
OK
OK
KO
4: C ollateral infor ma tio n A C K
OK
KO
KO
Block
Securities
P art A
Business scheme description
A Participant sends an Interbank Repo request “to buy” securities to the
Central Bank TMOD; another Participant sends a Interbank Repo request
“to sell” securities to the Central Bank TMOD. These requests may be
sent to the Central Bank TMOD directly through RTGS. (Steps 1-2).
The Central Bank TMOD will match the Repo request for buy and Repo
request for sell.
The Central Bank TMOD validates the Participants’ request and notifies
this Participant about the result of the validation. Again, to do this, the
Central Bank TMOD sends either an acknowledgement message or a
reject message to RTGS, and RTGS routes the message to the related
Participants (Step 3 or Step 4),
If the REPO requests are valid and there are sufficient securities with the
seller Participant, the Central Bank TMOD will block the securities that
should be involved with the REPO operation and issues the
corresponding payment order to RTGS (Step 5). As a rule, the REPO
transactions have a higher priority levels than ordinary payment orders,
RTGS accepts this payment order, validates and tries to settle it. Error
notification is issued in case unsuccessful validation (Step 6),
The Participant and the Central Bank TMOD are notified about the
settlement of the REPO transaction (Steps 7-13),
PSD
Page 77
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
At the end-of-day RTGS automatically cancel all REPO transactions
remain unsettled with appropriate notifications sent to parties involved. (it
may happen in exceptional situations when the Buyer Participant does not
have sufficient funds, Steps 14-15).
Table of messages in the scheme
Sequential number SWIFT
Name of message in the
of message in the
message type
diagram
diagram
1
MT598
Repo Request (“Sell”)
2
MT598
Repo Request (“Buy”)
3
MT598
Collateral rejection notice
4
MT598
Collateral information ACK
notice
5
MT202
REPO transaction
6
MT296/ERROR Validation Error
notification
7, 8
MT296/WAIT
Settlement Delay
notification
9
MT202
REPO transaction
10
MT910
Credit confirmation
11
MT202
REPO transaction
12
MT900
Debit confirmation
13
MT296/SETL
Settlement notification
14, 15
MT296/CANC Cancellation notification
Repo Request Message Format
Participants must send a MT598 message with the following fields format
to the Central Bank to request for Repo using T-bill & CD (as in Step 1 of
above business scheme):
Field description
Tag
Format
Example
Sender
Receiver
Transaction Reference
Number
PSD
20
16x
Page 78
Always this value:
Participant BIC
Always this value:
CBOMOMRURTG
GRP 1 INT REPO
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Field description
Tag
Format
Example
Sub-message Type
12
3!n
503
77E
CRLF
59a
Allotment number
21C
4!a2!a2!c[3!c] Always this value:
CBOMOMRUTMD
4!a2!a2!c[3!c] Always this value:
Participant BIC
34x[1]
10/112/9,23
Counterpart
52D
34x
Face value (in OMR)
33B
3!a15d
Always this value:
Counterpart BIC
OMR1500000,
Purchase Price (in OMR)
32B
3a!15d
OMR1500000,
Pricing rate (% p.a)
36
12d
0,50000
No. of days
38A
3n
1
Interest amount for 365
days
Repo date
36A
12d
616.438
30
Repurchase price
34B
6!n
050625
(YYMMDD)
3!a15d
OMR1500000,
Remark
70
34x
54a
0.5m,1m
Note:
Both buyer and seller send this message
Transaction Reference of messages from buyer and seller must be the same.
6.4.6
Interbank Repo using GDB via MDSRC
The following process flow for settlement of Buyback transactions shall
apply to Interbank Repo for GDB
When the Seller Participant and Buyer Participant has agreed to a Repurchase
Transaction in Government Development Bond, both Participants must send the
request message to MDSRC for validation and forwarding to the Central Bank.
PSD
Page 79
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Business scheme description
Liquidity
Liquidity
Department
Department
Part.
Part.
BB
KO
M SM /
M DSRC
RTS/X
1: Request for
REPO(Buy)
2: Request for
REPO(Sell)
3: Collateral rejection
4: Collateral information ACK
OK
OK
7: Authorization
request
OK
Validation
5: REPO transaction
KO
8: Authorization
reply
6: Validation
error notification
OK Is transaction
authorized?
Central
Central
Bank
Bank
OK
OK
OK
Possible
to settle
now?
10: Settlement
delay notification
12: REPO
transaction
OK
KO
9: Authorization
rejection
KO
KO
KO
11: Settlement
delay notification
Waiting
for
settlement
13: Debit confirmation
OK
OK
KO Validation
Block
Securities
Part.
Part.
AA
14: REPO
transaction
16: Settlement
notification
Transfer
Securities
15 Credit confirmation
18: Cancellation
notification
End-of-day
cancellation
17: Cancellation
notification
A Participant A sends an Interbank Repo request “to buy” securities to
MDSRC; another Participant B sends a Interbank Repo request “to sell”
securities to MDSRC. These requests may be sent to through RTGS
which will route this Message to MDSRC (Steps 1-2).
PSD
Page 80
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
MDSRC will match the Repo request for buy and Repo request for sell.
MDSRC will validate the Participant’s request and notifies this
Participant about the result of the validation. Again, to do this, MDSRC
sends either an acknowledgement message or a reject message to RTGS,
and RTGS routes the message to the related Participants (Step 3 or Step
4),
If the REPO request is acknowledged, MDSRC will block the related
Securities for transfer from seller to buyer. At the same time, MDSRC
will send a copy of the acknowledgement message and a REPO
transaction payment order to the Central Bank TMOD for authorization
of transfer of funds. (Steps 4 and Step 5).
RTGS will route the REPO payment order to the Central Bank TMOD for
authorization of payment transfer. In accordance with the authorization
result, the Central Bank TMOD will send either an authorization message
or a reject message to RTGS, and RTGS routes the message to MDSRC.
If the REPO order is not authorized by the Central Bank TMOD,
MDSRC will unblock and securities and send the reject message to the
Participants A & B. (as in Step 3).
If the REPO payment order is authorized by the Central Bank TMOD,
RTGS accepts this payment order, validates and tries to settle it. Error
notification is issued in case unsuccessful validation (Step 9),
The Participants, MDSRC and the Central Bank are notified about the
settlement of the REPO transaction (Steps 10-16),
If the settlement is completed successfully, MDSRC will transfer
ownerships of the Government Development Bond from Seller
Participant to Buyer Participant.
At the end-of-day RTGS automatically cancel all REPO transactions
remain unsettled with appropriate notifications sent to parties involved. (it
may happen in exceptional situations when the Buyer Participant does not
have sufficient funds, Steps 17-18).
Table of messages in the scheme
Sequential number SWIFT
of message in the
message type
diagram
1
MT598
2
MT598
3
MT598
PSD
Page 81
Name of message in the
diagram
Repo Request (“Sell”)
Repo Request (“Buy”)
Collateral rejection notice
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Sequential number SWIFT
of message in the
message type
diagram
4
MT598
5
6
7
8
9
10, 11
12,14
13
15
16
17, 18
Name of message in the
diagram
Collateral information ACK
notice
MT202
REPO transaction
MT296/ERROR Validation Error
notification
MT296/AUTH Authorization request
MT295/AUTH Authorization reply
MT296/ERROR Authorization rejection
MT296/WAIT
Settlement Delay
notification
MT202
REPO transaction
MT900
Debit confirmation
MT910
Credit confirmation
MT296/SETL
Settlement notification
MT296/CANC Cancellation notification
Repo Request Message Format
Participants must send a MT598 message with the following fields
format to MDSRC to request for Repo using GDB (as in Step 1 of above
business scheme):
Field description
Tag
Format
Example
Sender
Always this value:
Participant BIC
Receiver
Always this value:
CBOMOMRURTG
Transaction Reference
20
16x
GRP 1 INT REPO
Number
Sub-message Type
12
3!n
503
77E
CRLF
59a
4!a2!a2!c[3!c] Always this value:
MDSROMR1XXX
54a
4!a2!a2!c[3!c] Always this value:
Participant BIC
PSD
Page 82
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Field description
Allotment number
Counterpart
Tag
21C
52D
Format
Face value (in OMR)
Purchase Price (in OMR)
Pricing rate (% p.a)
No. of days
Interest amount for 365
days
Repo date
33B
32B
36
38A
36A
3!a15d
3a!15d
12d
3n
12d
30
6!n
050625
(YYMMDD)
3!a15d
OMR1500000,
34x
0.5m,1m
34x[1]
34x
Example
10/112/9,23
Always this value:
Counterpart BIC
OMR1500000,
OMR1500000,
0,50000
1
616.438
Repurchase price
34B
Remark
70
Note:
Both buyer and seller send this message
Transaction Reference of messages from buyer and seller must be the
same.
6.4.7
Reversal of Interbank Repo using T-bill and CDs
The following process flow for settlement of Buyback transactions shall
apply to reversal of Interbank Repo for T-Bill and CDs at maturity.:
When an Interbank Repurchase Transaction in either Treasury Bills or Certificate of
Deposit matures, both Participants must send the buyback request message directly to
the Central Bank TMOD for validation and processing.
PSD
Page 83
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Liquidity
department
PartB
RTPS
1: Request for
Buyback «Sell »
Matching
2: Request for
Buyback «Buy»
OK
3: Collateral rejection
KO
5: Buyback transaction
OK
Validation
OK
10: Credit
confirmation
OK
11: Buyback transaction
OK
12: Debit
confirmation
Possible
to settle
now?
KO
OK
6: Validation
Error notification
KO
KO
8: Settlement
delay notification
Waiting
for
settlement
OK
End-of-day
or timeout
cancellation
13: Settlement
notification
15: Cancellation
notification
14: Cancellation
notification
KO
Delivery
Securities
7: Settlement
delay notification
9: Buyback transaction
OK
Validation
Unblock
securities
OK
KO
KO
4: Collateral information ACK
OK
Business scheme description
A Participant sends an Interbank Repo Buyback request “to buy”
securities to TMOD; another Participant sends a Interbank Repo Buyback
request “to sell” securities to TMOD. Both Buyback requests must
contain the reference number of the relevant Interbank REPO transaction.
These requests may be sent to TMOD directly through RTGS which will
route this Message to TMOD (Steps 1-2).
TMOD will match the Buyback request for buy and Buyback request for
sell.
TMOD validates the Participant’s request and notifies this Participant
about the result of the validation. Again, to do this, TMOD sends either
an acknowledgement message or a reject message to RTGS, and RTGS
routes the message to the related Participants (Step 3 or Step 4),
If the Buyback requests are valid and there are sufficient securities with
the seller Participant, TMOD will block the securities that should be
PSD
Page 84
KO
Block
Securities
PartA
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
involved with the Buyback operation and issues the corresponding
payment order to RTGS (Step 5). As a rule, the Buyback transactions
have a higher priority levels than ordinary payment orders,
RTGS accepts this payment order, validates and tries to settle it. Error
notification is issued in case unsuccessful validation (Step 6),
If settled, the Central Bank shall transfer securities from Buyer to Seller
The Participant and TMOD are notified about the settlement of the
Buyback transaction (Steps 7-13),
At the end-of-day RTGS automatically cancel all Buyback transactions
remain unsettled with appropriate notifications sent to parties involved. (it
may happen in exceptional situations when the Buyer Participant does not
have sufficient funds, Steps 14-15).
Table of messages in the scheme
Sequential number SWIFT message Name of message in the
of message in the
type
diagram
diagram
1
MT598
Buyback Request (“Sell”)
2
MT598
Buyback Request (“Buy”)
3
MT598
Collateral rejection notice
4
MT598
Collateral information ACK
notice
5
MT202
Buyback transaction
6
MT296/ERROR Validation Error notification
7, 8
MT296/WAIT
Settlement Delay notification
9
MT202
Buyback transaction
10
MT910
Credit confirmation
11
MT202
Buyback transaction
12
MT900
Debit confirmation
13
MT296/SETL
Settlement notification
14, 15
MT296/CANC
Cancellation notification
Buyback Request Message Format
Participants must send a MT598 message with the following fields format
to the Central Bank to request for Buyback (as in Step 1 of above
business scheme):
PSD
Page 85
Version 06.01.01
Central Bank of Oman
Field description
Sender
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Tag
Format
20
16x
12
77E
59a
Receiver
Transaction Reference
Number
Sub-message Type
Examples
Always this value:
Participant BIC
Always this value:
CBOMOMRURTG
P-BB-1
Repo reference
Allotment number
Counterpart
Face value (in OMR)
Purchase Price (in OMR)
Pricing rate (% p.a)
20
21C
52D
33B
32B
36
3!n
504
CRLF
4!a2!a2!c[3!c Always this value:
]
CBOMOMRUTMD
4!a2!a2!c[3!c Always this value:
]
Participant BIC
16x
P-REPO-1
34x
10/112/1,2
34x
Counterpart BIC
3!a15d
OMR2000000,
3!a15d
OMR2000000,
12d
0,50000
No. of days
38A
3n
0
Interest amount for 365
days
Repo date
36A
12d
0,
30
Repurchase price
Remark
34B
70
6!n
050625
(YYMMDD)
3!a15d
OMR2000000,
34x
1.5m,0.5m
54a
6.4.8
Reversal of Interbank Repo using GDB via MDSRC
The following process flow for settlement of Buyback transactions shall apply to
interbank Repo for GDB via MDSRC:
PSD
Page 86
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
When an Interbank Repurchase Transaction in GDB matures, both Participants must
send the buyback request message directly to MDSRC for validation and processing.
Business scheme description
Liquidity
Liquidity
Department
Department
Part.
Part.
BB
KO
MSM/
MDSRC
RTS/X
1: Request for
Buyback (Buy)
2: Request for
Buyback (Sell)
4: Collateral information ACK
OK
OK
7: Authorization
request
OK
Validation
5: Buyback transaction
KO
8: Authorization
reply
6: Validation
error notification
OK Is transaction
authorized?
Central
Central
Bank
Bank
OK
OK
OK
Possible
to settle
now?
OK
9: Authorization
rejection
KO
11: Settlement
delay notification
10: Settlement
delay notification
12: Buyback
transaction
KO
KO
KO
Waiting
for
settlement
13: Debit confirmation
OK
OK
KO Validation
3: Collateral rejection
Block
Securities
Part.
Part.
AA
14: Buyback
transaction
16: Settlement
notification
Transfer
Securities
15 Credit confirmation
18: Cancellation
notification
End-of-day
cancellation
17: Cancellation
notification
A Participant A sends an Interbank Repo Buyback request “to buy”
securities; another Participant B sends a Interbank Repo Buyback request
“to sell” securities to MDSRC. These requests may be sent to MDSRC
through RTGS, which will route this Message to MDSRC (Steps 1-2).
MDSRC will match the Buyback request for buy and Buyback request for
sell.
MDSRC will validate the Participant’s request and notifies this
Participant about the result of the validation. Again, to do this, MDSRC
sends either an acknowledgement message or a reject message to RTGS,
and RTGS routes the message to the related Participants (Step 3 or Step
4),
If the Buyback request is acknowledged, MSM/MDSRC will block the
related Securities for transfer from seller to buyer. At the same time,
MDSRC will send a copy of the acknowledgement message and a
Buyback transaction payment order to the Central Bank TMOD for
authorization of transfer of funds. (Steps 4 and Step 5).
PSD
Page 87
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
RTGS will route the Buyback payment order to the Central Bank TMOD
for authorization of payment transfer. In accordance with the
authorization result, the Central Bank TMOD will send either an
authorization message or a reject message to RTGS, and RTGS routes the
message to MDSRC.
If the Buyback order is not authorized by the Central Bank TMOD,
MDSRC will unblock and securities and send the reject message to the
Participants A & B. (as in Step 3).
If the Buyback payment order is authorized by the Central Bank TMOD,
RTGS accepts this payment order, validates and tries to settle it. Error
notification is issued in case unsuccessful validation (Step 9),
The Participants, MDSRC and the Central Bank are notified about the
settlement of the Buyback transaction (Steps 10-16),
If the settlement is completed successfully, MDSRC will transfer
ownerships of the Government Development Bond from Seller
Participant to Buyer Participant.
At the end-of-day RTGS automatically cancel all Buyback transactions
remain unsettled with appropriate notifications sent to parties involved. (it
may happen in exceptional situations when the Buyer Participant does not
have sufficient funds, Steps 17-18).
Table of messages in the scheme
Sequential number SWIFT
of message in the
message type
diagram
1
MT598
2
MT598
3
MT598
4
MT598
5
6
7
8
9
10, 11
12,14
13
PSD
Name of message in the diagram
Repo Request (“Sell”)
Repo Request (“Buy”)
Collateral rejection notice
Collateral information ACK
notice
MT202
Buyback transaction
MT296/ERROR Validation Error notification
MT296/AUTH Authorization request
MT295/AUTH Authorization reply
MT296/ERROR Authorization rejection
MT296/WAIT
Settlement Delay notification
MT202
Buyback transaction
MT900
Debit confirmation
Page 88
Version 06.01.01
Central Bank of Oman
Sequential number
of message in the
diagram
15
16
17, 18
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
SWIFT
message type
Name of message in the diagram
MT910
MT296/SETL
MT296/CANC
Credit confirmation
Settlement notification
Cancellation notification
Buyback Request Message Format
Participants must send a MT598 message with the following fields
format to MDSRC to request for Buyback using GDB (as in Step 1 of
above business scheme):
Field description
Sender
Tag
Format
20
16x
12
77E
59a
3!n
504
CRLF
4!a2!a2!c[3!c Always this
]
value:
MDSROMR1XX
X
4!a2!a2!c[3!c Always this
]
value:
Participant BIC
16x
P-REPO-1
34x
10/112/1,2
34x
Counterpart BIC
3!a15d
OMR2000000,
3!a15d
OMR2000000,
Receiver
Transaction Reference
Number
Sub-message Type
54a
Repo reference
Allotment number
Counterpart
Face value (in OMR)
Purchase Price (in OMR)
PSD
20
21C
52D
33B
32B
Page 89
Examples
Always this
value:
Participant BIC
Always this
value:
CBOMOMRUR
TG
P-BB-1
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Field description
Pricing rate (% p.a)
Tag
36
Format
12d
Examples
0,50000
No. of days
38A
3n
0
Interest amount for 365
days
Repo date
36A
12d
0,
30
Repurchase price
Remark
34B
70
6!n
050625
(YYMMDD)
3!a15d
OMR2000000,
34x
1.5m,0.5m
PSD
Page 90
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
7. Rule 7 - Queuing Management
7.1
Principle of Queuing System
RTGS manages one queue per settlement account, where unsettled
payments are stored and processed according to their priority level and
their timestamp (priority + FIFO algorithm).
A credit transfer is a settlement affecting two settlement accounts (payerpayee).
RTGS can effect such a transaction only provided there is:
•
no queued payment order with a higher level of priority;
•
no queued payment order with the same level of priority but
older than the one in question;
•
sufficiency of funds;
•
the settlement account of the payer/payee is not blocked for
debit/credit correspondingly.
If any one of these conditions is not satisfied, the payment order is stored
in the waiting queue or rejected (according to a system configuration).
There is one waiting queue per each settlement account.
The following rules are applied to processing and settlement of payment
orders in the RTGS:
1. The time of accepting of payment order is the time of
registering the related message in the system, i.e. receiving it at
the Central Node from the Participant through the private
network or from the SWIFT network.
2. After validating the message, RTGS checks if the payment
order should be presented to the Settlement engine for further
processing. The presenting of the payment order to the
Settlement engine shall be suspended in case of:
PSD
Page 91
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
i. The payment order has future value date;
ii. The accounts to be credited or debited are blocked for the
related operations;
iii. The Participant that owns the debit or credit account is
suspended;
iv. The settlement process is frozen at the moment.
3. Payment orders that satisfy to the checks in items (1) and (2)
above are presented to the Settlement engine as payment
transaction.
4. The payment is placed into a queue in accordance with the
algorithm (Priority+FIFO in this case) if there are insufficient
funds to settle the payment transaction or if there are already
queued payment transactions to the account with the same or
higher priority. This time is registered as time of queuing.
5. The queue management algorithm processes the payment
transactions in a queue according to the Priority+FIFO
algorithm, where the FIFO aspect of the algorithm is based on
the queuing time of the payment transactions.
When a payment transaction is settled, the system checks if there are any
transactions in the queue for the account(s) credited during the settlement
of the payment transaction. If that is the case, the first transaction in the
queue with the highest priority level is submitted to the settlement
process.
If it cannot be settled then the process is stopped until:
•
•
a new payment transaction comes into the system;
any other function influencing on queue ordering is processed
by RTGS.
If a newly arrived payment order can be settled then:
PSD
Page 92
Version 06.01.01
Central Bank of Oman
•
•
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
The same procedure is performed for the next transaction in the
queue for the same account;
The credited account is kept in memory for later settlement
process initiation for queued payment transactions presented to
this credited account (if any).
This process continues until there are no transaction that can be settled for
the accounts involved in these cascade settlements (or until all queues
become empty).
For transactions with «time-out» execution or rejection, the system
handles each transaction’s presence time within the queue. If the
transaction still remains in the queue after this period of time, then it is
rejected.
RTGS activates the queue management process for each account involved
after the processing of any operation that may influence payment queues
(e.g., suspension/activation of Participant, locking/unlocking of account,
changing of priority of payment order, cancellation of payment order, etc.
As it follows from the queue management algorithm described above, if
there is a queue to any account it does not influence on settlement process
for the payment orders presented to other accounts.
Each Participant may manage and monitor his queue via “transactional”
interface and via WEB-interface.
A Participant (at his request) is allowed to inquire through the aggregated
information about the total number and amount of his instructions in the
queues using MT985/MT986 messages.
7.2
Priority Schemes
Following priority scheme shall be used in RTGS:
•
PSD
Priority 1 – exceptional priority, may used by system
administrator under exceptional and urgent circumstances only.
Page 93
Version 06.01.01
Central Bank of Oman
•
•
•
•
•
•
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Any payment with priority 1 should pass through additional
authorization;
Priority 2 – REPO operations;
Priority 3 – Clearing operations;
Priority 4 – Buy-back operations;
Priority 5 –covers all payment between Central Bank and
participants including FOREX, payroll, etc;
Priorities 6-9 – Central Bank internal operations, GL
transactions;
Priorities 10-99 – Participant’s operations that may be queued in
case of lack of funds (using of priority value 10 for urgent
transfers, 20 – for normal-priority transfers and 30 for lowpriority transfers is recommended).
Logically, each group may be considered as a separate queue. It means
that each Participant should have special access rights to send payments
to each of such logical queues or to move payment from one queue to
another. Inside a queue, payments are processed according to a
Priority+FIFO algorithm. Payment instructions are sequenced in a queue
according to this Priority+FIFO algorithm. Participants or authorized
Central Bank personnel may change the position of a payment instruction
in the queue by changing the value of its priority (MT195/MT295). No
payments with a lower priority may be settled if a payment with higher
priority is waiting for settlement (except in special cases such as gridlock
resolution).
Participants are allowed to send payments to a given group, to modify
their position in the queue, either by changing their priority or by
withdrawing and re-sending them later (which modifies the time-stamp,
and consequently the order in the queue). Changing the priority to the
same value also leads to moving of a transfer to the tail of a queue.
If no priority is defined in the credit transfer, RTGS imposes the lowest
priority.
7.3
PSD
Queue Cancellation
Page 94
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Payment order shall be removed from a queue if:
• payment is settled;
• payment is cancelled (by MT192/MT292).
If at the end of day some instructions remain queued, the Central Bank
RTGS System shall automatically cancel them.
7.4
Repriority of Queue
Each Participant and the Central Bank may control the queue by reordering of the payment instructions in a queue (using “Change priority”
message MTn95) or cancelling payments in a queue (using
“Cancellation” message MTn92). A Participant may change position of a
payment instruction sent by him earlier by changing the value of its
priority.
7.5
Grid Lock Resolution
Gridlock occurs when two or more payment queues are blocked due to
shortage of funds, although when all queued payments are settled, there
may be no shortage of funds. RTGS detects gridlock situation and selects
those payments that can be settled on a Net basis whilst preserving the
normal business conditions attached to the transactions.
RTGS automatically detects possible Gridlock and issues the appropriate
alarm. The following parameters are set for this purpose:
1) Number of payment instructions queued by the system,
2) Amount of funds in payment instructions queued by the system,
3) Number of payments that were queued since last posting
operation by the system.
Two algorithms are in use in Gridlock Resolution Subsystem:
1) "Simulated net balance" is a number of consecutive applications
SCBCP ("sequential constrain bank clearing problem") with
addition criterion function on volume or value optimization.
PSD
Page 95
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
2) "Bypass FIFO" - attempt to execute documents by way of their
receipt. If to execute the document it is not possible - it is
passed. It is applied cyclically while there are facts of execution
of documents. Criterion function as such is absent.
The Central Bank is authorised to determine the algorithm to be adopted
to resolve each case of gridlock situation.
The Central Bank shall be authorised to initiate the Gridlock resolution
mechanism manually.
During the Gridlock resolution process, payment instruction queues are
frozen and new payment instructions are not “taken into account” until
the process is complete. After re-activation of normal exchange period
these new payment instructions shall be activated automatically on
queue-ordering basis.
7.6
End of Day
The unsettled outstanding queued Payment Message with insufficient
funds shall be automatically be cancelled. It is the responsibility of the
Participant to ensure the re-entering of these Payment Messages on the
next Business Day for processing. No outstanding Payment Message shall
be carried forward for execution for the next value date.
8. Rule 8 - Central Bank of Oman Payment
8.1
8.1.1
General
Central Bank Transaction
The Central Bank shall be a Participant and is subject to these rules. The
Central Bank as Participant is not restricted to any Intraday liquidity
requirements or limits. Hence, all Payment Messages posted by the
Central Bank shall be settled immediately.
PSD
Page 96
Version 06.01.01
Central Bank of Oman
8.2
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Payments from Central Bank to Participants
The Central Bank shall credit or debit transactions to Participants’
settlement accounts for the following types of payment.
8.2.1
Incoming Forex Payment
The Central Bank will send a MT202 payment instruction to RTGS for
settlement of the Omani Rial leg of a foreign exchange deal transaction in
which Central Bank is the buyer of the foreign currency and the
participant is the seller of the foreign currency. The payment will debit
the Central Bank settlement account and credit to a participant Settlement
Account in RTGS.
The payment will use the following transaction type code in field 72 of
the payment instruction.
Transaction Type code:
8.2.2
/ CODTYPTR /005
GLD/90101.FOREX
Treasury & Monetary Operations Payment
The Central Bank will send MT202 payment instructions to RTGS for the
following types of Treasury & Monetary Operations transaction:
Monetary
Operations
Payment
Intraday Repo
with CBO
Debit A/C Credit
A/C
CBO SA
Participant
SA
007
90102.REPO
Overnight
Repo with
CBO
CBO SA
Participant
SA
007
90102.REPO
PSD
Page 97
Transaction GLDebit
Control Account
Type code
Version 06.01.01
Central Bank of Oman
Monetary
Operations
Payment
Maturity of
Reverse Repo
Interbank
Repo
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Debit A/C Credit
A/C
CBO SA
Participant
SA
Buyer
Seller
Participant Participant
SA
SA
Interbank
Seller
Buyer
Repo Buyback Participant Participant
SA
SA
Maturity of T- CBO SA
Participant
bill
SA
Maturity of
CBO SA
Participant
CD
SA
Discounting of CBO SA
Participant
T-bill
SA
Transaction GLDebit
Type code
Control Account
015
90102.REPO
007
90102.REPO
015
90102.REPO
008
90103.GOVTSEC
021
90104.CDBKS
020
90111.TBDISC
In above table ‘SA’ represents Settlement Account in RTGS system.
Apart from sending and receiving of payments via RTGS, the processing
of the above-indicated transactions, including principal, interest and
commission amount calculation shall follow the existing rules for
Treasury and Monetary Operations as defined by the Central Bank.
8.2.3
Central Bank Bills Payment
The Central Bank shall send either MT103 or MT202 payments via
RTGS to transfer funds to participant banks for paying various Central
Bank bills to suppliers who hold bank accounts with the respective
participant banks.
The payment will use the following transaction type code in field 72 of
the payment instruction.
Transaction Type code:
PSD
/ CODTYPTR /018
GLC/90109.BILLS
Page 98
Version 06.01.01
Central Bank of Oman
8.2.4
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Payroll
The Central Bank shall send (MT202) payment via RTGS to transfer
funds to the respective participant banks for paying salaries to the Central
Bank employees.
The payment will use the following transaction type code in field 72 of
the payment instruction.
Transaction Type code:
8.2.5
/ CODTYPTR /016
GLD/90107.PAYROLL
Bank Deposit Insurance Scheme
The Central Bank shall send (MT202) payment via RTGS to transfer
funds to the respective participant banks for payment of any insurance
claims accepted by the Central Bank
The payment will use the following transaction type code in field 72 of
the payment instruction.
Transaction Type code:
8.2.6
/ CODTYPTR /022
GLD/90112.BDIS
Pension Fund
The Central Bank shall send (MT202) payment via RTGS to transfer
funds to the respective participant banks for paying pension to the Central
Bank retired employees.
The payment will use the following transaction type code in field 72 of
the payment instruction.
PSD
Page 99
Version 06.01.01
Central Bank of Oman
Transaction Type code:
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
/ CODTYPTR /023
GLD/90113.PENSION
8.3 Payments from Participant to Central Bank
8.3.1
Outgoing Forex Payment
Participant will send a MT202 payment instruction to RTGS for
settlement of the Omani Rial leg of a foreign exchange deal transaction in
which the Central Bank is the seller of the foreign currency and the
participant is the buyer of the foreign currency. The payment will debit
participant settlement account and credit to the Central Bank Settlement
Account in RTGS.
The payment will use the following code words in field 72 of the
payment instruction.
Transaction Type code:
/ CODTYPTR /004
/GLC/90101.FOREX
If the outgoing Forex payment is valued on Friday or a scheduled
holiday, the Central Bank shall use a special business schedule shall be
on the Friday or holiday in which only valued Forex payments shall be
allowed for settlement. Under such situations, when the business day
cycle for Thursday or the day before holiday is completed, the Central
Bank shall perform settlement of Forex payment using the special
business day schedule.
After the special business day schedule is completed, the Central Bank
shall close the system. System shall only be open again on the next
business day. Participants need to ensure their settlement accounts have
sufficient fund at the end of Thursday business day or business day before
holiday.
PSD
Page 100
Version 06.01.01
Central Bank of Oman
8.3.2
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Treasury & Market Operations Payment
Participant will send MT202 payment instructions to RTGS for the
following types of Treasury & Monetary Operations transaction:
Market
Operations
Payment
Buy-back of
Intraday Repo
Maturity of
overnight Repo
Reverse Repo (CD
& T-bill)
Settlement of Tbill issued at
auction.
Debit A/C Credit
A/C
Settlement of CD
issued at auction.
Participant
SA
Participant
SA
Participant
SA
Participant
SA
Transaction
Type code
GLC
CBO SA
015
90102.REPO
CBO SA
015
90102.REPO
CBO SA
015
90102.REPO
CBO SA
008
90103.GOVTSEC
Participant CBO SA
SA
021
90104.CDBKS
Participant CBO SA
Settlement of
SA
Government
Development Bond
issued at auction.
008
90103.GOVTSEC
In above table ‘SA’ represents Settlement Account in RTGS system.
Participants are required to input the correct values of Transaction type
code (using codeword /CODTYPTR/) and the CBO GL account to be
credited (using codeword /GLC/) in field 72 of the respective MT202
payment message.
Apart from sending payments via RTGS system, the processing of the
above indicated transactions shall follow the existing rules for Treasury
and Monetary Operations as defined by the Central Bank.
PSD
Page 101
Version 06.01.01
Central Bank of Oman
8.3.3
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Banking Fees payment to Central Bank
Participants shall send MT202 payments via RTGS to transfer funds to
CBO for paying banking fees e.g. license fees.
The payment will use the following code words in field 72 of the
payment instruction.
Transaction Type code:
GLC:
8.3.4
/ CODTYPTR /017
/GLC/90108.BKSFEES
Bank Deposit Insurance Scheme
The respective participants shall send (MT202) payment via RTGS to
transfer funds to the CBO for payment of any insurance premium due to
the Central Bank
The payment will use the following transaction type code in field 72 of
the payment instruction.
Transaction Type code:
8.3.5
/ CODTYPTR /022
GLC/90112.BDIS
Pension Fund
The respective participant banks shall send (MT202) payment via RTGS
to transfer funds to the Central Bank for refunds, if any, of the pension
remitted by the Central Bank earlier
The payment will use the following transaction type code in field 72 of
the payment instruction.
Transaction Type code:
PSD
/ CODTYPTR /023
GLC/90113.PENSION
Page 102
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
9. Rule 9 - Finality of Payment
9.1
Definition of Finality
As prescribed in section 4.8 sub section 4.8.2 under Revocation of
Payment Message. Once the Settlement account of the sending participant
has been debited and the receiving participant settlement account has
been credited, the payment is deemed final.
9.2
Irrevocability of Transfer
The relevance of Bankruptcy to the RTGS implementation arises out of
the concept of finality and irrevocability of the transfers effected through
the RTGS System. When such transfers are executed they are deemed
final and irrevocable. On the other hand, under Bankruptcy Provisions in
Articles 604 through 612 of Oman Commercial Law, transactions and
payments made by a bankrupt may be held null and void by a Judicial
decree pursuant to a legal action instituted by the group of creditors or the
receiver in bankruptcy.
However, from the above-mentioned Articles 604 – 612 on Bankruptcy it
is clear that some types of transactions/payments made by the bankrupt
may be decreed null and void by a judicial decision i.e. such transactions
are revocable and not final.
The rule of finality and irrevocability of an RTGS transfer means that
once the transfer is executed through the RTGS System it becomes final
as of the moment of execution and cannot be amended or revoked by the
participant or the payor. This rule also applies if the payor is a bankrupt.
But this doesn’t preclude the group of creditors, or the receiver in
bankruptcy, from bringing an action in court against the alienee (the
transferee) at any later date to obtain a judicial decree to compel him to
return to the bankruptcy what he obtained from the transaction or the
value thereof at the time of receipt. Revocability in such case emanates
from the nature of the transaction and the fact that it is deemed revocable
by other Omani legislations such as the Commercial Law, the Law of
PSD
Page 103
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Money Laundering, the Penal Code of Oman or any other effective Law
under which recovery of illegally obtained property is required. In other
words, revocability attaches to the type of transaction and not the
operation of transfer itself. And as evident, transfer through the RTGS
System doesn’t confer any legality or immunity upon an otherwise void
or voidable transaction.
9.3
Dispute relating to Returns of Funds
It is important to differentiate between something, which may be pursued
by a court action, and an order made for return of the money (i.e. in the
case of the bankruptcy provisions in Book 5 of the Commercial Law) and
a provision which means that an entire transfer transaction can be
unwound. It is agreed that in the case of the Money Laundering Law, the
Commercial Law and the Penal Code (together with any other law which
may allow for the recovery of funds incorrectly or illegally paid), the
proper application of the law is to seek a court order and then to have the
court order to compel recipient to repay the funds. It does not involve the
“unwinding” of the actual transfer of funds in the first instance.
10. Rule 10 - Testing, Certification and Change Control
10.1
Participant Pre-requisite
Each participant is required to perform all necessary modifications to its
own systems linked to the RTGS systems at its own expense, and ensure
implementation and adherence to all relevant procedures as may be
required.
10.2
Service Level Specification
The Central Bank may from time to time specify the service levels to be
provided by RTGS and determine the service levels of the participants’
systems, used in relation to the RTGS.
PSD
Page 104
Version 06.01.01
Central Bank of Oman
10.3
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Certification Requirement
Any new Participant has to the fulfil the following steps prior to
connecting to the RTGS System before the live operations:
a) Complete the RTGS 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 Agreement for the Provision of CBO
National Payment Service
10.4
Participants’ Responsibility
Each participant has the following responsibilities:
a) To develop their internal systems for linking to / from RTGS
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 RTGS installations at
their site using facilities made available by the Gateway.
Day to day responsibility for operating its RTGS Gateway, host system
and the interface between its own host system and RTGS Gateway.
10.5
Basic Requirement of RTGS
RTGS shall provide the following minimum features to all the
participants at the entry level:
a)
b)
c)
d)
e)
PSD
Manual input of payment messages
System format validation
Message authorization with dual control
Printing and reconciliation of messages
Storage of messages in the database at participant’s end
Page 105
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
f) Online monitoring of RTGS payment transactions and
settlement account.
g) Access control
h) Message sequencing and Queue management.
i) Transaction audit trail
j) Free format message exchange facility between participants as
well as with the Central Bank
10.6
Authority to Effect Change
No participant has the authority to make changes of any nature to the
RTGS systems or install / use any software or any part of the RTGS
systems without the prior written approval of the Central Bank.
10.7
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 RTGS,
including any known or planned disconnection from RTGS, or any
significant changes to its host system interface to RTGS, its organization
structure, or environment.
10.8
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 RTGS.
10.9
Operations by Participants
Each participant shall operate the areas of RTGS, in line with its control
and responsibilities, as laid down in the control documents.
PSD
Page 106
Version 06.01.01
Central Bank of Oman
10.10
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Change Control
10.10.1
RTGS changes:
The Central Bank is authorized to make any changes to RTGS 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 update 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.
10.10.2
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.
10.10.3
Advice of changes
These Operating Rules and Regulations 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.
11. Rule 11 - Fees and Charge
PSD
Page 107
Version 06.01.01
Central Bank of Oman
11.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.
At the initial stage of production operation of RTGS, Central Bank will not charge the
participant for transaction fees. 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.
11.2
Collection of Fee and Charges
11.2.1 MTn90: Advice of Charges, Interest and Other Adjustments
RTGS calculates requested charges at pre-defined period of time,
generates related MTn90 and sends it to Central Bank department
responsible for payment generation (e.g., Central Bank Banking
department).
11.2.2 MTn91: Request for Payment of Charges, Interest and Other Expenses
The RTGS calculates charges at pre-defined period of time, generates
related messages and sends it to related Participant.
PSD
Page 108
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
12. Rule 12 - Emergency Condition
12.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 15 sub-section 15.6
12.2
Request for Extension
Should there be a need for Extension of the RTGS Service to any of the
Participants, the participants must complete the following steps:
a) Log a Call with the Help Desk
b) Send request through MT 199 in case the MT 199 message cannot
be transmitted over communication network
c) Send a written request to the Payment Systems Department
Manager by fax for authorization of the extension.
The Central Bank has the sole discretion to approve or reject the
extension request.
12.3
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 fund the settlement account and complete the settlement. The Clearing
transactions of the Participant will not be cancelled under this condition.
12.4
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
following failures, malfunctions…etc occur.
PSD
Page 109
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
12.4.1 Case 1: Failing of the Private Network at the Central Node
The RTGS 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 RTGS Central mode administrator must change the mode of the
participating communication activating "SWIFT Network" by means of
BackOffice Workplace.
If malfunction of Private network happens during the period of exchange,
the participant must, having been reconnected, sent a request MT920 to
acquire situation of its operations at the RTGS system level: regulated
payment orders and orders in a queue (certain issued orders, being able to
not have been issued in the system with of the reason malfunction). In
case of loss of operation, the Participant can resend to the system the
copy of every lost order. RTGS verifies the copy of payment orders of
participants. There is no risk of double settlement of the same order. The
participants can also issue the MT985/STAT request messages.
In this case of decision to use Service bureau:
RTGS supports the same message types both for SWIFT and private
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 RTGS message exchange point of view. To
resume the operations via Private network, the channel of communication
"Private network" must be specified for any the participants by means of
BackOffice Workplace. This switch may be done in real-time mode, but
it is preferable to it the end of business day when the processing is ended.
PSD
Page 110
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
12.4.2 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 of Oman, Payment Systems Department
for inputting the messages. In the Future the same will done through
inputting the messages through the Service Bureau operated by the
Central Bank, and the Central Bank will advise the procedure accordingly
when the Service Bureau is available.
12.4.3
Case 3: Failing of the RTGS Central Site
The RTGS central system administrator must immediately inform all the
participants by broadcasting the message via Web monitoring; Webmonitoring components can function in spite of the RTGS 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. The participants who use SWIFT network have
to follow SWIFT methods to send messages to the backup site. For the
participants using the Private Network, the communication components
of RTGS switches the routing messages on the backup site automatically.
The resumption of the service on the main site must be made after
necessary procedures for DBMS mirroring shall be performed (as a rule,
during the nearest holidays).
In switching the service on the backup site, the participants must
conciliate their positions according to the algorithm represented in
Case 1.
12.4.4
Case 4: Failing of WEB monitoring
“Failing of WEB monitoring” refers to all of these types of fails (web
server fails, network fails and application fails), because procedures to be
followed in these cases are the same.
PSD
Page 111
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
The RTGS central system administrator must immediately inform all the
participants by broadcasting the MTn99/TEXTMESSAGE or by other
means: telephone and fax to inform all the participants. Participants
continue their work using message exchange via SWIFT or Private
network.
After resuming the service, the RTGS central system administrator must
inform all the participants by broadcasting the MTn99/TEXTMESSAGE.
The Participants may resume monitoring via WEB monitoring
component.
12.4.5 Case 5: Failing of the Private Network on Participant site
Participant should switch to the SWIFT Network or to Service Bureau.
In case of decision to work via private network:
The participant establishes connection via SWIFT network: In this case
the RTGS Central mode administrator must change the mode of the
participating communication activating "SWIFT Network" by means of
BackOffice Workplace.
If malfunction of Private network happens during the period of exchange,
the participant must, having been reconnected, sent a request MT920 to
acquire situation of its operations at the RTGS system level: regulated
payment orders and orders in a queue (certain issued orders, being able to
not have been issued in the system with of the reason malfunction). In
case of loss of operation, the Participant can resend to the system the
copy of every lost order. RTGS verifies the copy of payment orders of
participants. There is no risk of double settlement of the same order. The
participants can also issue the MT985/STAT request messages.
13. Rule 13 - Disciplinary
13.1
PSD
Authority
Page 112
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
The Central Bank has the special authority to take necessary timely action
on the Participants to ensure efficient operation of the RTGS.
13.2
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 of RTGS or any other reason deemed appropriate by
the Central Bank.
13.3
Suspended Participant’s obligation
In the event a participant has been suspended from RTGS, 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 RTGS rules. The Central Bank shall direct the
suspended participant to surrender its rights, systems, software and any
other material related to RTGS.
13.4
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 participant. The other participants shall be
advised of the suspension through a similar communication immediately.
PSD
Page 113
Version 06.01.01
Central Bank of Oman
13.5
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Re-admission
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.
14. Rule 14 - Default Processing
14.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.
14.2
Notification of Default
This is governed by clause number 7 of the “Agreement for the Provision
of the Central Bank of Oman Real-Time Gross Settlement Service”
agreement document.
14.3
Participant Obligation
This is governed by clause number 7 sub section 7.2 of the “Agreement
for the Provision of the Central Bank of Oman National Payment
Service”.
15. Rule 15 - Obligation to Law (Miscellaneous Provision)
15.1
Central Bank of Oman
Notwithstanding anything to the contrary stated in the RTGS rules and
regulations 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:
PSD
Page 114
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
i.
Delay caused due to breakdown, malfunctioning or
deficiency of RTGS system including hardware,
software, telecommunication and electrical systems.
ii.
Partial or complete disruption or failure of RTGS to
provide all or any other services provided by RTGS.
iii.
For the losses caused due to failure of the participants
systems.
iv.
The negligence, fraud, dishonesty, misconduct,
unfamiliarity or omission of the participant or its official
or employee in the use of RTGS.
However, the Central Bank shall be liable for Losses caused due to gross
negligence or wilful 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.
15.2
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.
15.3
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 RTGS arising directly or indirectly from
circumstances beyond its or his reasonable control, without limitation,
strike, lockout, equipment malfunction, government action, riot and war.
PSD
Page 115
Version 06.01.01
Central Bank of Oman
15.4
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Central Bank Personnel
Nothing in this rule (15) shall prejudice the liability of 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.
15.5
Officers, employees and Agents
The Central Bank retains the benefit of Rule 15 subsection 15.1 and 15.2
for itself and for the benefit of its officers, employees and agents.
15.6
Emergencies
If any malfunction, breakdown, or interruption or any emergency affects
RTGS 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 or curtail the hours of
operations of RTGS, pause any Participant, direct the use of contingency
facilities or close down RTGS in whole or in part. The Central Bank shall
not be liable for any directions so given.
15.7
Participants Act as Principals
Each participant shall be liable as principal in respect of its payment
messages.
15.8
Assignments
No Participant shall assign all or any of its rights or obligations accruing
from the membership of RTGS and the National Payment Service
Agreement. The Agreement however binds the successors of each
Participant.
15.9
PSD
Dispute Settlement
Page 116
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
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.
15.10
Governing Law
These Operating Rules are governed by the Laws of the Sultanate of
Oman.
PSD
Page 117
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
16. Rule 16 - Contact
16.1
Payment Systems Department Help-Desk
Refer to Appendix 11
Should there be any change the Central Bank will advice the Participant
the contact number of the RTGS System Help Desk via email or
publishes them on the web-monitoring site of the RTGS System.
16.2
Contact Details
Refer to Appendix 11
PSD
Page 118
Version 06.01.01
Central Bank of Oman
17.
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Appendices
Appendix 1 RTGS Participants
Appendix 2 Repo Operations
Appendix 3 Interbank Repo Operations
Appendix 4 Buy-Back Operations
Appendix 5 Request for Buy-Back transaction initiated by Participant
(Interbank REPO).
Appendix 6 Automated request for Buy-Back operation sent by RTGS to
Monetary Operations Domain
Appendix 7 (Interaction with MDSRC) REPO transaction initiated by
Participant
Appendix 8 (Buy-back operations with MDSRC) Request for Buy-Back
transaction initiated by Participant
Appendix 9 Automated request for Buy-Back operation sent by RTGS to
MDSRC
Appendix 10 Glossary of Terms
Appendix 11 Contact Details
PSD
Page 119
Version 06.01.01
Central Bank of Oman
Appendix 1
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
RTGS Participants
Participant Names and BIC Codes
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 Securities Market
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
State General Reserve Fund
Indirect Participants
Ministry of Finance – Customs Revenue
Ministry of Finance – Wadi AlDhika C/A
Switch Suspense Account
UAE Switch Account
Central Bank Departments
CBO Payment Systems Department
RTGS Section
Automated Clearing House
Finance Department
Human Resources Department
Banking Development Department
International Settlements Department
Treasury & Monetary Operations Depart (TMOD)
Accounting & Banking Operation Department
Currency Department
CBO Salalah Branch
CBO Sohar Branch
PSD
Page 120
BIC
ALLIOMRXXXX
MELIOMRXXXX
BMUSOMRXXXX
BDOFOMRUXXX
BARBOMMXXXX
BABEOMRXXXX
BSIROMRXXXX
CBOMOMRUXXX
HABBOMRXXXX
BBMEOMRXXXX
MOFOOMRXXXX
XMUSOMM1XXX
MDSROMR1XXX
NBADOMRXXXX
NBOMOMRXXXX
OMABOMRUXXX
ODBLOMRUXXX
OHBLOMRXXXX
OIBAOMMXXXX
SBINOMRXXXX
SCBLOMRXXXX
SGRFOMRUXXX
CUSTOMRUXXX
WADIOMRUXXX
ATMSOMRUXXX
UAESOMRUXXX
CBOMOMRURTG
CBOMOMRUCLH
CBOMOMRUFID
CBOMOMRUHRD
CBOMOMRUBDD
CBOMOMRUISD
CBOMOMRUTMD
CBOMOMRUACC
CBOMOMRUCUR
CBOMOMRUSAL
CBOMOMRUSOH
Version 06.01.01
Central Bank of Oman
Appendix 2
Part
PartAA
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Repo Operations
Central
Central
Bank
Bank
Liquidity
Department
RTS/X
1: Request for REPO
KO
2: Collateral rejection
OK
KOValidation
3: Collateral information ACK
OK
Blocking of
Securities
4: REPO transaction
OK Validation
OK
Possible
to settle
now?
OK
OK
OK
8: REPO
transaction
5: Validation
error notification
KO
KO
6: Settlement
delay notification
OK
KO
7: Settlement
delay notification
Waiting
for
settlement
9: Debit confirmation
OK
10: REPO
transaction
12: Settlement
notification
OK
11: Credit confirmation
13: Cancellation
notification
End-of-day
Cancellation
14: Cancellation
notification
OK
Business scheme description
1. The Participant issues the request for REPO operation to RTGS.
RTGS checks the syntax of this message and routes this message to
Monetary Operations Domain authorized for providing of REPO
against securities this Participant intends to use for REPO (Step 1),
2. The Monetary Operations Domain validates the Participant’s
request and notifies this Participant about the result of the
validation. Again, to do this, the Monetary Operations Domain
sends message to RTGS, and RTGS routes the message to the
related Participant (Step 2 or Step 3),
3. The Monetary Operations Domain blocks the securities that should
be involved with the REPO operation and issues the corresponding
payment order to RTGS (Step 4). As a rule, the REPO transactions
have a higher priority levels than ordinary payment orders,
PSD
Page 121
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
4. RTGS accepts this payment order, validates and tries to settle it.
Error notification is issued in case unsuccessful validation (Step 5),
5. The Participant and the Monetary Operations Domain are notified
about the settlement of the REPO transaction (Steps 6-12),
6. At the end-of-day RTGS automatically cancel all REPO
transactions remain unsettled with appropriate notifications sent to
parties involved (it may happen in exceptional situations only,
Steps 13-14).
Table of messages in the scheme
Sequential number of
message at the diagrams
1
SWIFT message
type
MTn98
Name of message at the
diagram
Collateral information
2
MTn98
Collateral rejection notice
3
MTn98
Collateral information ACK
notice
4
MT202
REPO transaction
5
MT296/ERROR
Validation Error notification
6, 7
MT296/WAIT
Settlement Delay notification
8
MT202
REPO transaction
9
MT900
Debit confirmation
10
MT202
REPO transaction
11
MT910
Credit confirmation
12
MT296/SETL
Settlement notification
13, 14
MT296/CANC
Cancellation notification
NB. REPO operations shall be entered manually by Monetary Operations
Domain administrator.
PSD
Page 122
Version 06.01.01
Central Bank of Oman
Appendix 3
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Interbank Repo Operations
Liquidity
department
PartB
Matching
1: Order «Sell »
2: Order «Buy »
OK
3: Request for REPO
4: Collateral rejection
KO
6: REPO transaction
OK
Validation
11: Credit
confirmation
OK
12: REPO transaction
OK
13: Debit
confirmation
Possible
to settle
now?
KO
OK
7: Validation
Error notification
KO
KO
9: Settlement
delay notification
Waiting
for
settlement
OK
End-of-day
or timeout
cancellation
14: Settlement
notification
16: Cancellation
notification
15: Cancellation
notification
KO
Delivery
Securities
8: Settlement
delay notification
10: REPO transaction
OK
Validation
Unblock
securities
OK
OK
KO
5: Collateral information ACK
OK
KO
KO
Block
Securities
PartA
RTS/X
Business scheme description
•
A Participant sends a request “to buy” securities to Monetary
Operations Domain; another Participant sends a request “to sell”
securities to Monetary Operations Domain. These requests may be
sent to Monetary Operations Domain directly through RTGS, or
through another system that shall route this Message to Monetary
Operations Domain (Steps 1-2).
•
Monetary Operations Domain shall match the buy and sell
transactions and store them till settlement date.
•
On the value date for settlement Monetary Operations Domain shall
first block the securities to be delivered for each transaction (after
verification of quantity availability).
PSD
Page 123
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
•
The Participant issues the request for REPO operation to RTGS.
RTGS checks the syntax of this message and routes this message to
Monetary Operations Domain authorized for providing of REPO
against securities this Participant intends to use for REPO (Step 1),
•
The Monetary Operations Domain validates the Participant’s request
and notifies this Participant about the result of the validation. Again,
to do this, the Monetary Operations Domain sends message to
RTGS, and RTGS routes the message to the related Participant (Step
2 or Step 3),
•
The Monetary Operations Domain blocks the securities that should
be involved with the REPO operation and issues the corresponding
payment order to RTGS (Step 4). As a rule, the REPO transactions
have a higher priority levels than ordinary payment orders,
•
RTGS accepts this payment order, validates and tries to settle it.
Error notification is issued in case unsuccessful validation (Step 5),
•
The Participant and the Monetary Operations Domain are notified
about the settlement of the REPO transaction (Steps 6-12),
•
At the end-of-day RTGS automatically cancel all REPO transactions
remain unsettled with appropriate notifications sent to parties
involved (it may happen in exceptional situations only, Steps 13-14).
Table of messages in the scheme
Sequential number
SWIFT
of message in the
Name of message in the
message type
diagram
1
MTn98
Order “Sell”
2
MTn98
Order “Buy”
3
MTn98
Request for REPO
4
MTn98
Collateral rejection notice
5
MTn98
Collateral information ACK
diagram
notice
PSD
Page 124
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
6
MT202
REPO transaction
7
MT296/ERROR
Validation Error
notification
8, 9
MT296/WAIT
Settlement Delay
notification
PSD
10
MT202
REPO transaction
11
MT910
Credit confirmation
12
MT202
REPO transaction
13
MT900
Debit confirmation
14
MT296/SETL
Settlement notification
15, 16
MT296/CANC
Cancellation notification
Page 125
Version 06.01.01
Central Bank of Oman
Appendix 4
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Buy-Back Operations
Request for Buy-Back transaction initiated by Participant
PartA
Central
Bank
RTS/X
Liquidity
Department
1: Request for buy-back
KO
OK
2: Buy-back
rejection
Validation
OK
3: Buy-back notification ACK
OK
4: Buy-back transaction
OK
KO
Possible
to settle
now?
8: Buy-back transaction
OK
9: Debit confirmation
OK
10: Buy-back transaction
OK
11: Credit confirmation
Status
KO
KO
7: Settlement
delay notification
6: Settlement
delay notification
OK
KO
5: Validation Error
Notification
Validation
Waiting
for
settlement
End-of-day
cancellation
OK
13:Cancellation
notification
12: Settlement
Notification
14: Cancellation
notification
OK
Buy-back settlement:
Securities leg
OK
Business scheme description
1. Any Participant may issue a request for a Buy-back operation to
RTGS. This request is validated by RTGS and routed to the
Monetary Operations Domain for further validation and processing
(Step 1),
2. In case of a validation error, the Participants receive “technical
rejection” answer with an error description (Steps 2) or Buy-back
acknowledgement (Step 3),
3. In case of positive acknowledgement Monetary Operations Domain
issues a corresponding Buy-back transaction to RTGS (Step 4).
RTGS accepts this transaction, validates it and tries to settle it
according to the normal queuing technique. As a rule, Buy-back
transactions have a higher priority level than ordinary payment
orders (Steps 6-12),
4. Buy-Back operations remain unsettled at the end-of-day are
cancelled automatically with appropriate notifications sent to
parties involved (Steps 13-14).
PSD
Page 126
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Table of messages in the scheme
Sequential number of
message in the
diagram
1
2
3
4
5
6, 7
SWIFT message type
Name of message in the
diagram
MTn98
MTn98
MTn98
MT202
MT296/ERROR
MT296/WAIT
Request for Buy-Back
Buy-back rejection
Buy-back notification ACK
Buy-back transaction
Validation Error notification
Settlement Delay notification
8
MTn98
Buy-back transaction
9
MT900
Debit confirmation
10
MTn98
Buy-back transaction
11
MT910
Credit Confirmation
12
MT296
Settlement notification
13,14
MT296/CANC
Cancellation notification
PSD
Page 127
Version 06.01.01
Central Bank of Oman
Appendix 5
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Request for Buy-Back transaction initiated by
Participant (Interbank REPO)
PartB
RTS/X
Liquidity
Department
PartA
1: Request for buy-back
KO
OK
2: Buy-back
rejection
Validation
OK
3: Buy-back notification ACK
OK
4: Buy-back transaction
OK
KO
8: Buy-back transaction
OK
9: Debit confirmation
OK
10: Buy-back transaction
OK
11: Credit confirmation
Status
KO
KO
7: Settlement
delay notification
6: Settlement
delay notification
OK
KO
Possible
to settle
now?
5: Validation Error
Notification
Validation
Waiting
for
settlement
End-of-day
cancellation
OK
13:Cancellation
notification
12: Settlement
Notification
14: Cancellation
notification
OK
Buy-back settlement:
Securities leg
OK
Business scheme description
Any Participant may issue a request for a Buy-back operation to RTGS.
This request is validated by RTGS and routed to the Monetary Operations
Domain for further validation and processing (Step 1),
In case of a validation error, the Participants receive “technical rejection”
answer with an error description (Steps 2) or Buy-back acknowledgement
(Step 3),
In case of positive acknowledgement Monetary Operations Domain
issues a corresponding Buy-back transaction to RTGS (Step 4). RTGS
accepts this transaction, validates it and tries to settle it according to the
normal queuing technique. As a rule, Buy-back transactions have a higher
priority level than ordinary payment orders (Steps 6-12),
Buy-Back operations remain unsettled at the end-of-day are cancelled
automatically with appropriate notifications sent to parties involved
(Steps 13-14).
Table of messages in the scheme
PSD
Page 128
Version 06.01.01
Central Bank of Oman
Sequential number of
message in the
diagram
1
2
3
4
5
6, 7
8
9
10
11
12
13,14
PSD
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
SWIFT message type
Name of message in the
diagram
MTn98
MTn98
MTn98
MT202
MT296/ERROR
MT296/WAIT
MTn98
MT900
MTn98
MT910
MT296
MT296/CANC
Request for Buy-Back
Buy-back rejection
Buy-back notification ACK
Buy-back transaction
Validation Error notification
Settlement Delay notification
Buy-back transaction
Debit confirmation
Buy-back transaction
Credit Confirmation
Settlement notification
Cancellation notification
Page 129
Version 06.01.01
Central Bank of Oman
Appendix 6
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Automated request for Buy-Back operation sent by
RTGS to Monetary Operations Domain
Liquidity
Department
RTS/X
PartA
Automated
Buy-Back
request
Central
Bank
1: Request for buy-back
2: Buy-back transaction(s)
OK
Possible
to settle
now?
Validation
KO
3: Validation Error
Notification
KO
5: Settlement
delay notification
4: Settlement
delay notification
KO
7: Debit confirmation
Waiting
for
settlement
OK
8: Buy-back transaction
OK
OK
9: Credit confirmation
10: Settlement
Notification
11: Cancellation
notification
12: Cancellation
notification
OK
6: Buy-back transaction
OK
KO
Status
KO
End-of-day
cancellation
OK
Buy-back settlement:
Securities leg
OK
Business scheme description
1) At the special period within a day RTGS issues a request for BuyBack operations for any REPO operation remain “unbuy-backed” to
Monetary Operations Domain. Monetary Operations Domain then
issues to RTSX a Buy-back transaction for every REPO operation
remain “unbuy-backed” and RTSX tries to settle these Buy-back
transactions on individual basis,
2) It is the responsibility of the Monetary Operations Domain to convert
REPO operations to Overnights (or perform other operations
accordingly to pre-defined arrangements) if some of REPO operations
are not returned by related Buy-backs during the day due to lack of
funds on Participant’s Settlement account or any other reasons.
Table of messages in the scheme
Sequential number of
SWIFT
message in the
message type
diagram
1
MTn99
2
PSD
MT202
Page 130
Name of message in the
diagram
Request for Buy-Back
Buy-back transaction
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Sequential number of
SWIFT
message in the
message type
diagram
3
MT296/ERROR
PSD
Name of message in the
diagram
Validation Error notification
4, 5
MT296/WAIT
Settlement Delay notification
6
MTn98
Buy-back transaction
7
MT900
Debit confirmation
8
MTn98
Buy-back transaction
9
MT910
Credit Confirmation
10
MT296
Settlement notification
11,12
MT296/CANC
Cancellation notification
Page 131
Version 06.01.01
Central Bank of Oman
Appendix 7
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
(Interaction with MDSRC) REPO transaction
initiated by Participant
Liquidity
Liquidity
Department
Department
Part.
Part.Bi
Bi
MDSRC
RTS/X
1: Request for REPO
3: Collateral information ACK
OK
OK
6: Authorization
request
OK Validation
4: REPO transaction
KO
7: Authorization
reply
5: Validation
error notification
OK Is transaction
authorized?
Central
Central
Bank
Bank
OK
OK
OK
OK
KO Validation
OK
Possible
to settle
now?
8: Authorization
rejection
KO
KO
9: Settlement
delay notification
11: REPO
transaction
KO
KO
10: Settlement
delay notification
Waiting
for
settlement
12: Debit confirmation
OK
13: REPO
transaction
15: Settlement
notification
14: Credit confirmation
End-of-day
cancellation
16: Cancellation
notification
17: Cancellation
notification
Business scheme description
The Participant issues the request for REPO operation to RTGS. RTGS
checks the syntax of this message and routes this message to the MDSRC
(Step 1),
The MDSRC validates the Participant’s request and notifies this
Participant about the result of the validation. Again, to do this, the
MDSRC sends message to RTGS, and RTGS routes the message to the
related Participant (Step 2 or Step 3),
The MDSRC blocks the securities that should be involved with the REPO
operation and issues the corresponding REPO transaction to RTGS (Step
PSD
Page 132
Version 06.01.01
Block
Securities
2: Collateral rejection
KO
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
4). As a rule, the REPO transactions have a higher priority levels than
ordinary payment orders,
RTGS accepts this REPO transaction and validates it. Error notification is
issued in case unsuccessful validation (Step 5),
Authorization request is sent to the Central Bank Monetary Operations
Domain (Step 6). The authorization reply (Step 7) is returned as the
answer. If the transaction is not authorized, the authorization rejection is
sent to MDSRC and related REPO transaction is cancelled (Step 8),
If the authorization is made RTGS tries to settle REPO transaction. The
Participant, Central Bank and the MDSRC application are notified about
the settlement of the REPO transaction (Steps 9-15),
At the end-of-day RTGS automatically cancel all REPO transactions
remain unsettled to the next day processing (it may happen in exceptional
situations only, Steps 16-17).
Table of messages in the scheme
Sequential number of SWIFT message
Name of message at the diagram
message at the
type
diagrams
1
MTn98
Request for REPO
2
MTn98
Collateral rejection notice
3
MTn98
Collateral information ACK
notice
4
MT202
REPO transaction
5
MT296/ERROR
Validation Error notification
6
MT296/AUTH
Authorization request
7
MT295/AUTH
Authorization reply
8
MT296/ERROR
Authorization rejection
9, 10
MT296/WAIT
Settlement Delay notification
11
MT202
REPO transaction
12
MT900
Debit confirmation
13
MT202
REPO transaction
14
MT910
Credit confirmation
15
MT296/SETL
Settlement notification
16, 17
MT296/CANC
Cancellation notification
Note bere. REPO operations shall be prepared by MDSRC system
automatically or manually.
PSD
Page 133
Version 06.01.01
Central Bank of Oman
Appendix 8
(Buy-back operations) Request for Buy-Back
transaction initiated by Participant
PartA
Liquidity
Department
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
RTS/X
MDSRC
1: Request for buy-back
KO
KO
2: Buy-back
rejection
Validation
OK
OK
3: Buy-back notification ACK
4: Buy-back transaction
7: Authorization
reply
OK
OK
KO
Validation
5: Validation Error
Notification
8: Authorization
rejection
Validation
KO
OK Possible
Central
Bank
to settle
now?
KO
9: Settlement
delay notification
OK
11: Buy-back transaction
OK
12: Debit confirmation
OK
13: Buy-back transaction
OK
14: Credit confirmation
KO
KO
10: Settlement
delay notification
Waiting
for
settlement
End-of-day
cancellation
OK
16: Cancellation
notification
15: Settlement
Notification
17: Cancellation
notification
OK
Buy-back settlement:
Securities leg
6: Authorization
request
Business scheme description
1. Any Participant may issue a request for a Buy-back operation to
RTGS (Step 1). This request is validated by RTGS and routed to
MDSRC for further validation and processing. RTGS optionally
may perform re-conciliation with REPO operation and rejects a
Buy-Back request if corresponding REPO operation was not found
in RTGS database (“REPO re-conciliation” process),
2. In case of a validation error, the Participants receive “technical
rejection” answer with an error description (Steps 2),
3. Otherwise, MDSRC acknowledges Buy-Back request (Step 3) and
issues a corresponding Buy-back instruction to RTGS (Step 4),
4. RTGS accepts this payment order and validates it. Error
notification is issued in case unsuccessful validation (Step 5),
5. Authorization request is sent to the Monetary Operations Domain
(Step 6). The authorization reply (Step 7) is returned as the answer.
If the transaction is not authorized, the authorization rejection is
sent to MDSRC (Step 8),
PSD
Page 134
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
6. If the authorization is made RTGS tries to settle Buy-Back
transaction. As a rule, the Buy-Back transactions have a higher
priority levels than ordinary payment orders (Steps 9-14),
7. Buy-Back operations remain unsettled at the end-of-day are
moving to the next day with appropriate notifications sent to
parties involved (Steps 15-16),
8. It is the responsibility of MDSRC to perform Overnights (or
perform other operations accordingly to pre-defined arrangements)
if some of REPO operations are not returned by related Buy-backs
due to lack of funds on Participant’s Settlement account or any
other reasons.
Table of messages in the scheme
Sequential number
of message in the
diagram
1
PSD
SWIFT
message type
Name of message in the diagram
MTn98
Request for Buy-Back
2
MTn98
Buy-back rejection
3
MTn98
Buy-back notification ACK
4
MT202
Buy-back transaction
5
MT296/ERROR
Validation Error notification
6
MT296/AUTH
Authorization request
7
MT295/AUTH
Authorization reply
8
MT296/ERROR
Authorization rejection
9, 10
MT296/WAIT
Settlement Delay notification
11
MTn98
Buy-back transaction
12
MT900
Debit confirmation
13
14
15
16,17
MTn98
MT910
MT296
MT296/CANC
Buy-back transaction
Credit Confirmation
Settlement notification
Cancellation notification
Page 135
Version 06.01.01
Central Bank of Oman
Appendix 9
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Automated request for Buy-Back operation sent by
RTGS to MDSRC
PartA
RTS/X
MDSRC
Automated
Buy-Back
requests
Liquidity
department
1: Request for buy-back
2: Buy-back transaction
OK
4: Authorization
request
KO
KO
3: Validation Error
Notification
Validation
5: Authorization
reply
Validation
KO
KO
6: Authorization
rejection
OK
Central
Bank
KO
KO
7: Settlement
delay notification
OK
9: Buy-back transaction
OK
10: Debit confirmation
OK
11: Buy-back transaction
OK
12: Credit confirmation
KO
Possible
to settle
now?
KO
Waiting
for
settlement
8: Settlement
delay notification
End-of-day
cancellation
OK
13: Settlement
Notification
OK
Buy-back settlement:
Securities leg
OK
15: Cancellation
notification
14: Cancellation
notification
Business scheme description
At the end of day RTGS issues a request for Buy-Back operations for any
REPO operation remain “unbuy-backed” to MDSRC. MDSRC then
issues to RTSX a Buy-back transfer (operation) for each REPO and
RTSX tries to settle these transactions after receiving the authorization
from Monetary Operations Domain,
It is the responsibility of MDSRC to perform Overnights (or perform
other operations accordingly to pre-defined arrangements) if some of
REPO operations are not returned by related Buy-backs due to lack of
funds on Participant’s Settlement account or any other reasons.
Table of messages in the scheme
Sequential number of SWIFT
message in the
message type
diagram
1
MTn99
2
MT202
3
MT296/ERRO
PSD
Page 136
Name of message in the diagram
Request for Buy-Back
Buy-back transaction
Validation Error notification
Version 06.01.01
Central Bank of Oman
Sequential number of
message in the
diagram
4
5
6
7, 8
9
10
11
12
13
14,15
PSD
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
SWIFT
message type
R
MT296/AUTH
MT295/AUTH
MT296/ERRO
R
MT296/WAIT
MTn98
MT900
MTn98
MT910
MT296
MT296/CANC
Page 137
Name of message in the diagram
Authorization request
Authorization reply
Authorization rejection
Settlement Delay notification
Buy-back transaction
Debit confirmation
Buy-back transaction
Credit Confirmation
Settlement notification
Cancellation notification
Version 06.01.01
Central Bank of Oman
Appendix 10
Ref
1.
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Glossary of Terms
Term
Definition
ACK/NAK
This message confirms that the system has
received a message from a participant and
that the system has accepted (ACK) or
rejected (NAK) the message.
2.
Administrator/System
Administrator
A user role established in the RTGS with
responsibility to perform all daily
maintenance
of
system
parameters,
participant
/user/account
information,
business rules in order to suit operational
requirements of the RTGS participants.
3.
Automated
Buy-Back
(REPO Rollover)
The period in which the system generates
reports on settlement accounts of the
participants that are outstanding i.e. not
bought back. Also refer to Section 3.2 under
Description of the periods of a Business Day
4.
Available balance
5.
Available funds
6.
Bank identifier code (BIC)
The balance of a settlement account which is
available for use by a debit instruction, and
in which the amount blocked by queued
payment has already been excluded..
Funds available for transfer or withdrawal in
cash.
A universal method of identifying financial
institutions in order to facilitate the
automated processing of telecommunication
messages in financial environments.
7.
BankNet
PSD
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
Page 138
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Term
Ref
Definition
information
subscribers.
electronically
amongst
the
8.
Business Cycle
Refer to Rule 3 Section 3.1
9.
Cancellation/cancelled
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
RTGS system operator.
10.
Central Bank
The Central Bank of Oman
11.
Clearing house
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.
12.
Clearing system
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).
Clearing/clearance
The process of transmitting, reconciling and,
in some cases, confirming payment orders or
security transfer instructions prior to
settlement, possibly including the netting of
instructions and the establishment of final
positions for settlement.
Collateral
An asset that is delivered by the collateral
provider to secure an obligation to the
collateral taker. Collateral arrangements
may take different legal forms; collateral
may be obtained using the method of title
13.
PSD
Page 139
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Term
Ref
Definition
transfer or pledge.
14.
Credit transfer
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.
15.
Customer
A private person or an institution, on whose
behalf (ordering customer) or in whose
favor (beneficiary customer), a payment is
effected.
16.
Customer payment
A payment where the originator or the final
beneficiary, or both, are not financial
institutions.
17.
Daily processing
The complete cycle of payment settlement
processing tasks which needs to be
completed in a typical business day, from
start-of-day procedures to end-of-day
procedures, including the backing-up of
data.
18.
Daily settlement
Completion of settlement on the day of
value of all payments accepted for
settlement.
19.
Default
Failure to complete a funds or securities
transfer according to its terms for reasons
that are not technical or temporary, usually
as a result of bankruptcy. Default is usually
PSD
Page 140
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Term
Ref
Definition
distinguished from a “failed transaction”.
20.
Deletion
21.
Delivery
(DvP)
22.
Depository
An agent with the primary role of recording
securities either physically or electronically
and keeping records of the ownership of
these securities.
23.
Digital signature
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.
24.
Direct participant
A participant who is responsible to the
settlement agent (Central Bank of Oman)
for the settlement of its own payments, those
of its customers, The participant has direct
physical connection and settlement account
in the RTGS system.
25.
Encryption
The use of cryptographic algorithms to
encode clear text data (plaintext) into cipher
text to prevent unauthorized observation.
26.
Exchange
Period
Interbank Payments
PSD
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. See also unwinding.
versus
payment
for
A link between a securities transfer system
and a funds transfer system that ensures
that delivery occurs if, and only if, payment
occurs.
The period in which the participants can
only exchange interbanks payments i.e. MT
202 Al
f
t S ti
32
d
Page 141
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Term
Ref
Definition
202. Also refer to Section 3.2 under
Description of the periods of a Business Day
27.
Exchange
Periods
for
Customer and Interbank
Payments (Including Repo)
The periods in which the participants can
exchange their interbank transfers and
transfers of their customers and enter into
Repo transaction. Also refer to Section 3.2
under Description of the periods of a
Business Day
28.
Exchange
Periods
for
Cutomers and Interbank
Payments (Excluding Repo)
The periods in which the participants can
exchange their interbank transfers and
transfers of their customers but cannot
request a Repo. Also refer to Section 3.2
under Description of the periods of a
Business Day
29.
Failed transaction
A transaction which does not settle on the
contractual settlement date.
30.
Field
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
PSD
Page 142
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Term
Definition
Ref
31.
Final
Irrevocable and unconditional.
32.
Final settlement
Settlement which is irrevocable and
unconditional. The discharge of an
obligation by a transfer of funds that have
become irrevocable and unconditional.
33.
Finality
Settlements in payment systems which are
both unconditional and irrevocable are
designated as final.
34.
Financial institution
An organization primarily established to
offer and perform services specifically
related to the provision of financial
(monetary) services.
35.
Financial liability
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.
36.
Format
The rules of layout, e. g, for a message type
or field within a message type.
37.
Format checking
That part of the processing which checks
that a message format conforms to the
message type rules.
The checks include, among others:
PSD
•
presence of mandatory fields
•
absence of forbidden fields
•
field length restrictions
•
character restrictions
Page 143
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Term
Definition
Ref
38.
General Ledger
This refers to the General Ledger
Accounting system of Central Bank in
which the participants settlement accounts
are maintained as a sub-ledger.
39.
Gridlock
A situation that can arise in the RTGS in
which the failure of some transfer
instructions to be executed (because the
necessary funds or securities balances are
unavailable) prevents a substantial number
of other instructions from other participants
from being executed. See also Failed
transaction, queuing, and systemic risk.
40.
Indirect participant
Indirect participants are distinguished from
direct participants by their inability to
perform some of the system activities (e.g.
inputting of transfer orders, settlement)
performed by direct participants. Indirect
participants thus require the services of
direct participants to perform those
activities on their behalf. In RTGS context
the term refers more specifically to
participants in a transfer system which are
responsible only to their direct participants
for settling the payments input into the
system (see also direct participant)).
41.
Intraday liquidity
Funds that can be accessed during the
business day, usually to enable financial
institutions to make payments in real time.
42.
Key
A unique series of digits used in
combination
with
a
cryptographic
algorithm.
43.
Key length
The
PSD
Page 144
number
ti k
of
bits
comprising
Version 06.01.01
an
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Term
Ref
Definition
encryption key.
44.
Key management
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.
45.
Liability
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.
46.
Monetary
Domain
47.
Liquidity risk
PSD
Operations
An entity in the RTGS system which is
responsible for processing the request of
intraday and overnight liquidity request
from participants. It validates the
participant request and authorizes injection
of liquidity to the settlement account of the
participant such that the participants
payment can be settled timely and mobility
of funds is maintained in the RTGS system.
In the operating environment of CBO
RTGS system, Treasury Market Operations
Department (TMOD) of CBO is assigned
the role of the Monetary Operations
Domain.
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
Page 145
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Term
Ref
Definition
some unspecified time thereafter.
48.
MDSRC
Muscat
Depository
Registration Center
49.
Message type (MT)
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).
and
Securities
There is a set of rules for each message type.
50.
Net credit (or net debit)
position
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).
51.
Net settlement
The settlement of a number of obligations or
transfers between or among counterparties
on a net basis. See also Netting.
52.
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
PSD
Page 146
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Term
Ref
Definition
default by a participant (see also multilateral
netting).
53.
Obligation
A duty imposed by contract or law.
54.
Participant
A party that participate in the settlement
activities operated by the RTGS system. See
also Direct Participant, Indirect Participant.
55.
Payment
The payer’s transfer of a monetary claim on
a party acceptable to the payee. Typically,
claims take the form of banknotes or deposit
balances held at payee’s bank.
56.
Payment instrument
Any instrument enabling the holder/user to
transfer funds.
57.
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.
58.
Payment system
A payment system consists of a set of
instruments, banking procedures and,
typically, interbank funds transfer systems
that ensure the circulation of money.
59.
Protocol
Procedures for the interchange of electronic
messages between communicating devices.
60.
Queuing
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
PSD
Page 147
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Term
Ref
Definition
lines or available collateral. See also Caps.
61.
Receiver
The participant receiving a message as
identified by its registered address in the
header of the message.
62.
Reference Documents
Refer to Rule 1 Section 1.8
63.
Repurchase agreement
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. Also called a repo.
64.
Request
Message sent to RTGS to receive answer on
status of the transfer, account, etc. Text
messages in RTGS are also process as
requests.
65.
RTGS
Real Time Gross Settlement System
66.
RTGS
System/RTGS
67.
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 payment system or through
correspondent banking relationships.
68.
Sender
The party sending a message as identified
b it
i t d dd
i th h d
f th
PSD
Payment
Refer to Rule 1 Section 1.2
Page 148
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Term
Ref
Definition
by its registered address in the header of the
message.
69.
Sending bank
See Sender.
70.
Sequence number
A number attributed sequentially to a
message and attached to it to prevent the
duplication or loss of messages.
71.
Server
A computer that provides services through a
network to other computers.
72.
Service bureau
A type of institution type which is defined in
RTGS system to offer services of
sending/receiving payment orders on behalf
of participants that have temporarily lost
electronic delivery channel to the RTGS
system..
73.
Session key
A cryptographic key which is used for a
limited
time,
such
as
a
single
communication session or transaction, then
discarded.
74.
Settlement
The actual fulfillment of the payment order,
i.e. the transfer of the payment from the
sender bank to the receiver bank is called
settlement. This transfer is carried out via a
central counterparty. It releases the debtor
from his/her payment obligation.
75.
Settlement account
An account held by a direct participant in a
CBO RTGS system for the purpose of
processing payments.
76.
Settlement date
The date on which the parties to funds
transfer transaction agree that settlement is
to take place. The intended date is
PSD
Page 149
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Term
Ref
Definition
sometimes referred to as the contractual
settlement date.
77.
Settlement risk
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,
78.
Settlement system
A system used to facilitate the settlement of
transfers of funds or financial instruments.
79.
Subfield
A data element which constitutes the
smallest indivisible unit within a field
consisting of more than one data element. A
group of two or more subfields constitutes a
field.
80.
Systemic risk
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 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.
81.
Tag
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.
82.
TCP/IP
Transmission control protocol/internet
protocol: a set of commonly used
communications and addressing protocols;
TCP/IP is the facto set of communications
PSD
Page 150
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Term
Ref
Definition
standards of the internet.
83.
Text (text block)
The part of a message which is enclosed
between the header and the trailer.
84.
Text message
Free format message (MTn99). In RTGS
text messages are also used for proprietary
requests and reports.
85.
Time stamp
A value inserted in a message to indicate the
time at which the message was created.
86.
Transaction
Number
87.
Transfer
88.
Unsettled
Cancellation
89.
Value Date
PSD
Reference
This field specifies the reference assigned by
the Sender to unambiguously identify the
message.
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.
Payment
The period in which all unsettled payments,
which are queued in the RTGS System, shall
be automatically cancelled.
Day on which a payment is due to be
credited to the receiving participant in the
payment system.
Page 151
Version 06.01.01
Central Bank of Oman
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Term
Definition
Ref
90.
Value date
The date on which funds are at the disposal
of the Receiver. See also Day of Value,
Settlement date
91.
XML
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 152
Version 06.01.01
Central Bank of Oman
Appendix 11
‫اﻟـﺒـــــﻨﻚ اﻟﻤـــﺮآــــﺰي اﻟﻌﻤـــــــﺎﻧﻲ‬
Contacts Details
Designation
Manager Payment Systems Department
In-Charge, RTGS Section
RTGS Section Team
Number
24779021
24702222 Ext 2022
24702222 Ext 2027
24701688
24700102
24702222 Ext 2024, 2025, 2026
Fax: 24781842
Email: rtgs@cbo-oman.org
PSD
Page 153
Version 06.01.01