Scaling UPI Without Passing the Burden to Small Businesses

A request from a client

My answer was about technical feasibility. Adding a line to a bill is a small change for any point-of-sale system. Whether a restaurant is allowed to add that line is a separate question. NPCI's revised Merchant Discount Rate (MDR) framework for UPI, announced on 15 September 2026, introduces a 0.4% fee on eligible merchant payments above ₹2,000 from 15 October 2026 and bars merchants from passing that charge to customers as a surcharge. Menula has not built or enabled such a surcharge, and no customer's bill has changed because of this conversation.

What stayed with me was the reasoning behind the request. A restaurant owner facing a new operating expense looks for a way to recover it. That is ordinary business behaviour. It also shows why the question of who is charged first is different from the question of who eventually bears the cost.

What the fee means for merchants and customers

A rule against an explicit surcharge governs what appears on the bill. It does not, by itself, determine where the economic cost settles. A business may absorb the fee, adjust overall prices, encourage a different payment method, or respond in some other way. Which of these happens will depend on margins, competition, average order values and the share of payments that are eligible.

One owner's phone call cannot tell us what every business will do. It is a reason to measure outcomes for merchants and customers once the 0.4% MDR framework takes effect, rather than assume them.

It is also fair to recognise that payment businesses need sustainable funding. Running UPI at national scale costs money, and those costs have so far been carried by participants and partly offset by government incentive schemes: ₹8,276 crore in total between FY2021–22 and FY2024–25, and an allocation of ₹2,000 crore for FY2026–27. The useful question is how to fund the system efficiently and transparently, and which parts of the cost can be reduced.

Where the ₹20,000 crore goes

The fee has been justified by the cost of running UPI. NPCI has said industry estimates put that cost at roughly ₹20,000 crore a year, covering servers, bandwidth, fraud prevention and technical support at banks. Separately, the Department of Financial Services told Parliament's Standing Committee on Finance that the industry spends about ₹20,700 crore a year on merchant payments alone. Neither figure has been published with a breakdown by category or by participant.

What can be checked is how much NPCI itself spends, because NPCI publishes annual financial statements. That shows how much of the estimated cost could sit with the central operator, and how much must sit elsewhere.

Three things follow from the published numbers.

• Most of the cost is outside NPCI. Even if all of NPCI's spending on every product were counted, about 85% of the estimate would still sit with banks, payment service providers and apps. Their UPI costs are not reported separately.
• The central data centres are not the expensive part. NPCI's data-centre rent and power came to about ₹43 crore in FY2025–26, roughly 0.2% of the ₹20,000 crore estimate. NPCI runs its own data centres in Chennai and Hyderabad, and said in 2023 that they could handle 50 to 70 billion payments a month. The highest monthly volume so far is 23.2 billion, recorded in May 2026.
• The cost is repeated across banks. Each payment needs a debit at one bank and a credit at another, and each bank runs its own switch, core banking system, fraud controls, SMS alerts and support teams. NPCI's chief executive has said banks carry about ₹21,000 crore a year and pointed to sharp rises in server prices. This repeated bank-side infrastructure is where most of the ₹20,000 crore is likely to be spent, although no public breakdown confirms the split.

Comparison: today's model and one switch on 3 to 5 data centres

My view is that one national payment switch running from 3 to 5 data centres across India, with shared services for participating banks, could handle UPI's scale, redundancy and growth for considerably less than today's estimated annual cost. NPCI's two data centres already carry UPI at national scale. The proposal, described in full later in this article, brings UPI, IMPS, NEFT and RTGS onto one switch and offers banks shared services on the same sites.

In this scenario, costs rise in the first year before they fall, because the shared sites and the migration have to be paid for before banks move across. How much is saved depends mostly on how much of today's bank-side cost the shared service can actually replace. That is the figure a pilot should measure first.

How a UPI payment travels

For the person paying, UPI feels like one tap. Behind that tap, several organisations exchange messages. In a simplified standard bank-account payment:

1. The customer starts a payment in a UPI app.
2. The app and its PSP (payment service provider) bank connectivity route the request into the network.
3. NPCI's UPI switch coordinates the payment messages between participants.
4. The sender's bank validates the request, records the debit in its core banking system (the bank's main account ledger) and returns a result.
5. After a successful debit, the recipient's bank processes the credit and returns its result.
6. Status is communicated to the participants. Notifications may involve the recipient's app and PSP.

Real payments involve more than this. Address resolution, risk controls, settlement and exception processing add further steps, and some roles can be performed by the same bank. Customer deposits do not travel through NPCI as if it were a wallet. NPCI carries the messages; the money stays in bank accounts.

Where delays can arise

A fast central switch does not remove the dependency on each participating bank's payment switch and core banking system. If either bank's systems respond slowly or are unavailable, the payment can be declined or its status can remain uncertain. At a restaurant counter, that means a waiting customer and a staff member unsure whether to hand over the bill as paid.

Bank-side systems are not the only possible point of failure. App and PSP availability, network connections and NPCI's own services also matter. Capacity limits, database contention, integration design and outages are engineering questions to investigate bank by bank. They are not a diagnosis that applies to every bank.

NPCI's published statistics distinguish technical declines from business declines. Invalid credentials, insufficient funds or a crossed transaction limit are business declines, and they say nothing about overloaded infrastructure. When the beneficiary bank does not return an online credit confirmation, the payment can enter a pending or deemed-approved state. A missing confirmation alone does not mean the money was lost.

