RTGS- MERITS AND DEMERITS TO THE RETAIL BANKER

By

MEGHA AAKARAM GORULE

UNDERTAKING LETTER

I declare that project work entitled “RTGS- MERITS AND DEMERITS TO THE RETAIL

BANKER” is my own work conducted as part of my syllabus.

I further declare that project work presented has been prepared personally by me and it is

not sourced from any outside agency. I understand that, any such malpractice will have very

serious consequence and my admission to the program will be cancelled without any refund

of fees. I am also aware that, I may face legal action, if I follow such malpractice.

1
__________________________
Signature of Candidate

Table of content

Serial No Topics Page No

1 Introduction 4
2 Terminology 5
3 Management of the RTGS System 7
4 Membership 9
5 RTGS Transaction Type and Message Formats 12
6 Components, Communication and Settlement 13

2
 7 RTGS Business Day and Operating Sessions 16
8 Intra-day Liquidity (IDL) Facility 19
9 Features of RTGS System 22
10 Merits & Demerits of RTGS to the Retail Banker 31
11 Rights of Members / Participants 34
12 Customer Transactions – Obligations and Rights of Members / Participants 35
13 MNSB Settlement and Clearing House Participants 38
14 Obligations and Duties of Members / Participants 40
15 Sub-Membership in RTGS System 42
16 Dispute Resolution and Miscellaneous 44
17 Important Implications for the working of the RTGS system 45
18 Disclosures 49
19 Conclusion 49
20 Annex 1: Channel Codes for UTR/Transaction identification 51
21 Annex 2: Codes on Message Validation (RTGS) 52
22 Annex 3: List of TTC Values and Priority for RTGS System 53
23 Annex 4: Cut-off Times in the RTGS System at RBI 54
24 Annex 5: RTGS Threshold Value and Maximum Service Charges for Customers 55
25 Annex 6 : RTGS Service Charges for Members 56
26 About RTGS 57
27 Bibliography 60

1.Introduction

1.1 Whereas in the advent of new technology, it is necessary and expedient to set up the new
Real Time Gross Settlement (RTGS) system for facilitating on-line real time settlement of
payments, the Reserve Bank of India (RBI) has decided to setup a new RTGS system and frame
regulations for matters connected therewith or incidental thereto.

3
1.2 Short title and commencement:-

(1)These Regulations may be called the RTGS System Regulations, 2013.

(2) They shall come into force from the date of their Notification under the Payment and
Settlement Systems Act, 2007 and Payment and Settlement Systems Regulations 2008. The
RTGS (Membership) Business Operating Guidelines, 2004 and RTGS (Membership)
Regulations, 2004 shall be ceased to exist from the date of notifying the RTGS System
Regulations, 2013. The existing participant of the old RTGS system shall continue to be
members of the RTGS System 2013 unless otherwise specified.

(3) The acronym “RTGS” Stands For ‘Real Time Gross Settlement’. RTGS is a funds transfer system
where money is moved from one bank to another in ‘real-time’, and on gross basis. When using the
banking method, RTGS is the fastest possible way to transfer money. ‘Real-time’ means that the payment
transaction isn’t subject to any waiting period. The transaction will be completed as soon as the
processing is done, and gross settlement means that the money transfer is completed on a one to one basis
without clustering with another transaction. The transaction is treated as final and irrevocable as the
money transfer occurs in the books of the RBI (Reserve Bank of India). This system is maintained by the
RBI, and is available during working days for a given number of hours. Banks using RTGS need to have
Core banking to be able to initiate RTGS.

4
 2.Terminology:

I. 'Access Criteria for payment systems' means a set of criteria / norms issued by RBI from
time to time to allow a member to access the Payment Systems.

II. ‘Ancillary Payment System’ means a payment system operated by RBI or any Clearing
Entities. For example, paper (MICR / Non-MICR) clearing managed by RBI or other
banks, NEFT, NECS, CCIL and NPCI operated systems and systems operated by SEBI
regulated clearing entities, etc.

III. 'Bank' means the Reserve Bank of India.

IV. 'Central System' means the hardware and software installed in a central location hosting
RTGS application to process and to settle the funds transfer requests received from the
members. The Central System will be operated and managed by the Bank.

V. 'Centralised Payment System' means and include Real Time Gross Settlement (RTGS)
System, National Electronic Fund Transfer (NEFT) System and National Electronic
Clearing Services (NECS) and any other system as may be decided by RBI from time to
time.

VI. 'Customer transaction' means a funds transfer originated or received by a member on

behalf of its customer.

VII. ‘E-Kuber’ means Core Banking Solution of the Bank maintaining current accounts of the
banks, Governments and other institutions / entities.

VIII. 'Host system' means members own system like Core Banking Solution (CBS) system or
similar kind of application.

IX. ‘INFINET’ means the Indian Financial Network, the communication backbone.

5
 X. 'Inter-institutional transaction' means a funds transfer between two RTGS System
members / participants.

XI. 'Interface' means the utility (software application) which helps to interact between
member’s host system and Member Interface of the RTGS System, 2013.

XII. 'Intra-day Liquidity (IDL)' means the liquidity support provided by the Bank during a
RTGS business day to the members against eligible collateral.

XIII. 'Member' means an entity admitted by the Bank to access the RTGS System.

XIV. 'Member Interface (MI)' means the hardware and software component installed at the
member’s/participant's end connecting with the Central System.

XV. 'Multilateral Net Settlement Batch (MNSB)' means a settlement file containing the net
funds positions (receivable / payable) of clearing members emanating from various
payment systems having current account / settlement account with RBI.

XVI. 'Own Account Transfer' means transfer of funds between member's current account and
settlement account maintained with the Bank.

XVII. ‘RTGS’ system means system which facilitates on-line real time settlement of payments
either on gross basis or through Multilateral Settlement Batches, received from the
members.

XVIII. 'Settlement Account' means an account opened with the Bank by members of RTGS to
facilitate settlement of transactions.

XIX. ‘SFMS’ means the Structured Financial Messaging Solution provided by IDRBT.
XX. ‘SWIFT’ means the messaging system provided by the Society for Worldwide Interbank
Financial Telecommunication.

6
XXI. ‘System Operator’ means the Bank which will operate and manage the Central System.

XXII. ‘UTR Number/Transaction Identification’ means Unique Transaction Reference Number

that identifies a transaction uniquely.

3.Management of the RTGS System:

3.1 Operations of the RTGS System

3.1. The RTGS System will be operated by the Bank under the supervision of the Regional
Director, Reserve Bank of India, Mumbai Regional Office, Shahid Bhagat Singh Marg, Fort,
Mumbai 400 001.

3.2 Governance: Constitution of Standing Committee

The Bank shall constitute a Standing Committee for the management of the RTGS system. The
Standing Committee shall consist of the following members, namely:

a) A President;

b) A representative each from

(i) Department of Payment and Settlement Systems (DPSS);
(ii) Department of Information Technology (DIT);
(iii) Department of Government and Bank Accounts (DGBA);
(iv) Internal Debt Management Department (IDMD);
(v) Financial Markets Department (FMD);
(vi) Department of Banking Operations and Development (DBOD);
(vii)Legal Department (LD) and any other Department of the Bank.

c) A member representing State Bank of India and its associate banks.

d) Two members representing all the nationalised banks as a distinct group.

e) One member each representing

• All foreign banks as a distinct group
• All private banks as a distinct group
• All banks, other than those mentioned above, as a distinct group
• All Primary Dealers as a distinct group
• clearing houses like CCIL and NPCI

7
 • SEBI approved entities permitted to access RTGS system
• Any other distinct group as approved by the Standing Committee

3.3. The President shall be the Regional Director, Reserve Bank of India, Mumbai or such other
authority from the Bank, as may be nominated by the Bank, from time to time. The secretarial
assistance to the Standing Committee will be provided by the office of the President.

3.4 Tenure of members: The tenure of members from distinct bank group, other than the Bank
shall be for 1 year and shall be substituted by another member of that distinct group each year.
The tenure of the representatives of the Bank shall be, as may be decided by the Bank, from time
to time.

Frequency of meeting:

3.5. The Standing Committee shall meet on a need based basis but at least once every year.

3.6. The Standing Committee shall take decisions by majority of the members present in a
meeting or by circulating among the members, the agenda items and the proposed resolutions, as
may be deemed fit and proper by the President of the Standing Committee.

a. The President of the Standing Committee shall convene and preside over the meetings of
the Standing Committee and arrange to furnish a copy of the decisions taken by the
Standing Committee to all members of RTGS System.
b. In the absence of the required quorum, the meeting shall stand adjourned and the
President shall have the power to re-convene the meeting at any time later either on the
same day or any other subsequent day.
c. Each member present shall have one vote.

3.7Functions of the Standing Committee:The functions of the Standing Committee shall

include the examination, clarification, and recommendation of proposals to DPSS Central Office
relating to:

(i) Such issues, as it may deem fit and proper for the smooth, satisfactory and proper
functioning of the RTGS System.
(ii) Suggestions made by the participants of the RTGS System, received at least seven days
before the meeting or if otherwise permitted by the Chair.
(iii) Such other matter as may be referred to it by the Reserve Bank of India.

4. Membership:

4.1. Membership of RTGS system shall be open to all the licensed banks and to any other
institution at the discretion of the Bank.

8
4.2. Any other clearing agency managed by RBI shall be a member of RTGS system.

4.3. Criteria for membership: The access to the RTGS System will be decided on the basis of
Access Criteria guidelines issued by the Bank. The membership type and the facilities for the
participants are decided as per the Access Criteria Bank at its discretion may amend the Access
Criteria guidelines from time to time. The Bank at its discretion may permit other entities
membership to RTGS.

4.4. Apart from Access Criteria guidelines, an entity has to comply with the other specific
requirements for access to the RTGS system:
i. Membership of the Indian Financial Network (INFINET) / SFMS / domestic SWIFT network.
ii. Maintain a current account with the Bank.
iii. Maintain a settlement account with the Bank.
iv. Maintain Subsidiary General Ledger (SGL) account with the Bank.
v. Any other additional requirements specified by the Bank.

