What Interoperability Actually Changes
To see why interoperability can alter competition in retail digital payments, follow one payment rather than compare app logos. This chapter focuses on the boundaries between a user-facing app, the payment rail, the banks, and the payee. By tracing those responsibilities, the reader can tell which part of a payment is being opened to competition—and which network effects remain in place.
One payment, several responsibilities
A digital payment has a visible beginning and a less visible middle. A person opens an app, scans a code, or enters a recipient’s details. Behind that action, a retail payment system routes, authorises, and clears the transaction. Banks or other payment service providers then settle obligations between financial institutions. The interface is important, but it is only one component of the system.
A closed-loop system keeps these components under one provider’s commercial roof. The payer uses the provider’s app or wallet, and the payee must be reachable within the same provider’s network. In a typical wallet arrangement, both parties hold a balance or account with that provider. The payment can be convenient once the network is established, but the provider’s user base is part of what makes the product valuable: every additional user creates another possible counterparty.
That requirement changes the user’s decision. Suppose a person prefers App A because its language support is better, while the merchant they need to pay uses App B. If the two systems do not connect, choosing App A may make the payment impossible. The person must either persuade the merchant to join App A, maintain another app, or use cash. The app with the largest existing network has an advantage that is not necessarily related to reliability or design quality. It is valuable because everyone else is already there.
UPI separates the user-facing choice from that counterparty constraint. The IMF’s description of UPI presents it as an instant-payment platform built over India’s existing Immediate Payment Service infrastructure. Banks and third-party application providers can use the interface to exchange payment messages. A payer can therefore open one provider’s app and send money to a payee reached through another provider’s app. The underlying funds remain in users’ bank accounts rather than needing to be held in the app provider’s wallet.
The distinction is easiest to see as a pair of transaction paths:
In the interoperable path, the app that handles the payer’s interaction need not be the app that handles the payee’s interaction. NPCI sits between the participants and ensures that the payer’s and payee’s banks debit and credit the appropriate accounts. In a simplified example, up to four distinct participant organizations may be involved: the payer’s provider, the payee’s provider, the payer’s bank, and the payee’s bank. A third-party application provider, or TPAP, supplies the user-facing service through a partnership with a payment-service-provider bank connected to the underlying rails. The app, the bank, and the system operator are related, but they are not interchangeable.
This is why interoperability is more than a technical adapter. The IMF defines it as technical, semantic, and business compatibility. Technical compatibility means that systems implement standards that allow hardware and software to interact. Semantic compatibility means that the information exchanged is interpreted consistently. Business compatibility means that participants agree on access, obligations, clearing, settlement, and how to handle failures. If an app can technically send a message but the provider cannot access the rail on fair terms, or participants have no agreed way to resolve a failed transaction, the user does not experience a genuinely open system.
The design also differs from some earlier arrangements that were already partly connected. Before UPI, users could make certain bank-to-bank transfers through IMPS, move money between some bank accounts and electronic wallets, or transfer money within a single wallet provider. They could not necessarily use a third-party app to initiate transfers between bank accounts, or move between wallets belonging to different providers. UPI expanded interoperability along those dimensions by allowing participating TPAPs to interact with the common interface through partner banks.
The key change is therefore not that UPI makes every provider perform the same function. It allows different providers to perform different functions while preserving the connection needed for the payment. That division can support specialization: one firm can concentrate on a user-friendly interface, another on banking access, and a shared system on routing and settlement rules. The arrangement also makes responsibility more distributed. The payment can be initiated in one place, authorized through a common system, and reflected in accounts held elsewhere. The result is potentially more choice at the front end, but also a need for clear rules about access, failure, and accountability across the boundaries.
Consider what the payer experiences when a cross-app payment succeeds. The payer’s app collects the instruction, the provider and its partner bank connect it to the common interface, the shared system directs the message, and the two banks update the relevant accounts. The payee’s provider then displays the result. None of those steps needs to look like a separate product decision to the user. But each is a dependency. If access is restricted, the message is interpreted differently, or participants do not agree who handles a failed transaction, the user’s apparent choice of app can become meaningless. The competitive value of the front end depends on invisible cooperation underneath it.
This also explains why “open” cannot mean only that a provider is technically capable of sending a payment message. The business arrangements determine who may connect, which obligations each participant accepts, and how the system behaves when a payment is delayed or rejected. Those rules affect whether a smaller provider can offer a credible alternative. A common rail can make several interfaces possible, but fair access and predictable handling of failure are what make those interfaces usable substitutes rather than decorative choices.
The separation of roles changes the economics of the market as well. A provider does not need to reproduce every function of the payment system in its own closed network before it can present a service to users. The shared infrastructure handles the common connection, while different organizations can compete over the part of the experience they are best positioned to improve. That may be interface design, trust, access to a particular customer group, or the way the service communicates a successful payment. The system gains from specialization only if the boundaries remain dependable; otherwise, users bear the cost of coordination that the shared rail was meant to remove.
Where the network effect lives
The competitive consequence follows from the location of the network effect. In a closed loop, the provider’s own user base determines how many people a customer can reach. Growth reinforces the provider: more users make the service more useful, which attracts more users. A rival may offer a better interface, but it begins with a smaller set of reachable counterparties. To become viable, it may need to attract both the payer and the payee in the same interaction, or persuade an entire group to coordinate on the new network. This is the familiar “everyone is already there” barrier, but in payments it affects the basic ability to transact.
Interoperability weakens that app-level feedback loop. A new app does not need to reproduce the full set of counterparties before it can offer value. A user can select it for trust, accessibility, features, or reliability while continuing to pay people who use other apps. The value created by additional participation is not captured only by the provider that first recruited the user. It enlarges the set of possible connections across the shared platform.
That does not eliminate network effects. It changes their level. The shared rail becomes more useful as more banks, providers, consumers, and merchants connect to it. This can create a virtuous cycle for the overall platform without making one particular front end the only practical choice. The distinction matters because platform growth and provider dominance are different outcomes. An interoperable platform can become large while the user-facing market remains contestable—or it can become large while a few interfaces learn how to recreate their own barriers.
The merchant side makes the boundary especially important. Person-to-merchant payments are a two-sided market: merchants value an app or card when many customers use it, while customers value it when many merchants accept it. Without interoperability, a provider may use that mutual dependence to build a strong position on both sides. A merchant that accepts only one system loses potential customers; a customer that carries only one app loses potential merchants. The two groups can wait for each other, producing a coordination failure that protects an early incumbent.
An interoperable rail can lower that coordination pressure because the merchant does not need to know which app a customer uses, and the customer does not need to adopt the merchant’s preferred app simply to complete a payment. That makes partial participation useful. A provider can first serve a particular customer group or offer a differentiated interface, then develop merchant relationships later. It can compete for one side without immediately rebuilding the whole network. This is one reason interoperability can make entry more credible even when the rail itself remains costly to build and operate.
The shared-platform benefit has limits. Retail payment systems require substantial fixed investment and process transactions at scale. Their value depends on participation by banks, non-banks, consumers, and merchants, so a rail can still tend toward concentrated or even natural-monopoly structures. The BIS Bulletin on competition in retail digital payments emphasizes that contestability has increased in many economies, partly because fast payment systems offer alternatives to card networks, but entry alone does not guarantee effective competition. In advanced economies, incumbent card networks have retained important positions even as new digital interfaces have appeared.
Fragmentation creates the opposite problem. If competing private systems remain siloed, each may try to capture its own network rather than connect to the others. Merchants may face several technical or commercial relationships, while consumers may be steered toward the app that has the widest acceptance rather than the one that best fits their needs. The BIS points to China and Peru, where major payment apps were previously incompatible with one another and with other apps before regulatory intervention. A market can therefore be crowded at the interface and fragmented at the connection layer. That is not the same as meaningful competition; it may simply distribute lock-in across several silos.
Nor does a shared rail remove the rail’s fixed costs, scale economies, or two-sided merchant coordination. Those features can still support concentration and shape which providers are able to offer a credible alternative. The access and commercial conditions around the rail therefore matter even when the transaction itself is interoperable.
There is also a difference between being reachable and being easy to choose. A user may technically be able to pay across providers but remain unaware of that possibility, encounter an app-specific QR code, or lose access to a bundled lending or insurance product when switching. Interoperability has its strongest competitive effect when the user can discover alternatives, use them without unusual friction, and keep the relationships that make payment useful. The technical path is a necessary condition for that freedom, not a complete description of it.
This gives us a more precise way to describe what changes. Interoperability removes one important reason for users to select the same provider as their counterparties. It can shift network effects toward the shared platform, lower the scale needed for a differentiated app to enter, and expose incumbent quality to switching pressure. But it leaves the rail’s scale economics, the merchant’s two-sided incentives, and the surrounding questions of access, data, reliability, and governance. The central competition question is no longer simply, “How many apps are available?” It is, “Can a user choose among them without giving up the ability to transact—and can providers still create practical barriers after the connection exists?”