How the rails differ: limits, timing and cost

The fastest way to compare the Indian rails is to put them side by side on four questions. How fast is the credit, what is the value range, when does the system operate, and what does it cost. UPI credits in seconds, works around the clock, and is free for most person to person payments, but it has per transaction and per day limits that vary by bank and use case, typically around one lakh rupees per transaction for most customers; NPCI raised the limit to 5 lakh rupees for specified categories, including capital markets, insurance and verified merchants, in December 2024. Source: NPCI UPI limit circular, Dec 2024. IMPS also credits in seconds and works around the clock, but it allows higher values than UPI, typically up to five lakh rupees per transaction, and it usually carries a small charge. NEFT credits within a few hours through half hourly batches, works around the clock, has no system maximum, and is usually free or very cheap through digital channels. RTGS credits in real time around the clock, has a minimum of two lakh rupees and no maximum, and carries the highest charge of the four. Timing is where analysts most often make mistakes, because the words instant and same day mean different things on different rails. UPI and IMPS are instant in the sense that the beneficiary account is credited within seconds under normal conditions. NEFT is same day in the sense that the payment will be settled in a batch and credited within a couple of hours, but it is not instant. The analyst must state the rail and the service level in every requirement. RTGS is available around the clock, every day of the year, including weekends and holidays, since 14 December 2020, so a payment submitted after a bank's own customer cut off is processed in the next cycle, not the next working day. NACH is not instant at all. It is a one to two day cycle designed for scheduled bulk payments. A requirement that says instant payment must be translated into a specific rail and a specific service level, or the development team will build the wrong thing and the customer will be disappointed. Cost and limits are not fixed forever, so the analyst should treat them as configuration rather than hard coding them into requirements. The Reserve Bank and NPCI change limits and charges from time to time, and individual banks set their own limits within the system rules. A good design stores the limits in a configuration table, shows the current limit to the customer before they type the amount, and gives a clear error when the amount is above the limit for the chosen rail, including a suggestion to use another rail. The same principle applies to cut off times. Show the cut off, warn the customer when they are close to it, and offer the alternative rail that will still meet the deadline. These small design decisions are what make a payment product feel reliable instead of frustrating. Take a worked example with real numbers. A company must pay INR 50,000 to a supplier, INR 5,00,000 to a contractor, INR 25,00,000 to a vendor, and INR 1,00,00,000 to a property seller, all on the same morning. The INR 50,000 supplier payment goes by UPI, because it is below the INR 1,00,000 general per-transaction limit and settles in seconds at no cost to the customer. The INR 5,00,000 contractor payment goes by IMPS, because it is at the IMPS per-transaction limit and settles in seconds. The INR 25,00,000 vendor payment goes by NEFT, because it is above the IMPS limit and does not need to settle in seconds, and it settles in the next half-hourly batch. The INR 1,00,00,000 property payment goes by RTGS, because it is above the INR 2,00,000 minimum and needs immediate final settlement. The four payments cost different amounts, settle at different speeds, and carry different finality, and the analyst must be able to explain each difference to the business. Failure and recovery: a payment sent on the wrong rail fails in a way that is specific to that rail. A INR 5,00,000 payment sent by UPI is rejected because it exceeds the per-transaction limit, and the customer must split it or use IMPS. A INR 50,000 payment sent by RTGS is rejected because it is below the INR 2,00,000 minimum, and the customer must use UPI, IMPS or NEFT. The requirement must enforce the limits in the product, so the customer cannot select a rail that cannot carry the payment, and the error message must name the correct rail. A NEFT payment sent after the last batch of the day settles the next morning, and the customer must be told the value date, not just that the payment was sent. An RTGS payment sent when the bank has insufficient funds in its settlement account is queued, and if it is not funded by the cut-off it is rejected, and the customer must be told to retry. The recovery is always to choose the right rail for the value and the urgency, and the requirement must enforce the limits so the customer cannot choose the wrong rail. For a business analyst, product owner or subject matter expert, the test is to write the rail selection rules for a product as a decision table, with one row per value band and one column per rail, and to state the limit, the timing, the cost and the failure mode for each cell. The limits are configuration, not hard-coded constants, because the Reserve Bank and NPCI change them, and the requirement must state where the limits are configured and who can change them. A product that hard-codes the UPI limit will break when NPCI raises it, and a product that does not state the RTGS minimum will allow a payment the rail cannot carry. Source: Reserve Bank of India, RTGS and NEFT directions; NPCI, UPI and IMPS limits, December 2024. Last reviewed 7 November 2026.