4.5. An entity eligible under the Access Criteria guidelines for centralised payment systems viz.,
RTGS, NEFT and NECS has to apply for authorisation to access RTGS in the prescribed format
and required documents to the Chief General Manger, Reserve Bank of India, Department of
Payment and Settlement Systems (DPSS), 14th Floor, Central Office Building, Shahid Bhagat
Singh Marg, Fort, Mumbai – 400 001.

4.6. Authorisation to access the RTGS will be accorded / declined on the basis of the
recommendation of Inter-Departmental Group (IDG) constituted by the Bank for Access Criteria.
The same will be communicated to the entity. The approval letter will indicate the type of
membership, types of transactions and facilities available, etc. The decline letter will indicate the
reason(s) for which the membership has not been considered. After the approval of RTGS
membership, the entity will be able to access RTGS system on completion of necessary
documentation and operational clearances from the Regional Director, Reserve Bank of India,
Mumbai Office, Main Building, Shahid Bhagat Singh Marg, Fort, and Mumbai 400001.

9
4.7. The RTGS members have to get prior approval of the Bank for any change or revision in the
process or any terms and conditions for participating in the RTGS system. In such cases, the
member has to submit necessary application and documents to the Regional Director, Reserve
Bank of India, Mumbai Office, Main Building, Fort, Mumbai 400001. The application has to be
made in the form and format available in the public domain (circular RBI / 2011-12 / 193
[DPSS.CO.OD.494 / 04.04.009 / 2011-2012] dated September 21, 2011), subject to change as
may deem fit by the Bank from time to time.

4.8 Type of Membership:The types of participants in the RTGS system primarily are of four
types viz., (i) Central bank – exclusively for RBI (ii) Regular participant – all types of facilities
to be provided (e.g. banks), (iii) Restricted participant – some particular type(s) of facilities to be
provided (e.g. Primary Dealers) and (iv) Clearing house – permitted to submit MNSB file to
RTGS system.

4.9. The existing RTGS participants will be mapped to the new RTGS system as follows:

Sr. Membership
Broad Category Facilities available
No. Type
IDL, inter-bank, customer transactions,
1 Type A Regular Participant
own account transfer
2 Type B Restricted Participant IDL, inter-bank, own account transfer
Gross transaction, MNSB, any other
3 Type C Clearing House transactions / facilities approved by the
Bank.

Regular or Restricted Customer Transactions, Inter-bank,

4 Type D Participant or IDL/No IDL, Own Account Transfer,
clearing house Any other conditions applied by RBI
The facilities mentioned above are indicative. However, RBI has the right to change these
facilities for any particular participant, if necessary. RBI may define new membership types or
disable an existing membership type at any point of time.

10
4.10 Options for accessing RTGS System: The members have to opt for any of the three options
viz., thick-client, Web-API (through INFINET or any other approved network) and PO module.
The choice of options for connecting to the RTGS system is based on the volumes and business
requirements of a member:
a) Thick client interface/SFMS Member Interface: A Member has to own, install
and maintain the dedicated hardware and software connecting to the Central
System through the INFINET or any other approved network by the Bank.

b) Web service interface: The interface application needs to be developed by the

members as per the specification provided by the Bank. The Central System will
have to be connected through the INFINET or any other approved network by the
Bank. The necessary specifications and standards for developing the application
for web service have been made available on the RBI website.
(Hyperlink - http://www.rbi.org.in/Scripts/Bs_viewRTGS.aspx)

c) Payment Originator (PO) module: This mode of access is purely browser based.
Members can originate and receive payment transactions through INFINET / any
other network approved by the Bank. The participants having minimal volume of
RTGS transactions (daily average volume 100 or less) are permitted to use this
mode of access. RBI reserves the right to revise the average daily transaction limit
for accessing RTGS through PO module in future. The Bank shall issue specific
instructions to the participants for accessing RTGS system through public
internet.

4.11. A participant can access the Central System through one channel at a time, which is said to
be the primary channel. The preference has to be provided to the Bank for necessary
configuration at the Central System. Another access channel will work as a back-up channel and
participant has to inform the Bank mandatorily before switching to another channel.

11
5. RTGS Transaction Type and Message Formats

5.1. The RTGS System will process following types of transactions:

a. Inter-institutional / inter-bank transaction – Funds transfer purely between two RTGS

members / participants.

b. Customer transaction – Funds transfer / receipt on behalf of the customer of a RTGS

participant member.

c. Government transaction – Funds transfer/receipt on behalf of Government Accounts by a

participating member.

d. Multilateral Net Settlement Batch (MNSB) – The file containing net settlement position of
clearing participants of an ancillary payment system managed by a clearing house.

e. Delivery versus Payment (DvP) – A transaction involving funds in one leg against delivery of
securities on the other leg. (A securities settlement mechanism that links a securities transfer and
a funds transfer in such a way as to ensure that delivery occurs if and only if the corresponding
payment occurs.)

f. Own Account Transfer (OAT) – Transfer of funds by a member between RTGS settlement
account and the current account maintained with the Bank.

g. Return Payment Transaction – Credit transfer received by a participant through RTGS that
could not be credited to an account specified in the message to be returned to sending member.

5.1.1. The standard message formats for the above transaction types along with major validation
rules.

5.2. The Bank has right to introduce any other transaction types, if necessary in future.

12
6. Components, Communication and Settlement

6.1. Transaction Flow: Each member will communicate from their Member Interface to the
Central System through the INFINET or any other network permitted by the Bank. The
interactions between the Member Interface and the Central System will be through pre-defined
message format (ISO 20022) only. Every message will be digitally signed and encrypted for
ensuring security. The Institute for Development and Research in Banking Technology (IDRBT)
or any other institute as decided by the Bank will be the Certifying Authority (CA) for digital
certificates.

6.2. Unique Transaction Reference (UTR) / Transaction Identification Number: Each message
has to be assigned with a unique number and provided in the field Transaction Identification
<TxId>. The UTR Number is unique for a transaction in the RTGS system. The Unique
Transactions Reference (UTR) number is 22 characters length, which can be used for further
reference. The structure of the unique number is “XXXXRCYYYYMMDDnnnnnnnn” where
XXXX is IFSC (first 4 character) of sending participant, R represents RTGS system, C
represents channel of the transaction, YYYYMMDD represents year, month and date of the
transaction, nnnnnnnn denotes the sequence number. The list of channel codes is furnished in
the Annex 1.

6.3. Message Standard: The RTGS system will handle messages based on ISO 20022 standard.
Every payment message is validated for the presence of mandatory fields. All mandatory fields
are validated in accordance with the ISO 20022 message standards and the coding requirements
set by the Bank. The error codes are present in the message returned to the system of originating
member as prescribed by the Bank. A list of error code is provided in Annex 2.

6.4. Transaction Type Code (TTC): The RTGS system uses a Transaction Type Code (TTC) to
identify the type of individual payment messages that is allowed for the particular type of
payment transaction. The TTC values are in the range of “0000” to “9999”. The list of active

13
TTCs has been given in Annex 3. Participants can also check the list online with the web front-
end of RTGS application. TTC value shall be part of the message content. The Bank will have
the right to change the list of TTC values from time to time.

6.5. Priority: The members may assign a priority while processing a payment transaction at the
Member Interface before releasing the transaction to the Central System. The available range of
priority is from '01' to '99'. The lower the assigned number, the higher will be the priority.
The priorities from “01” to “10” are reserved for the RBI. Participants can use the priorities from
“11” to “99”. The transactions of the RBI are assigned with the highest priorities followed by the
MNSB transaction file and inter-bank. RBI may change the priority number allocation as and
when required with a due notification. In case a participant other than the RBI enters priority
number from 0 to 10, then the RTGS system will assign default priority number to the
transaction and settle the same.

6.6. Queuing: Payment messages received in the RTGS will be maintained in a logical payment
queue, pending settlement. The queue will be ordered by priority numbers of the transactions
and, within a priority number, by the time of receipt in the RTGS system. Transaction will be
taken up for settlement which is at the top of the payment queue. Members may cancel or re-
prioritise transactions that are awaiting settlement in the payment queue.

6.7. Settlement: A payment transaction is determined and settled when the Settlement Account
maintained with RBI of sending participant is debited and receiving participant is credited. On
settlement, the payment transaction will be treated as final and irrevocable.
6.8. Debit notification and Credit message: On successful settlement of any payment transaction
the sending participant receives a notification and receiving participant receives the full payment
message. The members accessing the RTGS system through the Thick Client/MI channel may
put in place necessary interfaces with their host systems using Straight Through Processing
(STP). The members accessing the RTGS system through Web and PO module should monitor
their transactions (both debit and credit) on a continuous basis.

14
6.9. Duplicate Handling: Participants have to choose the Copy Duplicate field tag in the
Business Header of the payment message and fill relevant mandatory fields for handling
duplicate transactions. If Copy Duplicate field tag is selected, the Central System will check
whether the transaction has already been processed or not. Accordingly, the transaction will be
processed by the Central System.

7. RTGS Business Day and Operating Sessions

7.1. The RTGS system will be operational on all days except specified holidays as decided by the
Bank from time to time. Any changes to the operating calendar or any declaration of unscheduled
holidays will be communicated to the participants by means of a broadcast message or
publication on the Bank's website or on both the mediums.

7.2. The business hours for the RTGS System will be decided by the Bank in consultation with
the stakeholder at the meetings of the Standing Committee. However, the Bank may, at its
discretion, change the hours of operation of the RTGS System for a particular day or for any
period with prior notification.

7.3. RTGS daily events

15
a) Start of Day (SOD): This is the first event which triggers basic functions of the system
viz., advancing of system’s business date; loading the updated code files; accepting
payment instructions from the internal systems of the Bank. Payments sent by the
participants are not accepted for settlement at the time of SOD. If submitted, the
payments are kept in the queues, waiting for the next event to be executed. To transfer
opening balances to settlement account from the participant’s current account maintained
in E-Kuber system (SOD balance transfer), a participant has to provide necessary
undertakings to the Regional Director, Reserve Bank of India, Mumbai Office, Main
Building, Fort, Mumbai 400001. The SOD balance transfer of existing RTGS participants
will be continued in the RTGS system as per the undertakings already submitted for this
purpose.