What the ecosystem pays for

Public discussion of the fee has often reduced UPI's cost to servers. Servers matter, but they are one part of a wider set of expenses. The table below separates the main categories and the kinds of improvement worth evaluating in each. It does not assign amounts to any category; no verified public breakdown of that kind is available to us.

Payment companies earn commercial benefits from UPI, such as customer reach and the ability to sell lending, insurance or other services. Those benefits deserve to be weighed alongside expenses. Cross-selling, however, does not prove that the infrastructure is already fully funded. Separating essential operating costs from commercial spending would make the funding discussion clearer for everyone.

A per-payment figure, read with care

NPCI has attributed the roughly ₹20,000 crore annual figure to industry estimates. As the breakdown earlier in this article shows, it is not an NPCI budget and has no published breakdown by category.

The same annual volume works out to about 7,662 payments per second averaged across a 365-day year. Infrastructure is not sized to an average. Peak demand, multiple messages per payment, status queries, retries, durability, replication and failover decide what is actually needed. Core payment processing runs on CPUs and can avoid GPU spending, yet storage, networking, security, staffing and resilience remain substantial. Fraud systems may use separate compute resources. The scenario model earlier in this article uses openly stated assumptions for that reason; a real estimate would need a workload model and supplier quotes.

The lesson from UPI Lite

UPI Lite shows how a prefunded balance can reduce the need to debit a customer's main bank account for every small purchase. The customer allocates funds from their bank account into a Lite balance. The issuing bank holds the backing funds, and the app's common library maintains the Lite balance on the device. Funding and topping up the balance still involve the bank's systems, and the recipient's credit path is still relevant.

Lite does not remove banks, does not move money into NPCI, and should not be described as making every Lite payment work without the internet.

Why a bank account cannot simply become a Lite balance

A normal bank account is also used by debit cards, ATMs, transfers and other channels. If its balance were copied into a separate payment system and reconciled later, the same money could be spent twice: once through UPI and once through a card, before the two records caught up. There are only two safe designs. Either the funds are reserved for the separate balance, as Lite does, or every channel respects one authoritative account ledger.

One switch for every payment

Today, India's main electronic payment systems run on separate central switches. UPI and IMPS are operated by NPCI; NEFT and RTGS are operated by the RBI. Each has its own message formats, connections, certification and monitoring, and every bank connects to each of them separately. A payment's journey is similar in all four: a debit at one bank and a credit at another.

I propose a single national payment switch for all of them: UPI, IMPS, NEFT and RTGS routed through one central system, run by either the RBI or NPCI, from 3 to 5 data centres across India. Each bank would make one connection instead of four, to one message standard, with one place to monitor and reconcile every payment. The rules that make each payment type different, such as NEFT's batches or RTGS's high-value limits, would continue as rules within the switch rather than as separate systems.

What changes, and what stays the same

• One connection per bank. Banks build, test and certify one integration instead of four. Smaller banks, which find repeated integration hardest to fund, benefit most.
• One view of every payment. Pending, failed and reversed payments across all types can be tracked in one place, which should shorten the time to fix exceptions and refund customers.
• Capacity shared across payment types. Demand peaks at different times for different payment types. One switch sized for the combined load, across 3 to 5 sites, can use its capacity more fully than four systems each sized for their own peak.
• Settlement stays with the RBI. Money between banks would still settle through their accounts at the RBI, as it does today. The switch changes how payment messages are routed and processed, not where money is held.
• Bank ledgers still matter. A single switch does not remove the need for each bank to debit and credit accounts reliably. The optional shared ledger services described below address that side.

Who runs it: the RBI or NPCI

Either could operate the switch. The RBI already runs NEFT and RTGS and holds banks' settlement accounts, which suits high-value payments and systemic oversight. NPCI already runs UPI and IMPS, which carry most retail payments by volume, and has experience scaling them. The choice would be a policy decision, and either route needs the other involved from the start. Consolidation also brings a risk that has to be designed against: a single switch must not become a single point of failure, which is why it needs several independent data centres, tested failover and clear accountability for outages.

Optional services for banks

Alongside the switch, banks could choose to adopt shared bank-side services built to the same standard:

• Shared connectivity and monitoring. Certified adapters, reconciliation and monitoring, so each bank does not build its own.
• A modern account ledger. Bank-owned account records on resilient shared infrastructure, used by every channel, including cards and ATMs. This is a major banking migration and would be optional.

Each bank's data would stay isolated, with its own customers and regulatory duties. Banks able to fund onboarding upfront could pay a setup and migration fee; others could use an annual subscription. Either way, operations, security and capacity need ongoing funding.

These are possibilities to test, not promised results. A move of this size would start with a pilot on a limited set of banks and payment types.

A measurable path forward

A national migration should not be the first step. I would start with a limited pilot: measure where failures and latency actually occur, then test shared components with willing banks and a controlled workload.

A pilot should track:

• Technical decline rates, kept separate from legitimate business declines
• Debit and credit response latency
• Payments with missing confirmation, and reversal time
• Verified cost per successful payment
• Peak-load capacity and failover performance
• Merchant costs and customer outcomes alongside the technology metrics

Funding options can be tested in parallel: transparent shared-service pricing, public support aimed at inclusion, contributions from ecosystem participants, and clearly funded essential access. No single model guarantees zero MDR or a fixed percentage reduction in total cost. The point of a pilot is to replace assumptions with evidence.