NEFT: batch settlement and why it still matters

NEFT is the Reserve Bank of India batch based system for transferring money between bank accounts across India. It is not a real time system. When a customer submits an NEFT payment, the sending bank collects it with other NEFT payments and sends the batch to the RBI at the next half hourly settlement window. The RBI settles the batch, the receiving bank gets the instruction, and the beneficiary account is credited. NEFT runs around the clock with batches every half hour, so a payment submitted just after a batch waits up to thirty minutes for the next one, and a payment submitted just before a batch moves quickly. That waiting time is the key difference from IMPS and UPI, where each payment is processed on its own. A single NEFT payment moves through five clear steps. Step one, the payer submits the payment with the beneficiary account number, IFSC, and amount, and the sending bank validates the details. Step two, the sending bank debits the payer account and holds the payment in its NEFT queue until the next batch. Step three, at the batch time the bank sends the batch to the RBI NEFT processing centre as structured financial messages. Step four, the RBI settles the batch between banks and forwards the credit instruction to the receiving bank. Step five, the receiving bank credits the beneficiary account and sends a confirmation back. The status at each step is explicit, accepted, queued for batch, settled by the RBI, or credited, and the payment is only complete when the beneficiary bank confirms the credit. The batch structure is what makes NEFT efficient for banks. They can validate, queue, and reconcile payments in bulk rather than handling each one as a separate real time event. Corporate customers use NEFT heavily for bulk payments, often uploading a file with hundreds of payments that the bank processes as a batch. Salary payments, supplier payments, rent, and other transfers where a delay of thirty minutes does not matter all fit NEFT well. Because the batch gives a natural control total, reconciliation is simpler than on a real time rail. The number and value of payments sent in a batch must match the number and value settled, and any mismatch is visible immediately. A failed credit in NEFT leads to a return of funds. The most common causes are a wrong beneficiary account number, an account that is closed, an account that is frozen, or an IFSC that does not match the beneficiary bank. When the receiving bank cannot credit the payment, it does not keep the money. It sends the funds back through the NEFT system as a return, travelling in the next available batches, with the reason for the return recorded. The sending bank then credits the returned amount to the payer account and informs the payer. Because returns also move in batches, a failed NEFT payment can take a few hours to come back, and the customer communication must set that expectation honestly rather than promising an instant refund. Timing and limits shape the customer promise on NEFT. The system rules set no minimum or maximum value, so a customer can send a small amount or a very large amount, although individual banks may set their own limits. NEFT is generally cheaper than IMPS and RTGS, and many banks offer free NEFT through digital channels, which makes it attractive for regular transfers. The credit usually happens within two hours of submission, counting the batch wait and the receiving bank processing time. The analyst must never let the screen promise instant credit for an NEFT payment. The screen should say the payment will be processed in the next batch and credited within a defined time, and it should show the batch timing so the customer understands the wait. The analyst must also design for the failure cases before launch. What happens if the beneficiary account number is wrong, what happens if the IFSC is wrong, how long a return takes, and who tells the customer. The requirements should cover the validation at entry, the batch cut off display, the return handling, and the reconciliation control totals for each batch. A bulk file with a wrong total or a bad record should be rejected before submission with a clear list of the bad records, not after half the payments have been sent. NEFT rewards careful batch design, and a team that treats it as a slow version of IMPS will build the wrong customer promise and the wrong operations process.