b) Open for Business (OFB): This event marks the moment when all the functionality of the
RTGS system is fully available to the participants. The system starts processing all types
of messages. Intra-day liquidity (IDL) facility will be available to the eligible participants
after Open for Business operation in the RTGS system.

c) Initial Cut-off (ICO): This event triggers restriction of submission of certain type of
transactions viz. customer transactions. After ICO time participants cannot submit the
customer transactions for settlement. Transactions submitted before ICO time pending for
settlement will not be cancelled. However, some specific types of transactions viz., inter-
institutional / inter-bank, return payments, MNSB, etc. will be accepted for settlement
after this cut-off.

d) Final Cut-off (FCO): This cut-off represents the end of all the normal operations
conducted by a participant for the business day, with the exception of those payments that
credit a participant with additional liquidity to repay the outstanding IDL loans. No
further IDL requests will be accepted after this point. Any other pending transactions will
be automatically cancelled by the RTGS system and the sending participants will be
notified accordingly.

16
 e) IDL Reversal Session: This session is available only to the participants having
outstanding IDL positions after Final Cut-off to receive funds from any other bank/own
account transfer purpose.

f) End of Day (EOD): This is the last event of every business day. There will either be
positive or zero balance in the settlement accounts. The balances of settlement accounts
will be swept back to the current accounts of respective banks maintained in E-Kuber.

7.4. MNSB files and MNSB Return files are permitted to be posted from the moment of Open
for Business and before End of Day of the RTGS system. The Bank may, at its discretion,
prescribe specific time windows for MNSB settlement from ancillary payment systems.

7.5. The Bank may permanently or temporarily change the timings of the various business phases
during the day at its discretion. The change in the hours will be notified by the Bank to the
participants through a broadcast message or publication on the Bank's website or both as decided
by the Bank.

7.6. Participants may request the Bank for time extension of any operating session. The request
for time extension should be sent one hour prior to the closing of that operating session to the
Regional Director, Reserve Bank of India, Mumbai Regional Office, Deposit Accounts
Department, Main Building, Shahid Bhagat Singh Road, Fort, Mumbai-400001. However, the
Bank reserves the right to decline such requests. Participants may note that the time windows
cannot be re-opened in the RTGS system once the cut-off for that session is already over. Further,
Bank will not be liable for any consequences, arising out of such extension of the operating
session for the RTGS members’ payments, whether queued or otherwise.

7.7. The cut-off timings of the RTGS system have been stated in the Annex 5. The Bank reserves
the right to change any operating session (either extend or shorten / compress the operating
session). The Bank shall not be liable for any consequences, arising out of such change of the
operating session.

17
7.8. Gridlock Resolution Mechanism: The system provides a gridlock resolution mechanism that
resolves (to the extent possible) all outstanding queued transactions. This resolution process is
automated and runs on a predefined time intervals for the urgent stream of payments in the
queue. The Bank is, however, in no way, obligated to settle queued transactions through this
mechanism and no member of the RTGS System can claim any right to have its payment
transactions settled through the gridlock resolution mechanism.

8.Intraday Liquidity (IDL) Facility

8.1. The Bank may, at its sole discretion, grant access to intra-day liquidity (IDL) facility to the
RTGS members for the settlement of their payment transactions in the RTGS to overcome short-
term requirements for funds (during the RTGS business day) for settlement of the transactions.
The terms and conditions, under which such IDL will be granted, may be amended from time to
time. The decision of the Bank in this regard shall be final.

8.2. The Bank will decide the eligibility criteria for IDL facility. RTGS members, eligible for
IDL facility, shall enter into an IDL Agreement with the Regional Director, Reserve Bank of
India, Mumbai in the prescribed format at the time of admission as an RTGS member. The IDL is
a repo facility and all terms and conditions of repo transactions shall be applicable accordingly.
The IDL will be provided to the RTGS members against eligible collateral.

18
8.3. The quantum of IDL, margin requirement and nature of collateral will be notified by the
Bank from time to time. The IDL facility will be provided to the eligible members against the
collateral of Government of India dated securities and treasury bills maintained in IDL-SGL
account as decided by the Bank from time to time.

8.4 The IDL facility will be invoked automatically for eligible participants as and when they do
not have the required funds in their settlement account for settlement of transactions. The IDL
facility will be invoked in the multiple of an amount decided by the Bank subject to a maximum
amount for which securities are earmarked in IDL-SGL account. The requests would be sent to
the Bank’s E-Kuber for eligible collateral. If eligible collaterals are not available then E-Kuber
shall decline the IDL requests. Further requests for IDL will be sent to the E-Kuber in a periodic
interval. However, the participants should ensure the availability of eligible collaterals with the
RBI and the lien for IDL facility to avoid repeated requests against the same IDL request. If such
instances are observed, the Bank shall view it seriously and may impose penalties at the
discretion of the Bank. The IDL will be reversed automatically as and when the required funds
are available in the settlement account of the participants. Bank has right to introduce upper limit
of number of IDL requests for a member.
8.5. The IDL funds shall be used by the RTGS system for the settlement of any transaction and
not just for the transaction for which the IDL was requested.

8.6. The IDL facility availed by a participant shall be automatically reversed by the RTGS
system on availability of sufficient funds in the settlement account of the participant above a
thresh hold level. The threshold level shall be set by the Bank at its discretion. The reversal of
IDL shall be treated as a high priority transaction. IDL that is outstanding on account of
insufficient fund in the settlement account is required to be repaid / reversed fully before the
RTGS End of Day phase by the participant. If an RTGS member fails to repay any IDL availed
of by it before the end of the business day, the securities against which such IDL has been
availed of and not repaid will get transferred to the Investment Account of the Bank. In such a
case, the participant will be liable to pay the Bank the interest at twice of the Repo Rate
prevailing on the particular day.

19
8.7. On the following business day, the member shall repurchase the securities within one hour of
RTGS start-of-day failing which the member will not have access to IDL facility till the
repurchase is completed. If the member does not repurchase the securities within the stipulated
period of time, the matter will be viewed seriously by the Bank and the member may be liable
for suspension from RTGS membership in addition to the imposition of additional penalties as
decided by the Bank.

8.8. The Bank may levy charges to a member for using IDL facility. The Bank may also, at its
sole discretion, change the manner in which IDL is charged. The Bank reserves the right to
withdraw the -IDL facility at any point of time and the decision of the Bank in this regard shall
be final.

8.9. Measures of intraday liquidity - On the basis of the four components discussed above, liquidity
as applied to the operation of RTGS systems may be measured both from an individual bank's
perspective and from a system perspective. From a bank's perspective, intraday liquidity may be
taken to be the bank's ability to settle a given value and number of transfers within a given time
constraint.

One way to characterise this concept would be to define so-called "net" intraday liquidity on the
basis of actual cash flows. As already noted, a bank's actual balance at the central bank at agiven
point in time during the day is determined by the starting balance as well as any payment
ormonetary activities and credit extensions that have taken place by that time. This actual
balance,however, may not necessarily represent the liquidity immediately available for the bank
to initiatenew outgoing transfers at that time, because some or all of the transfers that it has
already initiatedmay be queued within its internal system or in the centrally located queue. A
bank's net intradayliquidity, which may correspond more closely to its ability to settle its
outgoing transfers at a givenpoint in time, could be defined as the actual balance minus the value
of all pending transfers.

Alternatively, a bank's net intraday liquidity could be defined on the basis of the sum of actual
and potential cash flows. Such a concept has been adopted in some RTGS systems as a measure

20
of available liquidity, although in some other cases it has been felt that incorporating potential
cash flows may be too difficult. Potential cash flows refer to potential funds which a bank could
mobilise or use for cover. For example, a bank might include queued incoming transfers as a
source of liquidity that it expects to be available shortly for its own outgoing transfers. In this
case, a bank's net intraday liquidity is defined as the actual balance plus the value of queued
incoming transfers minus queued outgoing transfers. As potential sources of liquidity, a bank
might also include, for example, unused credit lines or liquid collateral.

9. Features of RTGS System

9.1. Hybrid feature: The RTGS system will have facility to settle transactions on a Gross and
off-setting basis (bilateral or multilateral offsetting) basis through its hybrid settlement features.
The cycle of offsetting will be notified from time to time by the Bank. The transactions will be
settled on a gross basis or liquidity optimization basis depending on priority of the messages in
the relevant field tag. The Bank may, at its sole discretion, implement this mechanism after due
notification to the members, subject to change from time to time.

9.2. Setting bilateral and multilateral limit: The Bank may set bilateral and multilateral counter
party limits at the request of the participants to discourage free riding on liquidity in the RTGS
system. The Bank has the right to implement this after due notification to the members, subject
to change from time to time.

21
9.3. Future value dated transactions: The RTGS system will accept future value dated
transactions from the participants for settlement on future RTGS working days. Such transactions
will be placed in the queue and shall be settled on the basis of value date of the transactions. The
Bank has the right to implement this after due notification to the members, subject to change
from time to time.

9.4. Centralised Anti Money Laundering Filtering: The RTGS system will validate payment
transactions with the negative list databases for AML / CFT as per the guidelines issued by the
Bank. The Bank has the right to implement this after due notification to the members.

9.5. Multicurrency: The RTGS system will process multicurrency transactions as per the
guidelines issued by the Bank from time to time. The Bank has the right to implement this after
due notification to the members.

