Choosing the right rail: a worked example

Consider a mid sized company in Bengaluru that needs to make four payments on the same morning, ten thousand rupees to a vendor who supplied office stationery, one lakh fifty thousand rupees to a consultant, twenty five lakh rupees to a supplier for raw material, and salaries to two hundred employees. A good analyst would not send all four through the same rail. The ten thousand rupee vendor payment could go through UPI if the vendor accepts it, or through IMPS if the payment starts from the corporate account. The consultant payment of one lakh fifty thousand rupees fits IMPS comfortably and will be credited in seconds. The twenty five lakh rupee supplier payment must go through RTGS because of its value and because the supplier needs final settlement today before dispatching the goods. This example shows the decision logic an analyst should apply to every payment requirement. First, ask the value. Below the RTGS minimum, RTGS is not an option. Second, ask the urgency. If the credit must happen in seconds, choose UPI or IMPS. Third, ask the volume. If there are hundreds of payments, choose a bulk system like NACH. Fourth, ask the operating hours. If the payment must move at midnight on a holiday, UPI, IMPS and RTGS are all available, because RBI RTGS has operated 24x7x365 since 14 December 2020, including weekends and holidays; the choice then turns on value and finality, not on the hour. Source: Reserve Bank of India, RTGS 24x7 availability from 14 Dec 2020. Fifth, ask the cost sensitivity. If the payment is low value and high volume, choose the cheapest rail that meets the timing need. Sixth, ask the finality requirement. If the payment must be legally final the moment it is sent, choose RTGS. Writing these six questions into the requirements document makes the rail selection transparent and reviewable, which is exactly what a payments BA is expected to do. The same logic applies to failure handling and customer communication. If the UPI payment to the vendor fails, the app should offer IMPS as the fallback and explain that the money will still arrive in seconds. If the RTGS payment is submitted after the cut off, the system should warn the user before submission and offer NEFT as the alternative with a clear statement of when the credit will happen. If the salary file has an error, the system should reject the file before submission with a clear list of the bad records, not after half the employees have been paid. These are the details that separate a payment product that works in a demo from a payment product that works in production, and they are the details this chapter has been building towards. Continue the worked example with the decision logic written out. The INR 10,000 vendor payment goes by UPI, because it is below the INR 1,00,000 per-transaction limit, it settles in seconds, and it costs the customer nothing. The INR 75,000 salary payment goes by NEFT as part of the monthly salary file, because it is one of many salaries, it does not need to settle in seconds, and NEFT has no per-transaction maximum. The INR 4,50,000 supplier payment goes by IMPS, because it is below the INR 5,00,000 IMPS limit and the supplier needs the money today. The INR 60,00,000 property payment goes by RTGS, because it is above the INR 2,00,000 minimum and needs immediate final settlement in central bank money. The decision logic is the same for every payment: first ask the value, then ask the urgency, then ask whether final settlement is needed, and the rail follows from the answers. Failure and recovery: if the UPI payment to the vendor fails because the vendor VPA is wrong, the app should offer IMPS as the fallback and explain that the vendor needs to confirm the correct VPA. If the NEFT salary file has one wrong account number, only that salary is returned, and the rest settle, and the payroll team must correct the one account and resend it. If the IMPS payment to the supplier fails because the beneficiary IFSC is wrong, the money is returned within hours, and the supplier must confirm the correct IFSC. If the RTGS property payment is queued because the bank has insufficient funds in its settlement account, the bank must fund the account before the cut-off, and if it cannot, the payment is rejected and the property transaction is delayed, which can break a chain of property purchases. RTGS is available around the clock, every day of the year, including weekends and holidays, since 14 December 2020, so a payment that must move at midnight on a holiday can use RTGS, subject only to the bank's own customer cut-off. Source: Reserve Bank of India, RTGS 24x7 availability from 14 December 2020. For a business analyst, product owner or subject matter expert, the test is to write the rail selection requirement as a decision table and to write the failure handling for each rail, because the two are inseparable. A requirement that selects the rail but does not state the failure mode will leave the customer with a generic error message and no way to recover. A requirement that states the failure mode but does not state the fallback rail will leave the customer stuck. The analyst must also state the value date for each rail, because a NEFT payment sent after the last batch settles the next morning, and a customer who expects same-day credit will complain. Source: Reserve Bank of India, Payment and Settlement Systems. Last reviewed 7 November 2026.