Lessons for FedNow from India's UPI miracle
Table of Contents
Summary
In 2023, Federal Reserve of USA plans to launch 'FedNow' – a peer-to-peer payment network with instant settlement. This essay reviews the experience of India's Unified Payments Interface (UPI) – one the world's most successful publicly operated P2P instant-settlement payment networks – and identifies key lessons for FedNow.
Two features were central to UPI's revolutionary success:
- The modular design of UPI's backend made it easier for banks to integrate into the UPI network.
- UPI's unbundling of the 'servicing' of customer accounts from the 'ownership' of such accounts created opened significant UX and regulatory arbitrage and opened the door for mammoth investments by Google Pay, PhonePe and other customer-facing applications.
The lessons for FedNow are straightforward:
- Design developer tooling to provide a smoother integration experience for potential member banks. USA's financial system is extremely fragmented compared to India, with deposit taking banks numbering over 10,000 – without appropriate tooling, comprehensive coverage may take several years to achieve.
- Unbundle 'servicing' from 'control' of customer accounts, and allow third party access to 'servicing' APIs.
The UPI miracle and some questions
The UPI, or Unified Payments Interface, is a semi-public payments protocol operated by an umbrella organization of India's banks; think Visa but for mobile payment and operated by a public-ish entity. UPI moves about 10 % of the total retail payment volumes in India — that's about 3.5Bn transactions per month. UPI apps, which include Google Pay, Amazon Pay, and Facebook's Whatsapp have more than 150 Mn active users between them.
Looking back, the rise of UPI in India has been nothing short of a miracle. Less than five years ago, in 2016, India retail customers made transfers worth $3.2 Trillion. Most of these funds were transferred using NEFT, which clocked around 100 Million transactions a month. Card network transactions were growing at 30% per year, and PayTM was fast emerging as the preferred mode of peer-to-peer payments. Fast-forward to the present, and UPI strides upon the Indian payments arena like a Colossus; IMPS, and the card networks lie vanquished. Private payment players like PayTM have mostly joined forces with UPI. Card networks actually lost share in transaction value in this intervening years. The UPI has truly become the one interface to rule all payments.
How did this happen? How did UPI – owned and operated by a quasi-government entity of all governance structures – come to dominate digital payments in India, building a customer base of several 100 millions of users, all within a span of 4 years? For context, it took Facebook and Twitter, with all their virality and global reach, the same time to reach 100 million users.
What explains this radical, miraculous success of UPI? While the fall in costs of data and smartphones that occurred after 2010 was a necessary condition for the emergence and growth of UPI, that alone cannot explain why UPI emerged as the preferred payment mode over other incumbents such as the Central Bank operated IMPS. Even though may rightly point to the demonetization of Indian currency in 2016 as a cruel catalyst for the initial adoption of UPI, that alone cannot explain UPI's sustained growth since then, or the decline of Paytm — the dominant payment incumbent at the time of demonetization with a wider network of merchants.
I propose that UPI's success boils down to two design decisions at the heart of the protocol's design:
- At the technical level, UPI's minimalistic backend interface required banks CBSs to implement only two APIs to integrate into UPI. This minimized the effort required to onboard banks onto the UPI network.
- At the customer-facing level, UPI made it possible for customers to securely operate their accounts held a regulated banks through applications designed and operated by non-Bank, unregulated entities like Google Pay. This arbitrage in regulatory overhead without a trade-off in delightful customer experience by this decision was the biggest reason for the success of the success of UPI.
UPI's Secret Sauce
Smoother integration with banks via containerized applications
At the bare-metal level, UPI's underlying code was designed to minimize the integration effort it took for banks to join the network. Integration efforts are one of the biggest blockers in the path of substantive improvements in Indian banking. For instance, in 2019, when the Indian government merged six state-owned banks, the choice of which banks to merge with which other boiled down to the technological compatibility of their respective backend systems.1 To avoid the same fate, the UPI team needed to make it easy for banks to plug into the network they had created, irrespective of their backend technology. Their solution was to develop a ready-made software module to handle most of the core administrative tasks involved in processing transactions, along with minimizing and standardizing the points of contact between this module and the rest of the bank's core-banking systems.
Consider the life cycle of a customer on a payments network. Such a customer would first need to register herself and link her registered identifiers like a unique handle and a look-up to an underlying account, that customer would also need to set some kind of authentication mechanism for transactions, and of course, she should be able to perform debit transactions, receive credit transactions, and also perform ancillary services such as fetching the balance of her linked account and a list of past transactions. All of these routine administrative tasks and operations could be standardized and externalized into a single module, instead of asking the banks to develop their custom implementations. Even if banks could reliably implement those tasks and operations, idiosyncratic variations between the implementations of each bank lead to conflicts and roadblocks in the future developments of UPI.
The UPI team's solution leveraged a concept known as 'containerization', where the code and the surrounding environment required for an application is contained within an 'installer'. Think of a container as an installer file for a PC game, but, instead of just installing the game, the installer first spins up a virtual machine with the appropriate operating system and other dependencies installed and then installs the game/application. This container installed the 'UPI switch' as the team described. It was the 'UPI switch' that was responsible for handling most of the heavy lifting involved during various stages of the customer life-cycle. the UPI team created the UPI network around a UPI switch, a containerized application (think of this as an installer, like a .exe or a .dmg file) which handles all of the heavy lifting involved in the customer life-cycle, reducing the interfaces with bank's IT systems. In fact, under this approach, the bank IT system only needed to provide interfaces to debit a customer's account and to check the balance in the customer's account. This central UPI switch was designed as a containerized application deployed on-prem on the bank's compute infra.
The UPI switch then operated as a collection of micro-services handling administrative tasks such as registering users and their PIN. Transaction authentication happened via a PIN input by the customer on their device. Once again the UPI Switch micro-service performed the authentication of the input PIN without the bank CBS having to step in. Such a micro-service reduced the integration required between UPI and the specific CBS systems of banks, allowing the entire UPI network to function with just three end-points connected to bank CBSes – one to look-up customers, one to check the balance of a given account, and another to debit an account. The IT vendors of banks were free to implement the back-end for these end-points in whatever manner worked best for them.
The net effect of all this to solve one part of the 'cold-start' problem involved in starting up a two-sided network from scratch. With bank onboarding a solved problem, the UPI team could now focus on attracting customers.
Unbundling 'servicing' from 'ownership' of customer accounts:
While a smoother onboarding of banks was one part of the 'cold-start' puzzle, UPI still had to solve the problem of acquiring customers. And here, the UPI team correctly perceived that acquiring customers was not a task to be left to the Government, Government-owned banks, or even incumbent private banks. Instead they designed the UPI APIs and SDKs such that third party applications could enjoy authenticated 'Write' access to the underlying accounts of the customers maintained with incumbent banks.
The UPI team's decision would later pay the way for the arrival of giants such as Google Pay and Amazon Pay, who spent considerable marketing budgets acquiring customers and merchants. The market share of various payment apps serves as a progress card for the decision to unbundle 'servicing' from account ownership. As the figure below shows, the UPI landscape in India is entirely dominated by the top-3 apps enjoying a cumulative ~85% share of transactions and value. The share of transactions processed by all 150 banks on the UPI network barely exceeds 3%. Despite the head start banks enjoyed in onboarding customers through their mobile banking applications, the largest UPI-based payment apps in India are private fintech players such as Google Pay, PhonePe and Paytm. Rather characteristically, the banks have been beaten hands-down in the game of onboarding and delighting customers, a fate the UPI team, presumably could've claimed to see from miles away.
Funnily enough, surprisingly few analysts have identified this unbundling as a major factor behind the success and growth of UPI.2 Instead, a lot of attention was devoted to the falling cost of data and cheaper devices as the reasons for UPI's success. All of those factors could also have allowed PayTM's private network to monopolize India's mobile payments, but instead it is UPI that emerged triumphant, with PayTM eventually joining the network.
The 'first-class' citizenship offered unregulated private fintechs made it possible for the likes of Google Pay to enable a customer to onboard themselves and to transact using their account entirely from within Google Pay, without any involvement of the underlying bank's systems or interfaces; the UPI stack offered a self-contained transactions suite. Similar to local loop unbundling in public utilities like power, distribution was separated from 'generation'. Unlike in USA, where Google Pay and Apple Pay achieved such disintermediation by leveraging NFC to emulate debit/credit cards within customers' devices, supporting customers on UPI required no such workarounds. Customer facing applications were first class citizens of the UPI ecosystem, by virtue of the separation of concerns between customer on-boarding and customer account operation.
In the final analysis, this direct access to 'Write' APIs on top of the customer's bank accounts is what helped UPI beat PayTM. PayTM, initially designed as a wallet, continued to require users to first make a deposit into their PayTM wallet/ account, and then perform transactions from that wallet/account. UPI on the other hand removed the need for customers to 'load an intermediary wallet/ account' before performing a transaction. Users could now move money on the fly via UPI. 'Write' APIs for user's bank accounts continues to be elusive in India's highly conservative and paternalistic banking ecosystem, a fact highlighted in a previous post on CBDCs in India.
The regulatory and UX arbitrage in allowing customer facing applications to distribute financial products is a gift that keeps on giving. The march of disintermediation beats on inexorably, spreading from relatively peripheral P2P transactions to online and ecommerce transactions, to investments now, and soon (potentially) to credit. Consider the case of Fixed Deposits in India, and the stunning success of Equitas Bank's launch of their FD product on Google Pay3. All this in a product without the network effects of a payment protocol/ network. Nothing can stop the juggernaut of a well-designed product combined with word-class distribution.
Generous servings of luck and network effects
As the sections above illustrate, UPI had all the right ingredients to create magic. However, it still took the entry of a behemoth, in the form of Google Pay, to evangelize and market the protocol. Without Google's aggressive cashback offers (users could receive between INR 20-100 for each transaction they performed) and extensive merchant acquisition, it's hard to see UPI reach its current levels of usage. To be clear, UPI did create its own luck. The massive regulatory and UX arbitrage created by allowing unregulated applications to service customer bank accounts is what opened the doors for Google Pay; without that crucial technical and governance decision, Google would've probably balked at applying for some curmudgeonly license, and the UPI we see today would still be an underdog if not an also-ran.
Google Pay's scorched earth marketing and customer acquisition campaigns created the critical mass of customers UPI needed for 'lift-off'. Once this critical mass was reached, the network effects inherent meant that not too long after, merchants would also start joining the UPI network. The transition from offline merchant collections to online collections was even smoother, thanks to the robust, extensible API provided by UPI's API specifications. As to why Google decided to bet big on a nascent payment protocol in a relatively peripheral market, we can only speculate. Perhaps, having an Indian CEO may have helped.
Lessons for FedNow
So, what should we and FedNow take away from UPI's success story.
- Making it easier for members to join you network is vital. Particularly in a banking space as fragmented as the USA with over 10,000 deposit taking institutions.
- Separation of account 'servicing' from 'ownership' + First-class citizenship for customer-facing applications. Almost all UPI's success have come from a deliberate strategic choice to become a playground open to all instead of trying to compete with extant networks out there. To do this, UPI needed to force legacy participants to open up their customer bases to be served by new-age fintech applications.
The United States' mobile payments market appears similar to India's payments market before UPI. We see the same cast of a few rickety, unpopular payments rails that stifle mobile payments, a few closed-loop wallets that charge exorbitant amounts to withdraw your own funds, and a growing reliance on card networks. If FedNow learns its lessons and plays its card rights, the biggest payments market in the world will experience nothing short of a revolution.