9.6Payment processing:Within this broad definition, the operational design of RTGSsystems can
differ widely. In particular, important differences may arise in the approaches to payment
processing when the sending bank does not have sufficient covering funds in its central bank
account. One possible way of treating transfer orders in such circumstances is for the system to
reject the orders and return them to the sending bank. The rejected transfer orders will be input
into the system again at a later time when the sending bank has covering funds. Until that time,
sending banks may keep and control the pending transfers within their internal systems (internal
queues). Alternatively, the RTGS system may temporarily keep the transfer orders in its central
processor (system or centrallylocated queues) instead of rejecting them. In this case, the pending
transfers will be released for settlement when covering funds become available on the basis of
predefined rules, agreed between the system and the participating banks. In many cases the
transfer orders are processed and settled with the extension of centralbank credit, normally
provided for a period of less than one business day (intraday credit); in other words, the central
bank provides banks with the necessary coveringfunds at the time of processing by extending
such credit. The central bank could take a range of approaches to the provision of intraday credit
in terms of (a) the amount of credit (including a zero amount), (b) the method by which credit is
extended (e.g. overdraft or repo), (c) the terms on the credit (e.g. free or priced) and (d) the

22
collateral requirements (if any).These possibilities of payment processing (i.e. rejected, centrally
queued, and settled with central bank credit) are not necessarily mutually exclusive. For
example, when the provision of central bank credit is constrained in some way, the transfer
orders for which the sending bankcould/would not obtain central bank credit will be rejected or
centrally queued. In recent years, new orplanned RTGS systems have tended to apply a
combination of these possibilities rather than beingbased on only one form of payment
processing.

9.7 Ability to limit payment system risks:RTGS systems can contribute substantially to limiting
payment system risks. With their continuous intraday final transfer capability, RTGS systems are
able to minimize or even eliminate the basic interbank risks in the settlement process. More
specifically, RTGS can substantially reduce the duration of credit and liquidityexposures. To the
extent that sufficient covering funds are available at the time of processing, settlement lags will
approach zero and so the primary source of risks in interbank funds transfers can be eliminated.
Once settlement is effected, the receiving bank can credit the funds to its customers, use them for
its own settlement purposes in other settlement systems or use them in exchange for assets
immediately without facing the risk of the funds being revoked. This capability also implies that,
if an RTGS system were linked to other settlement systems, the real-time transfer of irrevocable
and unconditional funds from the RTGS system to the other systems would be possible. The use
of RTGS could therefore contribute to linking the settlement processes in different funds transfer
systems without the risk of payments being revoked. Importantly, RTGS systems can offer a
powerful mechanism for reducing systemic risk.As central banks have a common interest in
limiting systemic risk, this capability has often been the key motive for many central banks to
adopt RTGS in large-value transfer systems. The appeal of RTGS in terms of systemic risk
containment may be better understood by breaking it down into separate elements. First, the
substantial reduction of intraday interbank exposures could significantly lower the likelihood that
banks may become unable to absorb losses or liquidity shortfalls caused by the failure of a
participant in the system to settle its obligations. Second, RTGS precludes the possibility of
unwinding payments, which can be a significant source of systemic risk in net settlement
systems. Third, since banks can, in principle at least, make final funds transfers at the time of
their choice during the day, settlement pressures are not concentrated at particular points in time.

23
This makes it likely that banks will have more time to cope with problems (for example, a
liquidity or solvency problem of a participant in the system), possibly by raising alternative
funds or through the receipt of incoming transfers from other participants.

9.8 Intraday liquidity requirements:Provided that there are no legal problems with regard to
settlement finality, the only structural impediment to continuous intraday finality is any liquidity
constraint a sending bank may face during the day.A liquidity constraint in an RTGS
environment has two basic characteristics, namely that it is a continuous constraint for settling
funds transfers and that intraday liquidity requirements must be funded by central bank money;
banks must therefore have sufficient balances in their central bank accounts throughout the
processing day.Intraday liquidity requirements raise important issues for both the central bank
and the private sector. Central banks, for their part, face a choice as to whether or not to provide
banks with intraday liquidity and, if so, what form that provision will take (e.g. by what
mechanisms and on what terms the credit will be provided, and how any resulting exposures will
be managed).

9.9. Concepts of illiquidity. If net intraday liquidity is negative, the bank can be viewed as being
illiquid in the sense that it is unable to settle some or all of its queued outgoing transfers.
However, care needs to be taken in interpreting the concept of a bank's illiquidity. Although
transfers processed over an RTGS system have some degree of time-criticality, not all transfer
orders are time-critical in the sense that they must be settled either at or by a specific point in
time during the day or within a specified and limited interval of time during the day. Some funds
transfer orders may be time-critical only in a same-day sense even in an RTGS environment.
Time-criticality and intraday time constraints may be influenced by the nature of the transfers,
transaction pricing policy (see below) and rules relating to end-of-day closing procedures.
Accordingly, even if a bank becomes illiquid, it may be able to delay certain less time-critical
transfers in order to allow subsequent incoming transfers to provide the necessary liquidity. The
scope for such liquidity management will vary, and typically will narrow towards the end of the
day. In practice, therefore, for illiquidity to have a significant impact on a bank, it must occur
over some "significant" interval of time.

24
9.10. System liquidity and gridlock:From a system perspective, the concept of intradayliquidity
could be related to the "amount" of funds that enables the system to process transfers between all
or most of banks in a timely manner. However, it is more difficult to analyse system liquidity
because it is not simply the sum of each bank's net intraday liquidity as defined above. Whether
the system is liquid or not also depends crucially on the distribution (or concentration) of
liquidity among banks in relation to their payment needs. For instance, gridlock could be
characterised as a case of system illiquidity in which the failure of some transfers to be executed
prevents a substantial number of other transfers from other participating banks from being
executed. Of course, gridlocks could occur when the aggregate liquidity is insufficient, but they
might occur even if the liquidity in the system, taking into account all queued incoming and
outgoing transfers, was adequate overall but poorly distributed. Suppose two systems had the
same aggregate sum ofbank liquidity: one might be liquid while the other might be in gridlock if
liquidity was concentratedamong a few banks in that system. Because of this, some systems
provide banks with ways of breaking gridlock.

9.11. Management of intraday liquidity: an individual bank's perspective:- The need to have intraday
liquidity typically entails a positive cost for banks in the form of funding costs and/or
opportunity costs. Banks therefore have incentives to manage intraday liquidity by attempting to
minimize it subject to certain constraints. Constraints on intraday liquidity management vary
from system to system. In general, banks are likely to try to avoid undue delays in time-critical
transfers (both because of customer relations and on account of possible legal liabilities) as well
as to try to minimize end-of-day overdrafts or processing penalties.For these purposes, for
example, banks may hold precautionary balances to guard against urgent and unexpected
transfers. Reserve requirements could also be a constraint, particularly if the requirement has to
be met each day.

An optimal level of intraday liquidity for an individual bank may be determined by the balance
between the costs of obtaining or maintaining liquidity and the costs of delaying settlement. the
former (liquidity costs) may include direct funding costs, opportunity costs of maintaining funds
in the central bank accounts and opportunity costs of tying up collateral or securities for central
bank credit. The opportunity cost associated with collateral for obtaining intraday liquidity could

25
be relatively low if banks already hold the relevant types of asset in sufficient quantities, which
they might do as part of their portfolio strategy or for other reasons. Although it may not be easy
to measure in practice, from an analytical point of view the concept of "settlement-delay costs"
could be defined as the potential or actual economic costs incurred if the settlement of funds
transfer orders were delayed. The degree of settlement-delay cost in a particular. RTGS system
may depend on the time-criticality of the underlying transactions, transaction pricing policies as
described below and, more generally, market practices. Given the level of liquidity costs, banks
are likely to have stronger incentives to obtain or maintain intraday liquid funds as delaying
settlement becomes more costly.

With a given starting balance, banks may operate intraday by adjusting the use of intraday or
overnight credit, sequencing incoming and outgoing transfers or, in limited circumstances,
selling assets for same-day settlement. Of these possibilities, sequencing transfers is a way
ofcontrolling intraday payment flows by scheduling the timing of outgoing transfers according to
the supply of liquidity provided by incoming transfers. Importantly, to the extent that incoming
and outgoing transfers are successfully sequenced, it could generate virtual "offsetting effects"
on RTGS payments and hence contribute to substantially reducing the necessary liquidity. The
most common way of sequencing is to use queuing arrangements. Regardless of whether it is
centralized or decentralized, queuing allows banks to sequence transfers in a systematic way.

Another method of sequencing transfers may involve message codes indicating the time of day
that an individual outgoing transfer should be settled. Such time-of-day message codes may be
used to store transfer orders within the central processor in the system or within the internal
system of the sending bank. Time-of-day message codes might allow banks to better forecast
liquidity requirements by increasing the certainty of the timing of debits and credits associated
with transfer orders involving a standard time-lag between the transaction date and the settlement
date (e.g. securities and foreign exchange transactions), intraday and overnight loans and other
time-critical transfers such as those for the settlement of balances in net settlement systems.

Even if they attempt to coordinate incoming and outgoing transfers as closely as possible, banks
may still face several limitations in minimizing intraday liquidity requirements. First, as noted
above, if transfers are time-critical, that limits the extent to which banks can delay them. Second,

26
individual transfer orders are often very large. Breaking down a particularly large transfer into
two or more smaller amounts may facilitate sequencing, and in some RTGS systems this is
actually done as a standard means of liquidity management. Nevertheless, the resulting transfers
can still be large, which would make closer sequencing difficult. Third, banks cannot have
complete information about the transfers they are due to receive and send on that day, so that
they have to sequence transfers more or less on the basis of predictions.

9.12. Management of intraday liquidity: a system perspective : The management of intraday

liquidity from a system perspective may concern bothmanagement of the aggregate level of
liquidity relative to payment requirements in the system andmanagement of the distribution of
liquidity among banks. For the former purpose, the central bank may typically provide individual
banks with credit directly for settlement purposes or indirectly through monetary operations
according to its policy.

