adsense

Monday, March 29, 2010

RTGS/NEFT/ECS are closed on 01/04/2010 – 1st April 2010


RTGS is closed on 01/04/2010 – 1st April 2010
NEFT  is closed on 01/04/2010 – 1st April 2010
ECS  is closed on 01/04/2010 – 1st April 2010
Apart from a holiday on 01/04/2010 – 1st April 2010, RTGS/NEFT/ECS are also closed on 02/04/2010.
01/04/2010, is the Annual Closing day for Indian Banks.
One moot question is that in today's computerised environment, is a Public Holiday, required to enable Banks to close their Books.
Well, till all the Bank Branches are brought under CBS(Core Banking Solution), a Public Holiday will be required to enable the Bank Branches  to close their Books of Accounts. 
There will be a series of holidays for RTGS/NEFT/ECS i.e 01/apr/2010, 02/apr/2010 and 04/02/2010.
Already the year-end rush has started from today itself i.e 29th March 2010.
This means there will be heavy rush of transactions on 3rd april and 5th april too.
Viewers are requested to plan properly their ePayments to avoid any last-minute tension.
– Try to comlete your RTGS/NEFT transactions by the afternoon of 31st March.
– This will ensure peace of mind for all the concerned parties.

Sunday, March 21, 2010

NEFT – New Settlement Batch @ 8.00am



NEFT – New Settlement Batch @ 8.00am

This is with reference to the new NEFT feature of T+2 hours settlement cycle.
The T+2 hours settlement cycle means that the Beneficiary Bank has to credit the respective accounts within 2 settlement cycles or Return, in case the credit cannot be afforded.

Why cannot some NEFT Transactions be credited to the beneficiaries account?
The primary reasons are
  1. Invalid Beneficiary Account Number
  2. Incorrect Beneficiary Name I.e There is a mis-match in the Beneficiary name as mentioned in the NEFT Transaction and the Beneficiary's name in the Bank Account.
The Secondary reasons are:-
  1. Account Closed
  2. Credit Restrictions in the account for eg: No-Frills account.
  3. Account does not exist, credit meant to A Bank Account is sent to B Bank Account !!


Do all NEFT transactions require the T+2 hours settlement window ?

In my opinion no. Any business transaction has a normal processing cycle and a quick processing cycle.
This is visible in every sphere of life
Railways-Sleeper and AC,
Temple Darshan – Ordinary and VIP, based on the cost of the entry ticket.
Bank Accounts – Based on the Average Quarterly Balance – Additional features are offered
Cinema Tickets – Ordinary and Balcony.

Than why do all NEFT Transactions have to adhere to T+2hours Settlement Cycle.
There are many types of transactions which can have a different Settlement Cycle, than the T+2hours settlement cycle.
  1. Dividend Payouts
  2. Vendor Payouts
  3. Insurance company Payouts
  4. Etc

Hence, I suggest an additional Settlement Cycle. Any new suggestion has to be 01) Simple to understand
  1. Easy to implement

I propose the following new Idea:-

A new settlement cycle at 8.00am, for Bulk uploads. The Settlement Cycle for the 8.00am Batch, will be T+1 day.
In the 8.00am NEFT Settlement Cycle,

  1. Dividend Payouts
  2. Vendor Payouts
  3. Insurance company Payouts
  4. Etc

can be settled. As the transactions are not direct customer initiated, a little delay will not hurt any one and at the same time will boost the volumes in NEFT.

The T+2hours Settlement Cycle, is a wonderful concept and has many benefits in it.
But, I feel that the driver for NEFT Volumes, will be the bulk uploads viz Dividend Payouts, Vendor Payouts, Insurance company Payouts. Of course the individual transactions will constitute a major chunk of the overall NEFT Volumes.

Saturday, March 20, 2010

Neft Timings In India - from 01/03/2010

Present NEFT  Timings
New Neft Timings
I.e from 01/03/2010

Weekdays
Weekdays
9.00 am to 5.00 pm
9.00 am to 7.00 pm
Saturdays
Saturdays

9.00 am to 12 noon
9.00 am to 1.00pm

Thursday, March 18, 2010

New NEFT Features from 01/03/2010(01 March 2010) - Tightening of Return Window


New NEFT Features - Tightening of Return Window



One of the key features of the New NEFT features from 01/03/2010 is the

Tightening of Return Window

·        Presently, the NEFT procedural guidelines mandate banks to return NEFT transactions in the very next available batch.
·        Prior to 01/03/2010, the NEFT system had been designed to allow destination banks to return transactions on a T+1 basis. The traffic analysis has revealed that a major chunk of returns are effected by banks either in the last batch of the day or in the first batch of the next day, indicating that the transactions are processed by the destination batches only at the end of the day instead of batch-wise.
·        In order to streamline the system and complete the processing cycle on a near-real-time basis, the concept of return within two hours of completion of a batch is being introduced.
·        The B+2 return discipline would require banks to afford credit to beneficiary accounts immediately upon completion of a batch or else return the transactions within two hours of completion of the batch settlement, if credits are unable to be afforded for any reason.

