By Swapneswar Sundar Ray, Independent Researcher and AI Systems Engineering Leader, Financial Services, Randolph, New Jersey, USA
UPI has already solved the first problem: getting money from one bank account to another in seconds, through an interface ordinary people will actually use. That achievement is easy to understate. Many payment systems are technically capable; far fewer become part of daily life. The harder phase starts now. Once instant payment becomes normal, users stop noticing the rail and start noticing everything around it:
Was the payment genuine?
Can I get help if I was tricked?
Why was my transfer blocked?
Can I send money across borders without learning a new app?
Those questions will shape UPI’s next decade more than shaving another fraction of a second from processing time. I work around AI, APIs and financial systems, and I have learned to be suspicious of any payment story that sounds too clean. The transaction itself is usually the easy part. Identity, exceptions, retries, fraud, disputes and accountability are where the system earns trust—or loses it.
The hard part
A real-time payment gives the risk engine almost no breathing room. In batch or slower card workflows, a suspicious event may sit in a queue long enough for additional checks. With instant payments, funds may move through several accounts before an investigator opens the case. That changes the design problem. The industry has spent years improving transaction scoring: amount, location, device, time, merchant and prior behavior. That still matters. But mule networks and social-engineering scams rarely announce themselves in one neat transaction. The useful signal is often in the connections between accounts, devices and beneficiaries, or in the speed with which money disperses after it arrives. AI is well suited to that kind of pattern recognition, especially graph analysis and behavioral modeling. It is less well suited to acting as an unchallengeable judge. A model can flag a network, summarize an investigation or suggest the next check. Someone still needs to understand why the alert fired, what evidence supports it and what happens to the customer if the model is wrong.
One lesson from an API program
On one enterprise API program I worked on, we reduced onboarding effort by automating test setup, documentation support and integration guidance. The result looked good on the dashboard: fewer manual handoffs and faster progress for consuming teams. The more important discussion came later. If the automated assistant gave an incomplete answer, could an engineer still trace the request through the system? If the tool was unavailable, did the team remember the manual path? That experience has stayed with me because real-time payments are heading in the same direction. Automation can remove friction, but every layer it hides can also become a layer fewer people know how to inspect. In a payment system, that is not an academic concern. It affects incident recovery, dispute handling and the ability to explain a decision to a regulator or customer.
Cross-border: where does the complexity go?
UPI’s cross-border expansion is often described as a simple extension of domestic success. It is not. Domestic instant-payment systems sit inside one legal, identity and settlement environment. Cross-border payments bring foreign exchange, sanctions screening, data localization, consumer-protection rules and different approaches to finality. The Bank for International Settlements’ Project Nexus is interesting because it looks at a hub model for linking domestic instant-payment systems rather than building endless bilateral connections. That is the right architectural question. A customer should see a familiar payment experience, while the infrastructure handles the ugly coordination underneath. There will still be arguments over fees, liability and which data can cross a border. Those are not side issues. They are the work.
Invisible payments
Embedded finance will make many payments feel less like payments. A supplier clicks an invoice. A driver completes a trip. A marketplace releases funds. A software agent renews a service within a limit set by the user. The payment instruction is buried inside another task. This is convenient until the customer no longer knows what was authorized. Consent has to become more precise: amount, purpose, frequency, expiry and who may initiate the transaction. A recurring mandate should be understandable without a lawyer, and revocation should not require a treasure hunt through menus. I expect this to become one of the less glamorous but more important UPI 2.0 questions. The interface may disappear; the obligation to explain the payment does not.
What about tokenisation?
Tokenization can add useful programmability, particularly for escrow, conditional release, supply-chain settlement and delivery-versus-payment. But it is easy to turn that idea into a technology parade. Most businesses do not want a new form of money for every workflow. They want the payment to settle, reconcile and survive an audit. The practical route is likely to keep regulated bank money at the center while using tokenised instructions or assets where they solve a specific problem. Programmability is valuable when it reduces reconciliation or counterparty risk. If it creates another closed pool of value that cannot move easily, the industry has rebuilt the fragmentation it was trying to remove.
CBDC versus UPI?
I do not see this as a winner-takes-all contest. UPI is a payment rail. The digital rupee is a form of sovereign digital money. One can move value; the other defines what form that value takes. There are use cases where a CBDC may offer useful properties, including programmable public money or offline capability. There are also millions of users who simply want their current bank account and payment app to work. The sensible outcome is coexistence, with interoperability strong enough that most people do not need to care which regulated instrument sits underneath a transaction.
Disputes are part of the product
Payment teams tend to talk about success rates. Customers remember the one transfer that went wrong. In real-time payments, support and recovery have to operate with the same urgency as authorization. A person who has been manipulated into sending money cannot wait days for the bank, app provider and recipient institution to decide who owns the case. India has already moved toward online dispute-resolution mechanisms for digital payments. The next challenge is operational: rapid reporting, coordinated holds where legally possible, traceability through linked accounts and a clear handoff between institutions. This does not guarantee recovery, and it should not become automatic reversal of every disputed transfer. But the current experience is still too fragmented in many markets.
What other countries should copy
The obvious answer is QR codes and instant settlement. The better answer is the shared layer underneath: common standards, broad participation, dependable settlement and room for competing customer experiences. UPI works because banks and applications can innovate without asking the customer to understand the plumbing. Other countries will adapt that model to their own regulation and banking structure. Some will move faster on open banking. Others will emphasize public infrastructure or private networks. The lesson is not to clone the screen. It is to make interoperability a starting condition rather than a feature added later.
Where this goes next
The next version of real-time payments will be judged less by whether a transfer completes and more by how the system behaves when the situation is messy. A fraud model is uncertain. A customer was deceived. A cross-border message is incomplete. An embedded payment was technically authorized but poorly understood. UPI has shown what happens when instant payments become infrastructure rather than novelty. The next step is less tidy: joining fraud intelligence, consumer protection, interoperability and new forms of digital money without making the experience harder for the person using it. That is where the real engineering—and most of the policy debate—now sits.
About the author
Swapneswar Sundar Ray is an independent researcher and AI systems engineering leader with more than 15 years of experience in financial services and enterprise technology. His work spans machine learning, generative AI, payments fraud management, electronic trading, API platforms, responsible automation and operational resilience. He is the author of books on enterprise AI transformation and retrieval-augmented generation. The views expressed here are his own.
References
- National Payments Corporation of India — Unified Payments Interface Overview
- Reserve Bank of India — National Strategy for Financial Inclusion 2025–30
- Bank for International Settlements — Project Nexus: Enabling Instant Cross-Border Payments
- Bank for International Settlements — Fast Payments: Design and Adoption
- Bank for International Settlements — The Next-Generation Monetary and Financial System
- Reserve Bank of India — Digital Rupee (e₹) FAQs
- Bank for International Settlements — Central Bank Digital Currencies and Fast Payment Systems: Rivals or Partners?