It is possible that the optimal liquidity management from an individual bank's perspective may
not necessarily be best for the system as a whole. As noted earlier, a bank may make a deliberate
attempt to delay the processing of transfers to economies on its own liquidity by relying on the
expected receipt of liquidity from others. To minimize the possible negative effects of such
behavior on system liquidity, RTGS systems sometimes incorporate mechanisms to discourage
"selfish" behavior and to encourage early processing and/or settlement of transfers. One way is to
lay down rules governing banks' outgoing payment flows, such as guidelines requiring banks to
send a certain proportion of their daily payment messages by specified times. Such a rule would
discourage banks from delaying transfers. However, it may be inappropriate in some cases; for
instance, some banks may have atypical intraday patterns of transfers, making it unrealistic for
them to observe such a rule. Or it may be that the rule is incompatible with the pattern of
transfers deriving from DVP or (future) PVP arrangements, where the timing of transfers is
critical. At the least, therefore, some flexibility may be needed in setting and applying such a rule

An alternative method may be to apply a transaction pricing policy that would encouragethe
early processing (input) and settlement of transfer orders. For instance, SIC applies a pricing
schedule for sending banks that penalises (i.e. sets a higher charge on) late input and settlement

27
of transfer orders, while the receiving bank is subject to a flat pricing schedule. This has led
banks to send and settle their bulk low-value payments as early as possible, ahead of large-value
funds transfers. Some proposed systems are also considering the possibility of adopting a pricing
policy that would set a higher charge on queued or late transfers (i.e. transfers that are entered
only shortly before the close of the system). Charging a penalty fee on the transfers that remain
unsettled at the end of the day could be used to complement such a transaction pricing policy

9.13.Monitoring system liquidity. Central banks (or system canters) are in many casesconcerned
with monitoring and managing liquidity in RTGS systems so as to maintain a smooth flow of
payments and to detect and prevent possible gridlocks. There are significant differences in
centralbanks' technical approaches to monitoring system liquidity. For example, the Bank of Italy
envisages an "indicator approach" to real-time monitoring whereby the central bank will pay
particular attention to synthetic indicators calculated on the basis of several key parameters such
as the total amount of liquidity available in the system, the volume of transfers entered into the
system and the volume of settled transactions. The indicators will be used to observe the queues and
intraday liquidity in thesystem as a whole and also to identify any potential gridlocks which may require
further investigationof an individual bank's net liquidity position. On the other hand, the Bank of France
will take a more"micro approach" whereby it will monitor in real time each bank's net intraday liquidity.
In contrast,the Swiss National Bank does not systematically monitor system liquidity in SIC. This reflects
itsview that monitoring liquidity is mainly the responsibility of participants and that there should be
nointervention by the central bank or the system in the centrally located FIFO queue.

9.14. Structural factors affecting liquidity requirements and management:There are various structural
factors that may affect liquidity requirements andmanagement in an RTGS system. First, the
number of participants may be of significance. Compared with a system with a larger number of
participants, an RTGS system with relatively fewer participants might internalise a greater
proportion of third-party payments and therefore have a lower level of interbank transfers sent
over the system; as a result, less intraday liquidity might be required at the system level to
process a given volume of payments. Such a system may also have more concentrated, offsetting
payment flows between banks and thus incoming transfers would be a relatively more important
source of liquidity. Furthermore, it might technically be less complicated for banks to monitor,
control and sequence payment flows in a system with relatively fewer participants.

28
Second, the relative market size (in terms of payment activity) or asset size of participants may
affect liquidity. An RTGS system with a mixture of large, medium and small participants may
have a different set of intraday liquidity requirements from a system consisting of participants of
broadly equal size. Larger banks, for instance, may have a more balanced intraday flow of
incoming and outgoing transfers, so that incoming transfers can provide the liquidity needed to
fund outgoing transfers, while smaller banks may process fewer transfers or tend to be net
senders/receivers of funds in the RTGS system. Larger banks may also find it easier to obtain
thenecessary liquidity if they have better access to funding and credit markets or a larger deposit
basethan smaller banks.
Third, participants' areas of specialisation may matter. If an RTGS system is composed of banks
that specialise in a variety of different market segments (such as merchant banking, credit card
transactions, deposit-taking, clearing activities, foreign exchange transactions and securities
transactions), payment flows and patterns and the resulting liquidity requirements may differ
from those in systems where participants tend to offer a more uniform range of products and
services.

Fourth, the structure of the payment systems and flows outside the RTGS system may affect
RTGS liquidity. Non-RTGS payments can be an important "exogenous" factor affecting bank's
RTGS liquidity. In practice, the mechanism through which non-RTGS payments influence RTGS
liquidity may take a variety of forms. Typically, net settlement obligations resulting from other
settlement systems (e.g. cheque clearing, other large-value transfer systems, ACH transactions
and securities settlement systems) are settled periodically over the RTGS system or at least
processed through the same central bank account as that on which the RTGS system relies for
intraday liquidity. In such circumstances where RTGS payments and the settlement of non-RTGS
payments are interrelated and "competing" uses of liquidity could therefore arise, banks may use
internal systems capable of integrating their RTGS and non-RTGS payment activities on an
intraday basis to manage their overall liquidity. At the same time, since the settlement of foreign
exchange transactions accounts for a substantial part of the total value handled by many RTGS
systems, existing or proposed netting arrangements for such transactions (e.g. FXNET, ECHO
and Multinet) may, by requiring only the net value of the transactions to be settled, also have an

29
effect on the value and timing of transactions, and consequently on the liquidity, in some RTGS
systems.

Fifth, the structure of central bank accounts may be an important factor influencing RTGS
liquidity. As the comparative table in Annex 1 shows, there are differences between G-10
countries in the way central bank accounts are organized. central bank accounts for RTGS may
be unified with or segregated from central bank accounts for other purposes, for example for
required reserves. Moreover, central bank accounts may be centralized (i.e. banks hold accounts
for making transfers at only one office of the central bank) or decentralized (i.e. they are
permitted to hold accounts at more than one office). One question is whether, under a
decentralized account structure, banks are able to monitor balances and shift them efficiently
between accounts on a real-time basis for liquiditypurposes. In general, the structure of central
bank accounts in a country is determined by a number ofdifferent considerations and therefore an
optimal account structure will not necessarily depend only on the settlement arrangements for
RTGS systems. However, in countries that have a decentralizedaccount structure and where
RTGS systems are operating or planned, there seems to be a broad tendency to
centralize/consolidate central bank accounts, or at least to centralize the arrangements for
processing the account data. This may suggest that a more centralized structure is sometimes a
more efficient and straightforward structure for an RTGS environment, in particular in terms of
liquidity management.

30
10.Merits of Real time Gross Settlement (RTGS)

 Due to elimination of time lag, the risk is greatly reduced.

 There is no credit settlement risk involved.
 It improves confidence of outside agencies like World Bank in Indian economy.
 It enables efficient settlements and avoids settlement delays.
 Customers can get new banking services based on reliable high value funds transfer

system.
 Most of the RTGS systems in place are secure and have been designed around

international standards and best practices.

 RTGS transactions involve large amounts of cash, basically only funds above Rs. 200,000

may be transferred using this system.

 Settlement is immediate.
 Payments are only effected if there are sufficient funds available.
 No maximum transfer amount limit.
 On weekdays (Monday to Friday) transactions are carried out from 9 AM to 4:30 PM.
 On Saturday, transactions can be made from 9 AM to 2 PM.
 The bank of the beneficiary has to credit his/her customer’s account within 30 minutes of

receiving the message of funds transfer.

 In case of a holiday, the amount gets credited on the next working day.
 RTGS could also be done offline by submission of the remittance form at the bank branch

of the remitter.
 RTGS avoids the cost involved in other instruments of fund transfer such as demand

draft.
 Transactions being settled on an individual basis (without netting), considerable time is

saved, thus acting as a catalyst for growth of commerce and industry.

 The coverage under the scheme is being widened progressively by bringing more and
more bank branches under the ambit of the system.

 Fund transfer through RTGS involves comparatively lower remittance charges. Inward

remittances are free of cost, while banks can charge a fee not exceeding Rs 30 for an

outward remittance on transaction amount of Rs 2lac-5lac. For higher amounts, banks

could charge a fee of Rs 55.

31
  Eliminates problem of debtors delaying their payments

 No more the anxious wait for a week or a fortnight, wondering if the instrument reached

safely and was duly realized.

 Reduces the cost of exchanging goods & Services.

 No geographical limitations within India as long as it is participating bank in RBI’s

RTGS system.

Thus, RTGS is a safe and secure fund transfer mechanism and avoids risk of loss associated with
cheques and demand draft that are used for fund transfer.

10.2 Demerits of Real time Gross Settlement (RTGS)

 It is more expensive to settle payments in this way. Therefore, RTGS payments tend to be

reserved for urgent transactions or very large ones when it is important to get same-day

value.
 It can create an exposure for the central bank, although this does not affect corporates

directly
 RTGS covers only large value transactions (Rs. 2 lakh and above).
 Not available on 24 hour basis. Does not work at night and on public / bank holidays
 A large number of bank branches are yet to be brought under the scheme.

11. Rights of Members / Participants

32
11.1. Participants / members are eligible to send / receive transactions to / from the central
system during the business hours as approved by the Bank.

11.2. Participants / members have right to contact RTGS Helpdesk set up by the Bank for
necessary assistance for RTGS operations.

11.3. Participants / members have right to make complaints / give feedback to the Bank on
technical / business issues with regard to the RTGS System. Such issues may be brought to the
notice of the Bank for further discussion in the Standing Committee.

11.4. Participants / members have right to make representations to the Bank for any issues related
to the RTGS system.

11.5. A participant / member may resign from the membership of RTGS System with 30 days
prior notice to the Chief General Manager, Reserve Bank of India, Department of Payment and
Settlement Systems, 14th Floor, Central Office Building, Shahid Bhagat Singh Marg, Fort,
Mumbai 400001. The Bank shall accept the resignation within the notice period, subject to such
conditions, as it deems necessary to impose on the member and the member shall be bound to
comply with the said conditions. The resignation shall take effect on acceptance thereof by the
Bank.

12. Customer Transactions – Obligations and Rights of Members / Participants

33
12.1. Eligible RTGS member can send / receive customer transactions on behalf of their
customers. The transaction originating member will carry out due diligence while sending the
payment request to the RTGS system. The originating member should ensure two factor
authentications by adopting maker-checker principle while originating a payment transaction.
Depending on the risk perception, participants may introduce / implement additional security
features in the on-line delivery channels for initiating RTGS transactions by the customers. The
originating member should release the payment message from their system to the RTGS central
system within 30 minutes of debiting a customer's account. The originating member should have
the facility of time stamping of their transactions at various stages for effective grievance
redressal mechanism.