The complete Notification can be accessed @

It has been more than 3 weeks since the new regulations went Live. And, the response to this new change is a mixed bag.
Of course, I am sure, lots of thought and brain-storming must have proceeded, before the introduction of B+2 return discipline.
Only time will tell, whether this feature is a success or a failure.

With Straight through Processing and Payee Name Validation, majority of the NEFT Inwards will be automatically routed to the destination account.
The major issue is the keying of the wrong account in the Beneficiary Account Number field. This error can occur at the Data entry level by the bank employees or providing wrong account number of the beneficiary by the Sender.

I feel one more validation should be introduced at the SFMS Gateway level itself.
--- At present 86+Banks participate in the NEFT Settlement Cycle.
15 Banks contribute to 75% of the volumes.
All this 15 Banks are on CBS(Core Banking Solution) i.e the Digits in the Customer Account Number are standardized across the bank, irrespective of the Product Code..
Eg: ING Vysya Bank -  12 Digit Account Number
Andhra Bank – 15 Digit Account Number.
South Indian Bank – 16 Digit Account Number
Union Bank of India – 15 Digit Account Number
Bank of Baroda – 14 Digit Account Number
                                                                              
The above data has been drawn from personal experience and the internet, the number of digits might be wrong. However this is not the point here.

The NEFT program should have an online verification of the Digits in the Beneficiary’s Banks Account number.
For eg: If an NEFT transaction is being executed from Andhra Bank account to ING Vysya Bank account, the NEFT Application should validate the ING Vysya Bank’s Account for 12 digits and than only the transaction should proceed.
This will minimize NEFT transactions with less than or more than the ING Vysya Bank’s CBS account number being transmitted, which in turn will reduce RETURNS.

Is this feasible?
Yes, 100% feasible.
Only an additional table in the NEFT Application is required, which has to be periodically updated as and when the data is received fro the Participant Banks.
Once Banks move to CBS, it will be very rare for the whole Account Number mechanism to change. Hence, only a one time exercise will suffice.

Process Flow:
01) A New Table is introduced in the NEFT Application – Banks CBS Account Digits
02)                       It is populated with the number of digits of CBS Accounts of the respective Banks
03)                       On a NEFT Inward (NO6), being received for a particular bank, the Digits in the Account Number field is cross-checked for the correct number.
04)                       If the digits in the Beneficiary Account number field match with the NEFT Master, the transaction is processed further.
05)                       IF the digits in the Beneficiary Account number field DO NOT match with the NEFT Master, the transaction is rejected at SFMS Level only with the reason INVALID Account number.

This is only a preliminary approach, and can be fine-tuned after brainstorming.











Tuesday, March 16, 2010

No RTGS/NEFT Holiday on Ugadi/Gudi Pawadha on 16th March, 2010.

What Is UGADI?



No RTGS Holiday on Ugadi/Gudi Pawadha on 16th March, 2010.

No NEFT Holiday on Ugadi/Gudi Pawadha on 16thMarch, 2010.
ePayments i.e RTGS/NEFT are functioning normally on Ugadi/Gudi Pawadha on 16th March, 2010

UGADI is a combination of two words-Yuga(era) and Aadi(beginning) according to the ancient language of Sanskrit and Kannada languages.
It simply means beginning of an era or a new year.

Ugadi/Gudi Pawadha, is celebrated mainly in South India and Maharashtra.
North India, does not celebrate this festival. Hence, no Holiday for RTGS has been declared.

This is the first major festival after the roll-out of the new timings for NEFT and the T+2 hours validation.

Normally, on holidays the staff at the RTGS/NEFT processing centers would be at a minimum. However, now with the increase in NEFT Cycles and the T+2 hours, it will be challenge to run the operations with minimum staff. All the staff would like to celebrate the festival with their family members.

Prior to 1st March 2010, on Holidays in Maharashtra, the RTGS Special Interbank session form 7.00pm to 7.30pm, would not be there. However, with the new NEFT timings, this session will naturally be there.

In fact, the major challenges in the coming days, will be the well-being of employees operating in the Centralized Operations of Institutions.








LinkWithin

Related Posts with Thumbnails

Disclaimer

The thoughts in this BLOG are personal, and reflect only my view on the subject.
This are not the views of my Employers.
All images, logos rights rest with the Original TitleHolders

All efforts have been made to make this information as accurate as possible, N Prashant will not be responsible for any loss to any person caused by inaccuracy in the information available on this Website. Relevent Official Gazettes Communications may be consulted for an accurate information. Any discrepancy found may be brought to the notice of N Prashant