Need Tally
for Clients?

Contact Us! Here

  Tally Auditor

License (Renewal)
  Tally Gold

License Renewal

  Tally Silver

License Renewal
  Tally Silver

New Licence
  Tally Gold

New Licence
 
Open DEMAT Account with in 24 Hrs and start investing now!
« Latest Circulars »
Open DEMAT Account in 24 hrs
 Auction of State Government Securities Feb 23, 2024
 RBI imposes monetary penalty on The Adinath Co-Operative Bank Limited, Dist. Surat, Gujarat
 The Relevance of SEACEN in a Turbulent World (Closing remarks by Michael Debabrata Patra, Deputy Governor, Reserve Bank of India - February 15, 2024 - at the 59th SEACEN Governors' Conference
  Business restrictions imposed on Paytm Payments Bank Limited vide Press Releases dated January 31 and February 16, 2024
 Extension of validity of Directions under Section 35A read with section 56 of the Banking Regulation Act, 1949 (As Applicable to Co-operative Societies) - HCBL Co-operative Bank Ltd., Lucknow (U.P.)
 Business restrictions imposed on Paytm Payments Bank Limited vide Press Releases dated January 31 and February 16, 2024
 Directions under Section 35 A read with section 56 of the Banking Regulation Act, 1949 Shimsha Sahakara Bank Niyamitha, Maddur, Mandya District Extension of Period
 Reserve Bank of India (Government Securities Lending) Directions, 2023
 Building resilient brand India amidst global uncertainty (Speech by Shri Swaminathan J, Deputy Governor, Reserve Bank of India - December 28, 2023 - at the 10th SBI Banking and Economic Conclave in Mumbai)
 Trade Credit for imports into India Submission of return on issuance of bank guarantees for Trade Credits on the Centralised Information Management System (CIMS)
 Minutes of the Monetary Policy Committee Meeting, December 6 to 8, 2023

RBI-New features in RTGS System
June, 23rd 2014

RBI/2013–14/651
DPSS (CO) RTGS No.2589/04.04.017/2013-14

June 20, 2014

The Chairman / Managing Director / Chief
Executive Officer of participants of RTGS

Madam / Sir,

New features in RTGS System

Please refer to our circular DPSS (CO) RTGS No.801/04.04.017/2013-14 dated October 11, 2013 regarding the launch of new RTGS system and coming into effect of “RTGS System Regulations 2013”. A reference is also invited to Chapter 9 of the “RTGS System Regulations 2013” wherein it had been indicated that the new features in RTGS system will be enabled after due notifications to members.

2. The new RTGS system has been running smoothly and has stabilised. It has hence been decided to enable the ‘Hybrid’ and ‘Future value dated transaction’ features in the system with effect from July 14, 2014. The details regarding operations of these two functionalities are given in Annex.

3. The Hybrid feature will be configured to do off-setting every 5 minutes. The transactions with normal priority would be settled in off-setting mechanism, with a maximum of two attempts i.e. the maximum time a transaction would be in “normal” queue is 10 minutes. If the transactions with normal priority are unable to be settled in offsetting mode within this time, the priority of the transaction would be automatically changed to “urgent”. The parameter value will be set to 10%. This means that 10% of the balance in the settlement A/c would be taken for settlement in the offsetting mode.

4. The Future Value dated Transaction would enable the customers / participants to initiate RTGS transactions 3 working days in advance for settling in RTGS on value date.

5. The circular is issued under section 10 (2) of Payment and Settlement Systems Act 2007, (Act 51 of 2007).

Yours faithfully,

Vijay Chugh
Chief General Manager

Encl: As above.


Annex

1. Hybrid feature

a) The RTGS system supports a new and unique way to handle large volume of payments using a minimum amount of liquidity from the Participants’ settlement accounts.

b) From the priority point of view, the RTGS system can handle two types of payments:

  1. Urgent payments
  2. Normal payments

c) Both categories are implemented over the same ISO20022 standard and share the same rules and regulations. However, while the urgent payments are processed as soon as they are received by the RTGS and using as much liquidity as required from the settlement account of the sending Participant, the normal payments are processed differently, following some strict processing rules which do not apply to the urgent payments. These rules are:

  1. The normal payments are not settled immediately, even though the sending bank may have sufficient funds in its settlement account;

  2. The normal payments may settle only at periodic time intervals which are controlled centrally by system parameter of RTGS;

  3. The RTGS does not take into consideration the pending normal transactions in the calculation for IDL funding request to CBS;

  4. The settlement of normal payments can occur only if several participants, simultaneously, have sent normal payments to each other. If 0 % of allowance is set in parameter value (centrally), in that scenario the transactions would look for settling transactions without using any amount from the settlement account, i.e., settlement will happen purely on offsetting mode. If an allowance of 1% is set in the parameter in that scenario, the transactions would try to settle using a percentage of the amount from the settlement account.

  5. If the condition for the settlement of normal payments is not possible, the system will automatically promote the normal payments to the urgent payment stream, after a predefined timeout parameter. Once promoted, the transactions will be processed according to the urgent payments’ settlement rules.

  6. From the format point of view, the field that designates a payment as normal or urgent is called InstrPrty and its content should be:
    • NORM – for normal payments
    • HIGH – for urgent payments