12.2. Credit under customer transactions, received by the RTGS member in its Settlement
Account through the RTGS System, has to be ultimately credited to the account of the
beneficiary on the basis of the account number in the payment message. The payment message
receiving member may put in place a Straight Through Processing (STP) mechanism for
crediting the beneficiary’s account. The beneficiary / receiving bank have to credit the account of
beneficiary customer immediately on receipt of the payment message at their Member Interface.
The beneficiary banks should credit the account of the beneficiary within 30 minutes of the
receipt of the message at the Member Interface.

12.3. The participants accessing RTGS system through Web or PO module based service have to
continuously monitor their incoming transactions in the central system for adhering to the
timelines prescribed by the Bank.

12.4. In case of any delay in providing credit to the beneficiaries’ account, the recipient /
beneficiary’s bank has to pay compensation at current repo rate plus 2% to the beneficiary
customer per day. Delay in credit on the same day has to be paid compensation to the customer
for one day. The compensation amount should be credited to the customer’s account
automatically without any request.

34
12.5. In case, it is not possible to credit the funds to the beneficiary’s account for any reason e.g.
account does not exist, account frozen, etc., funds will be returned to the originating member
within one hour of the receipt of the payment at the Member Interface of the recipient member or
before the end of the RTGS Business day, whichever is earlier. The return payment will be sent
by the recipient bank in the prescribed message format stated in Chapter 5. The transaction Id
should be same as that of original message.

12.6. In case of any delay in returning the payment to the originating member, the recipient
member will be liable to pay compensation at current repo rate plus 2% to the originating
member and the same will be ultimately credited to the account of originating customer. In case
of delay in returning on the same day, the receiving bank shall pay compensation to the sending
bank for one day that will be ultimately credited to the sender customer.

12.7 Customer transactions that are not settled in the RTGS on account of insufficient funds will
be viewed seriously. Recurring of such incidents will attract penal provisions as decided by the
Bank.

12.8. All members should provide necessary information in the customer's account statement
pertaining to their RTGS transactions as per the instructions issued by the Bank. Also, members
have to provide information in the form of alert or confirmation to customers as stipulated by the
Bank.

12.9. The participants can levy service charges for RTGS transaction to their customers as per the
instructions issued by the Bank from time to time.

35
12.10. Participants have to comply with the rules and regulations of FEMA and Wire Transfer
Guidelines issued by the Bank from time to time. The sending participant shall provide account
type “NRE” in the Debtor’s (Sender’s) Account Type wherever required.
12.11. The participant / member banks have to mandatorily provide Debtor Name (the ordering
customer) and Creditor Name (the beneficiary customer). The member banks have to furnish
name of the beneficiary in the passbook / account statement of originator and name of ordering
customer in the passbook / account statement of beneficiary from these field tags.

12.12. The participants / member banks have to provide necessary description in the passbook /
account statement of their customer for RTGS return transactions. The originating bank has to
populate necessary information from the ISO message and provide the same to the customer.

12.13. The Bank has the right to issue additional instructions to the RTGS participants for
customer transactions from time to time.

12.14. The Bank may introduce or remove threshold value for any transactions type in the RTGS
system, in future, with due notification to the participants. The existing floor limit for customer
transactions is given in Annex 6.

13. MNSB Settlement and Clearing House Participants

36
13.1. As stated in the Section 4 and access criteria for centralised payment systems, clearing
entities shall be permitted to submit Multilateral Net Settlement Batch (MNSB) file emanating
from the ancillary payment systems managed by the Clearing entity.

13.2. The Clearing entities that have been granted membership or limited access to the RTGS
system have to abide by the terms and conditions stipulated in the access criteria and / or any
other additional / specific conditions stipulated by the Bank from time to time.

13.3. The Clearing entities have to ensure that all their clearing members have current accounts
or settlement accounts or both with the Bank. RBI has right to settle MNSB file in the E-Kuber
which has been posted in the RTGS system and vice versa in case of any eventuality or as a BCP
measure.

13.4. The Bank, at its discretion may specify particular time window for posting the MNSB files
in the RTGS system for settlement.

13.5. The Clearing entities have to ensure maintenance of adequate funds in the settlement or
current account at RBI by their clearing members.

13.6. The MNSB file submitted by a Clearing entity would settle in the RTGS system on an all or
none basis. In case of insufficient funds in one or more clearing member’s settlement account to
take care of debit positions, the entire MNSB file will be pending for settlement. The system will
retry at periodic interval for a certain number of times (as decided by the Bank from time to
time) to reassess the funds position in the concerned member/s’ settlement account/s. If the
MNSB file still remains pending, the sponsorship arrangement / lines of credit arrangement of
the Clearing entity will be invoked, if available, for funding the required shortfall. In case, funds
are insufficient for the settlement of the MNSB file, then the MNSB file will be returned to the
concerned Clearing House.
13.7. Any delay in the settlement of an MNSB transaction, due to failure on the part of an RTGS
member/s to provide adequate liquidity to meet their respective debit obligations, will be viewed
seriously by the RBI. Penalty may be levied at the discretion of the Bank if continued instances

37
of shortfall in funds for MNSB settlement are observed for any RTGS member. The Bank is not
responsible for any delay in settlement or return to the Clearing entity of the MNSB file due to
short of funds in the current / settlement accounts of their clearing members.

13.8. The Bank may instruct Clearing entity for opening of limited purpose settlement account in
the RTGS system by their clearing members having current account with RBI but not a direct
member of the RTGS system.

13.9. On successful settlement of MNSB file, the debit and credit notifications will be sent to the
members of the clearing entity. The RTGS system will send notifications to the members of the
clearing house for debits / credits in the settlement account.

13.10. The Clearing entity, which submitted the MNSB transaction for settlement, affected by an
MNSB transaction, will be notified by the Central System on settlement of the MNSB
transaction. In case of an MNSB file is cancelled/rejected, the Clearing Entity will be notified of
the reason for failure, including details of the clearing participants, who failed to meet their debit
obligations as well as the actual amount of shortfall

13.11. No Clearing Entity will be permitted to cancel an MNSB transaction, once it has been
received by the Central Systems. An MNSB transaction can be cancelled by the Bank only.

14. Obligations and Duties of Members / Participants

38
14.1 All participants are required to closely monitor their liquidity positions. The RTGS
settlement accounts of participants are required to be funded adequately so that gross and MNSB
transactions are settled smoothly. Queuing of transactions and delay of MNSB file settlement due
to liquidity considerations will attract penal action including suspension of membership.

14.2. Members shall implement necessary infrastructure for accessing the Central System at RBI
on its Payment Gateway. The systems specifications should comply with the Bank's instructions /
guidelines. Members should do regularly maintenance of the systems to avoid any failure of
hardware, network and software and put in place the Business Continuity Plan as per the
guidelines specified by the Bank from time to time.

14.3. In case of any failure of the system resulting in non-operation of the system at the member
end, the member should report to the Bank at the earliest and not later than 30 minutes of the
incidence. The members have to adhere to the Business Continuity Plan (BCP) / Disaster
Recovery (DR) guidelines as notified by the Bank from time to time.

14.4. Members have to adhere to the Information Security Guidelines issued by the Bank from
time to time.

14.5. Members have to furnish complete information of the payment transactions in the
prescribed message format while originating transactions stipulated by the Bank from time to
time.

14.6. Members will not at any time assign, lease, license or dispose of to any other person, trust,
company or corporation including its subsidiaries in whole or in part, the RTGS services,
including the software, provided by the Bank or any benefit or advantage derived therefrom.

14.7. Members have to comply with the circulars, notifications, instructions etc. issued by the
Bank from time to time with regard to RTGS System.
14.8. Members are required to provide the information as and when it is required by the Bank.

39
14.9. The Bank may, at any time, conduct or to get conducted audit and inspection of the
member's site with or without any prior notice.

14.10. Members have to pay service charges / membership fees / transaction fees, if any, notified
by the Bank. The Bank has the right to debit such service charges / membership fees / transaction
fees from the member's current account / settlement account maintained with the Bank. Bank
may, at its sole discretion, levy tariffs on various system events associated with the transactions.
These charges are subject to revision from time to time. Bank may, if required, levy any other
additional charges.

14.11. Members should maintain RTGS transactions data for at least 10 years or such time period
as specified by the Bank from time to time. The members that will be using the PO module, data
will be available in the RTGS system.

14.12. The Bank may suspend / terminate the membership if the participant is suspended from
any other associated system(s) like SFMS, INFINET etc.

14.13. The Bank has right to suspend / terminate the membership in case of non-compliance of
any instructions issued from time to time. The Bank will have the authority to determine if a
member can continue to participate in the RTGS system. The Bank will have the right to suspend
or terminate the membership, if continuation of the member is felt to be detrimental to the
smooth functioning of the RTGS system in any manner.

14.14. RTGS member shall continue to be solely liable and responsible for the contents of the
messages sent by it, even if it subsequently resigns or is suspended or its membership is
terminated.

14.15. RTGS member shall be directly and wholly liable in respect of all its customers and with
reference to all the transactions, executed on RTGS system on behalf of such customers and the
Bank shall in no way be responsible either for the source or usage of funds involved in the
transactions.

40
15. Sub-Membership in RTGS System

15.1. Direct RTGS members can extend the RTGS facility to licensed banks which have the
technological capabilities but not participating in the RTGS system on account of either not
meeting the access criteria or because of cost considerations. The direct member is a sponsor
bank and the licensed bank accessing the RTGS system through a sponsor bank is a sub-member.

15.2. The sponsor banks would be responsible for sending / receiving the transactions / messages
on behalf of their sub-member(s).

15.3. The obligations and duties in respect of customer transactions viz. timely credit and return
are applicable to the sub-members also.

