adsense

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.











No comments:

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