Process flow

The normal payments will have the following flow in RTGS:

1. A new normal message is received, validated and (if successful) placed in the ENTER status queue.

2. The item will stay with status ENTER until the first gridlock cycle for the normal stream runs. After the cycle is completed, the item will change its status to COMPLETE (if the item was settled) or PENDING (if the item was not included in any gridlock solution).

3. Subsequent gridlock cycles will attempt to settle the item (every 5 minutes), considering other normal payments found in the system. If a solution is found by the normal payment stream gridlock resolution process, the respective transactions are updated to status COMPLETE and the respective output messages are generated to the sender and receiver.

4. If a solution is not found within the timeout period (10 minutes) for the normal payments, the item is promoted to the urgent stream. The change is visible to the end user when listing the transaction and also in the audit trail of the item.

5. Once the transaction is promoted to urgent, if the sending Participant does not have the required liquidity, the IDL funding may be invoked depending on the TTC of the item.

Example

The following table demonstrates how this feature will work. T1, T2, T3 etc. indicates the transaction initiated by banks. The bank initiating the transaction is debited and beneficiary bank is credited.

Normal Transaction in queue

Initiating Bank
( Debit)

Recipient Bank
(Credit)

Amount

T1

A

B

5,00,000

T2

B

C

4,80,000

T3

C

A

4,60,000

T4

B

C

1,00,000

T5

C

A

1,10,000

The following table explains how these transactions would be settled in off-setting mode when no liquidity is used from the settlement account of the banks or when a percentage of the amount in the settlement account is used for settling the transactions in offsetting mode. The parameter value indicates the percentage of the liquidty, that can be used for settlement of the transactions in offsetting mode (transactions with normal priority).

Example

Parameter Value

Settlement Account

Settled Transaction

Used Liquidity from A

Used Liquidity from B

Used Liquidity from C

Balance of Bank A

Balance of Bank B

Balance of Bank C

1

0%

10,00,000

10,00,000

10,00,000

0

0

0

0

2

5%

10,00,000

0

0

T1,T2,T3

40,000

0

0

3

10%

10,00,000

10,00,000

10,00,000

T1,T2,T3,T4,T5

0

80,000

0

In the example 1 the parameter value is set to 0% i.e. no amount will be utilised from the settlement account to settle these transactions. Hence, none of the above transactions listed (T1, T2, T3, T4 and T5 will be settled) as there is no transaction with equal value to offset (settle) the transaction.

In example 2, the parameter value is set to 5%. The maximum amount which can be used from the settlement account is Rs.50,000 (i.e.5% of Rs. 10,00,000). The transaction T1, T2 and T3 are settled. Though the maximum which can be used from settlement account is Rs.50,000 the actual amount utilised from A’s settlement account is 40,000 to settle these transactions. i.e. Rs.40,000 is utilised to settle transactions T1, T2 and T3 amounting to Rs.14,40,000. However, transaction T4 and T5 could not be settled as liquidity requirement for settling these transactions was more than Rs.50,000.

In example 3 the parameter value is set to 10%. The maximum amount which can be utilised from the settlement account for settlement of the transactions with normal priority is Rs. 1,00,000. In this case, all the transactions listed (T1, T2, T3, T4 and T5) are settled by usitlising Rs.80,000 from settlement account of B.

2. Future Value Transactions

1. This feature will allow Participants to send RTGS payments which are not submitted for settlement immediately, but at a later date. This option will facilitate the scheduling of certain important payments days in advance.

2. The RTGS will not attempt to settle them immediately but it will wait until the respective value date is reached.

3. The value date must be within a certain time period which is controlled by system parameter of the application (3 working days). When sending a future value payment, the sender must ensure that the respective value date is a working date according to the present RTGS calendar. If the value date is set on a non-working date, the payment will be rejected immediately.

4. A future value dated transaction can be manually canceled at any time, as long as its status is FUTURE, from the Settlement / Transaction / Cancel menu option. (The cancel operations requires an approve confirmation.)

5. When a Participant is removed, any future value payments already sent by the said participant and stored in RTGS will be automatically canceled. The sender will be notified about the cancelation using standard notification messages.

6. If the calendar of RTGS is modified by RBI and as a result some future value payments already present in the system have their value date falling on a non-working date, the respective transactions will not be canceled. The items will remain in the system and they will be submitted to the settlement process on the first working day following the original value date.

Home | About Us | Terms and Conditions | Contact Us
Copyright 2024 CAinINDIA All Right Reserved.
Designed and Developed by Ritz Consulting