15.4. There are no restrictions on the number of sub-members a sponsor bank could sponsor.
Aspects relating to operational feasibility, risk mitigation, fund settlement, collaterals etc., are the
responsibility of sponsor bank.

15.5. The sponsor bank should put in place a risk management framework and a system of
continuous monitoring of the risk management practices of sub-member(s) they sponsor. The risk
management framework should be approved by the Board of the sponsor bank.

15.6. The settlement of transactions by/on the sub-members would take place in the settlement
accounts of the sponsor banks maintained with Reserve Bank of India. The sponsor bank under
this arrangement will assume complete responsibility for the settlement of all transactions
pertaining to their respective sub-members.
15.7. The sponsor bank at all times should ensure that their sub-member/s adhere to and abide by
the rules, regulations, operational requirements, instructions, orders, decisions etc, of the RTGS
system, as laid down by Reserve Bank of India from time to time.

41
15.8. Redressal of all customer complaints / grievance would be the responsibility of the sponsor
bank. To aid in this process, the sponsor bank should ensure that the sub-member/s have put in
place a transparent and robust mechanism to resolve customer complaints in a quick and efficient
manner, as laid down in the procedural guidelines, business rules and regulations of the RTGS
system.

15.9. All disputes between the sponsor bank and the sub-member/s will be handled bi-laterally
amongst them.

15.10. The sponsor bank should bring to the immediate notice of the Reserve Bank of India:
(i) any involvement of its sub-member/s in any suspicious transactions, frauds, etc.;
(ii) any of its sub-member/s resorting to any unfair practices relating to their participation in
RTGS system;
(iii) any of its sub-member/s not adhering to the rules, regulations, operational
requirements, instructions etc., of RTGS system;

15.11. The sponsor bank is not required to take prior approval of the Reserve Bank of India for
sponsoring a sub-member/s into the RTGS system. However, as and when a sponsor bank admits
a sub-member, the sponsor bank is required to immediately inform The Regional Director,
Reserve Bank of India, Department of Payment & Settlement Systems (RO), Main Office,
Mumbai , regarding the details of the sub-member/s, IFSC allotted to the branch/branches of sub-
member/s, date of commencement of sub-membership etc. Further, every direct member bank
has to submit the Bank with a list of their sub-members of RTGS system as on March 31 every
year. The list is to be submitted to The Regional Director, Reserve Bank of India, Department of
Payment & Settlement Systems (RO), Main Office, Mumbai.

15.12. The sponsor bank should inform the Reserve Bank of India in case of cessation of
sponsorship arrangement between the sponsor bank and sub-member/s immediately.

42
15.13. The charges for customer transactions of sub-member/s cannot exceed the maximum
charges prescribed by the Bank from time to time and that by the sponsor bank.

16. Dispute Resolution

16.1. The Bank shall endeavour to ensure proper operation, control, maintenance and security of
the RTGS System. The Bank shall not be responsible for the loss, if any, that may be caused to
the members or their customers or any person, arising out of any action taken in good faith by
the Bank’s staff or malfunctioning or break down of the computer systems, computer network,
telecommunication network or any other equipment (inclusive of hardware and software), used
in the RTGS System or any force majeure conditions.

16.2. The Bank will issue necessary guidelines on Dispute Resolution Mechanism from time to
time. The disputes between two members of RTGS system should be addressed to the Regional
Director, Reserve Bank of India, Mumbai Regional Office, Main Building, Shahid Bhagat Singh
Marg, Fort, and Mumbai- 400001. In the event of any difference or dispute, arising between any
two members in connection with the RTGS System or incidental thereto, the dispute shall be
resolved by the Bank as per the guidelines issued on Dispute Resolution Mechanism by the Bank
from time to time.

Customer Service / Facilitation

16.3. The members have to set up customer facilitation centre (CFCs) for handling complaints
related to RTGS transactions. The details of customer facilitation centers viz., nodal person and
contact numbers have to be displayed by the members in their website and branches. These
details have to be shared with the Regional Director, Reserve Bank of India, Mumbai Office,
Main Building, Shahid Bhagat Singh Marg, Fort, and Mumbai- 400001.

43
16.4. The customers of banks / participants may send their complaints to the Chief General
Manager, Reserve Bank of India, Customer Service Department, Amar Building, 1st Floor, Sir P.
M. Road, Fort, and Mumbai- 400001.

16.5. The Bank has the right to levy penalties or any other punishment like suspension,
termination etc. to the RTGS members in the event of violation of the guidelines, instructions etc.
issued by the Bank from time to time.

16.6. The Bank has the right to frame additional guidelines / amendments to the existing
guidelines as deemed fit from time to time.

17. Important implications for the working of the RTGS system

17.1. Ownership and access policies- Most systems are owned by central banks. ELLIPS and
CHAPS are owned by an association or a company whose members are the direct participants
and the central bank; the systems are connected to the central bank's internal real-time
accounting system. Access policies also differ. In principle, direct access to RTGS systems
requires participants to hold their accounts at the central bank, which may raise issues regarding
the conditions under which participants can hold central bank accounts. In the majority of
systems direct access is open to all banks (or credit institutions or depository institutions as
applicable). Additional criteria such as financial strength and technical requirements are applied
in several systems. In the European Union the central banks have agreed that, with limited
exceptions, direct access should be confined to credit institutions. Partly reflecting the differing
access policies, the number of direct participants varies across systems; some systems have large
numbers of direct participants, whereas other systems are two-tiered systems with a more limited
number of direct settlement members, although indirect participation in the system can be wide.

44
17.2. Message flow structures- A lag between the time at which information is made available to
receiving banks and the time at which settlement takes place may have important risk
implications in large-value funds transfer systems. Even in the RTGS environment, where both
processing and final settlement are made in real-time, several circumstances can be identified in
which the treatment of payment messages or the associated information could be a source of risk.
There are two different types of message flow structure that are widely used in RTGS systems.

a) V-shaped Structure: To initiate a funds transfer the sending bank dispatches a

payment message which is subsequently routed to the central bank and to the
receiving bank as the system processes and settles the transfer. Arrangements for
routing payment messages in the majority of RTGS systems are or will be based
on a so-called V-shaped message flow structure. In this structure the full message
with all the information about the payment (including, for example, the details of
the beneficiary) is initially passed to the central bank and is sent to the receiving
bank only after the transfer has been settled by the central bank

b) Y-shaped Structure: In this case, the payment message is transmitted by the

sending bank to a central processor. The central processor takes a subset of
information that is necessary for settlement from the original message and routes
this core subset to the central bank (the original message being kept in the central
processor). Upon receipt of the core subset, the central bank checks that the
sending bank has sufficient covering funds on its account and informs the central
processor of the status of the transfer, for instance queued or settled. Once settled,
the full message containing the confirmation of settlement is rebuilt by the central
processor and sent to the receiving bank. The business information exchanged
between the sending and receiving bank (such as the identity of the beneficiary) is
therefore not known by the settlement agent.

45
17.3. Reserve requirements and central bank account structures- Countries vary in the extent to
which required reserves are imposed and are available for use as intraday liquidity in the RTGS
system. Central bank account structures also vary in terms of whether the RTGS accounts are
separated from the accounts used for required reserves or other purposes (i.e. unified or
segregated accounts) and whether banks can hold RTGS accounts at more than one office of the
central bank (i.e. centralized or decentralized accounts).

46
17.4. Relationships with other systems- In Germany, Japan and the United States, RTGS systems
coexist with net settlement systems for large-value transfers, and this will also be the case in
France. In other countries RTGS systems are or will be the only large-value funds transfer
system. RTGS systems are also used for the settlement of retail payments in various ways and in
several countries RTGS systems support real-time DVP systems for securities transactions.

17.5.Queuing arrangements: Broadly defined, queuing refers to an arrangement whereby funds

transfer orders are held pending by the sending bank or by the system in a certain order so as to
prevent any limits set against the sending bank from being breached or to manage liquidity more
generally. In RTGS systems, queues are most commonly generated when sending banks do not
have sufficient covering funds in their central bank account. Individual banks' queues may be
held at the system's central processor (system or centrally located queues) or they may be held
within the banks' internal systems (internal queues). These two broad possibilities according to
the location of the queues are not mutually exclusive; banks may maintain internal queues in
addition to the queues at the Centre, as is done in some RTGS systems with centrally located
queues. Queuing can also differ according to the management of the queues, that is, how an
individual bank's queue is controlled. The management may be carried out by the Centre
(centralized management) or by banks individually (decentralized management). Irrespective of
whether the queues are physically located at the Centre or within banks' internal systems, the
management of queues could in principle be either centralized or decentralized. Combinations of
these possibilities in terms of the location and management can thus lead to various forms of
queuing.

47
18. Disclosures:

18.1. RBI in the interest of banking or monetary policy or the operation of the payment systems
generally or in the public interest may disclose such information as deem fit and proper to any
person.

18.2. The Member’s transactions, including their customer transactions, settled or rejected
through the RTGS System, may be shared, as deemed necessary by RBI, with Regulatory
Authorities, Government and other appropriate authorities.

19. Conclusion:

The concept of RTGS is straightforward but the systems themselves can take many different
forms. These differences partly reflect the fact that circumstances vary from country to country,
so that arrangements that are appropriate for one country may not be relevant for another. In
many cases a pragmatic approach has been adopted to certain design features.
Finally, as mentioned earlier, RTGS systems are on the whole a relatively recent concept and
thus there has often been little operational experience on which to base comparisons between
different options.
Given these factors, while it may be difficult to draw any universally applicable conclusions
about the merits of particular features of RTGS systems, it might be useful to set out the key
criteria that are likely to be used when choosing between different options. RTGS systems can be
categorized according to three main considerations, namely (a) whether the central bank provides
intraday credit to participants in the system and, if so, on what terms, (b) the message flow
structure and (c) the facilities, if any, available for queuing. Although there are many other ways
in which systems differ, these three areas seem to capture the most important aspects.
Whether intraday credit is provided or not may depend partly on whether interbank funds
transfer systems are seen simply as mechanisms that enable settlement to take place, in which

48
case it may be decided that no specific liquidity facilities will be provided, or whether the
provision of intraday liquidity is seen as being a straightforward extension of a central bank's
existing role as a provider of liquidity to the banking system. The decision to extend intraday
credit may also reflect a view that intraday credit is necessary to enable the system to function
smoothly. Where credit is provided, there are variations in the terms set (e.g. whether the credit
has to be collateralized and what fee or interest rate, if any, is charged), reflecting a number of
important considerations.
As far as the message flow structure is concerned, the key choice is often between the V-shaped
and Y-shaped structures, and an important consideration here is the role of the central bank
relative to the private sector in the day-to-day operation of the system: for some, the attraction of
the Y architecture is that it enables a distinction to be drawn between the central bank's core role
as settlement agent and the rest of the system processing, which can be a separate, private sector
function.
Approaches to queuing may depend importantly on views about the relative roles of the private
sector and the central bank, the central bank's policies regarding the granting of intraday credit
and the extent to which banks can obtain liquidity easily from their own sources. If, as noted
above, an interbank funds transfer system is seen as being simply a settlement mechanism, then
it may also be that no centralised queue management facilities are provided beyond basic FIFO
processing. Or the balance between centralized and decentralised queue management may
depend on the extent to which banks see such management as a competitive issue rather than one
on which they want a standard approach to be adopted. Consideration of the balance to be struck
between risk, cost and liquidity may also determine whether queued incoming transfers are
transparent or not.
Finally, it is important to stress that, in designing an RTGS system; attention must be paid to the
broader financial environment in which the system is to operate. Mention has already been made
of the fact that circumstances vary from country to country, and this is true not just of the
payment system environment but also of the financial system in a wider context. Hence system
architects while designing an RTGS systems should keep the ground realities and the
environment in which the system is to operate in mind so that the end consumer or a common
man receives the ultimate benefits.

49
Annex 1:Channel Codes for UTR/Transaction identification

Channel ID Values

RTGS 9

Internet Banking 1

Cash Management 2

Treasury 3

ATM 4

Mobile 5

Other 6

50
Annex 2: Codes on Message Validation (RTGS)
Error Code Error
INVFMT Invalid message format
INVDATEFMT Invalid date format
INVCREDINST Invalid credit institution
INVDEBINST Invalid debit institution
INVSND Invalid sender IFSC
INVRCV Invalid receiver IFSC
INVDEST Invalid destination
INVPART Invalid participant
INVCURR Invalid currency
INVAMT Invalid amount
DUPREF Duplicate reference
INVDATE Past business date

The message specifies a value date which is closed (that is not a working
INVDATEEOD day (within the specified range of value dated transactions) or a past
working day)

INVDATEIC Initial cut-off has been performed

INVDATEFC Final cut-off has been performed
INVBUSSDATE Not a business date

The interval between current date and the future date is greater than the
INVBUSSDATEFUTURE
parameter for warehousing the future dated transactions

INVMTTYPE Invalid message type

INVSIG Invalid digital signature

The message was not sent using the gateway of the payment sender (for
INVGW
example, incorrectly configured contingency gateway)

no processing rule defined for the assigned TTC in the parameters for this
INVPROCRULE
TTC (which are defined at TTC set up)

INVDEFPROCRULE No default rule defined for this transaction type

INVTRANTYPEFORRULE Transaction type and assigned processing rule do not match

INVRESERVEOWNER Reserve owner does not match with the sender

CANUSR Transaction was cancelled

CANBLKDEB Blocked debtor settlement account
CANBLKCRED Blocked creditor settlement account
Annex 3:List of TTC Values and Priority for RTGS System

51
 TTC Transaction Priority Default IDL Members
Value Type Range Priority Facility Eligible
1000 Customer 11-99 35 Yes A

1400 Inter-bank 11-99 35 Yes A, B

1800 Own Account 11-99 35 No A, B, D

Yes (for
3000 MNSB 11-99 11 C, D
members)

3200 Inter-bank 11-99 35 No D

3500 Customer 01-10t 5 No RBI

3600 Inter-bank 01-10 5 No RBI

Yes (for
3700 MNSB 01-10 5 RBI
members)

4000 Customer 11-99 45 No D

Annex 4: Cut-off Times in the RTGS System at RBI

52
 S. Saturday / Short
Time Event Weekdays / Regular Days
No. Days

1 Open for Business 09:00 hours 09:00 hours

2 Initial Cut-off 16:30 hours 14:00 hours

3 Final Cut-off 18:30 hours 15:00 hours

4 IDL Reversal 18:30 hours - 19:00 hours -

5 End of Day 1930 hours 15:30 hours

Annex 5: RTGS Threshold Value and Maximum Service Charges for Customers

53
Table 1: RTGS Threshold

S.
Transaction Type Threshold Value
No.

1 Customer Rs. 2 lakh (floor limit)

Table 2: Maximum Service Charges Members Can Levy to the Customers

S. RTGS Transaction Type and

Maximum customer charges
No. Value Band

1 Inward transactions Free

2 Outward transactions

Rs.25 + applicable time varying tariff subject to a

2a. Rs.2 lakh to Rs.5 lakh
maximum of Rs.30/-.

Rs.50 + applicable time varying tariff subject to a

2b. Above Rs.5 lakh
maximum of Rs.55/-.

Annex 6 : RTGS Service Charges for Members

54
The RTGS service charges has three components viz., (a) monthly membership fee, (b)
transaction fee and (c) time-varying tariff for members and are as follows:

a) Membership fees

Type of RTGS Type of Monthly

Type of entities
participant Membership membership fee
Banks other than co-
Rs. 4,000
operative banks
Regular Type A
Co-operative Banks Rs. 2,000

Restricted Type B Primary Dealers Rs. 2,000

Clearing House / Clearing entities and

Type C & D Rs. 2,000
Regular / Restricted Special/other entities

b) Transaction fee (per transaction)

Monthly Volume
Band Charge per transaction Remarks
From To
1 1 25000 Rs. 0.50 First 25,000 transactions
2 25001 50000 Rs. 0.40 will be charged @
3 50001 100000 Rs. 0.30 Rs.0.50; next 25,000
will be charged @ 0.40
4 100001 and above Rs. 0.10 and so on

c) Time varying tariff

55
 Block Time of settlement at the Reserve Bank of India Charge per transaction

From To
1 09:00 hours 12:00 hours Nil
2 After 12:00 hours 15:30 hours Rs. 1
3 After 15:30 hours 17:30 hours Rs. 5
4 After 17:30 hours Rs. 10

About RTGS:

RTGS System –

The acronym 'RTGS' stands for Real Time Gross Settlement, which can be defined as the
continuous (real-time) settlement of funds transfers individually on an order by order basis
(without netting). 'Real Time' means the processing of instructions at the time they are
received rather than at some later time; 'Gross Settlement' means the settlement of funds
transfer instructions occurs individually (on an instruction by instruction basis). Considering
that the funds settlement takes place in the books of the Reserve Bank of India, the payments
are final and irrevocable.

Minimum / maximum amount stipulation for RTGS transactions –

The RTGS system is primarily meant for large value transactions. The minimum amount to
be remitted through RTGS is ` 2 lakh. There is no upper ceiling for RTGS transactions.

Time taken for effecting funds transfer from one account to another under RTGS –

56
 Under normal circumstances the beneficiary branches are expected to receive the funds in
real time as soon as funds are transferred by the remitting bank. The beneficiary bank has to
credit the beneficiary's account within 30 minutes of receiving the funds transfer message

Customer receive an acknowledgement of money transfer –

The remitting bank receives a message from the Reserve Bank that money has been credited
to the receiving bank. Based on this the remitting bank can advise the remitting customer
through SMS that money has been credited to the receiving bank.

If RTGS fails –

Funds, received by a RTGS member for the credit to a beneficiary customer’s account, will
be returned to the originating RTGS member within one hour of the receipt of the payment at
the PI of the recipient bank or before the end of the RTGS Business day, whichever is earlier,
if it is not possible to credit the funds to the beneficiary customer’s account for any reason
e.g. account does not exist, account frozen, etc. Once the money is received back by the
remitting bank, the original debit entry in the customer's account is reversed.

RTGS service –

The RTGS service window for customer's transactions is available to banks from 9.00 hours
to 16.30 hours on week days and from 9.00 hours to 14:00 hours on Saturdays for settlement
at the RBI end. However, the timings that the banks follow may vary depending on the
customer timings of the bank branches.

Processing Charges / Service Charges for RTGS –

With a view to rationalize the service charges levied by banks for offering funds transfer
through RTGS system, a broad framework has been mandated as under:
a. Inward transactions – Free, no charge to be levied.
b. Outward transactions – Rs.2 lakh to Rs.5 lakh - not exceeding Rs.30.00 per transaction;
Above Rs.5 lakh – not exceeding Rs.55.00 per transaction.

57
Essential information for initiating a RTGS remittance –

1. Amount to be remitted
2. Remitting customer’s account number which is to be debited
3. Name of the beneficiary bank and branch
4. The IFSC Number of the receiving branch
5. Name of the beneficiary customer
6. Account number of the beneficiary customer
7. Sender to receiver information, if any

RTGS service availability –

All the bank branches in India are not RTGS enabled. Presently, there are more than 100,000
RTGS enabled bank branches. The list of such branches is available on RBI website at:
http://rbidocs.rbi.org.in/rdocs/RTGS/DOCs/RTGEB0815.XLSX

Branch of the beneficiary accepts remittance through RTGS –

For a funds transfer to go through RTGS, both the sending bank branch and the receiving
bank branch would have to be RTGS enabled. The lists are readily available at all RTGS
enabled branches. Besides, the information is available at RBI website
(http://rbidocs.rbi.org.in/rdocs/RTGS/DOCs/RTGEB0815.XLSX).Considering that more than
110,000 branches at more than 30,000 cities / towns / taluka places are covered under the
RTGS system, getting this information would not be difficult.

Bibliography

58
A. https://rbidocs.rbi.org.in
B. https://www.goodreturns.in
C. www.globaltreasurer.com

Thank you

59