[#71] Yes & Axis Bank: The banks powering India’s UPI flywheel

Behind the UPI App leaderboards, there are banks powering each leg of the UPI transaction. Yes Bank & Axis are leading the charge, as top choice of partner for UPI Apps & merchants to power UPI txns

We talk a lot about UPI. And the top UPI Apps in India. And which apps are doing how many volumes, and how they’re progressing, and market concentration. But in this edition, I wanted to put on a different lens.

I’ve talked a lot in the past about how any payment transaction in India has to flow through a bank. So in the interest of that, I thought I’d look at not just what the top UPI apps are in July 2025, but also, which banks these apps are powered by, and the role of these banks in general. And if you folks want to check out previous UPI themes articles, you can check out the below:

1. [#68] The UPI bottleneck Full stack ambitions, 0 MDR reality

2. [#70] Biometric authentication: Will it actually move the needle?

3. [#60] The UPI Dilemma: When the infra & apps are commodities

4. [#56] Why MDR is needed to drive innovation on UPI

5. [#38] Is the battle for the ubiquitous UPI App over?

And for more payment themed articles, do explore other editions of The Painted Stork!

Before we do start diving into the 4-party UPI model, let’s take a look at what the July 2025 UPI App leaderboard looks like

Most of the rankings for the top 10 TPAPs have stayed the same. However, Pop continues to grow after the $30M investment from Razorpay. Now Pop ranks #15 in the UPI apps ranking. Overall monthly UPI volume stands at 19,145 Mn txns in July 2025, which is 5.78% higher compared to June 2025

The lens I’ve taken here is not just UPI Apps, but also what banks these are powered by: 5/10 are powered by Axis, & 6/10 are powered by Yes Bank

The usual suspects, similar to existing trends, top the UPI App leaderboard, both in terms of # of transactions, and value processed in Cr. PhonePe, Gpay, Paytm, & Cred are top in terms of value, while Navi & Supermoney are catching up in terms of number of transactions. I’ve covered this extensively in the past, and so I won’t spend too much time on this.

Yes, Axis, ICICI, HDFC & SBI are the top Payer PSPs here. There are some other banks in the mix as well: AmazonPay, apart from Yes & Axis, is also powered by RBL, while Slice, which acquired North East Small Finance Bank (and is now called Slice Small Finance Bank)

, is now exclusively powered by that. A point of interest is BHIM is a separate entity under NPCI (which also oversees UPI) has a direct connection to NPCI rails, and hence, does not need a sponsor bank for the same.

In fact, Axis & Yes seem to be the banks of choice for Payer PSP partnerships (AKA the bank that powers UPI Apps). From NPCI’s website, out of the 37 third party UPI apps, 14 are powered by Axis, 12 by Yes Bank, 8 by HDFC, 6 by ICICI, 3 by SBI, 2 each by RBL & Unity Small Finance Bank (which is BharatPe), 1 by Federal, and 1 by IDFC

Which UPI App is doing how much volume, and so on is just half the story. Now, I’ve mentioned “Payer PSP” a few times in the above section. What is this?

There is more nuance behind the scenes. While what we are all most familiar with is the UPI App, the heavy lifting, in terms of the UPI payment initiation, validation, and actual money movement happens by the Payer & Payee PSP, and then the fund movement happens between the Remitter & Beneficiary Banks. So what are these?

1. Payer PSP: This is the bank that allows onboarding of a customer onto a UPI App. The Payer UPI switch is a software provider that is used by the PSP to connect the UPI App to NPCI rails for payment initiation.

2. Payee PSP: Within this sits the Payee UPI switch (or the acquiring switch), which again is the piece of infra that connects the Payee UPI App / Payee Account to NPCI. In P2P, if I’m paying to end user Y ( mobile number or a VPA) the PSP Bank in the VPA, (or the default VPA if only the mobile number is passed) is the Payee here, which responds if the account is valid or not, so it’s more of a router. In P2M, the Payee PSP also the merchant acquiring bank, so it’s the bank that has given the merchant a terminal to process the payment, and also receives the credit of UPI funds from the remitter before settling to the PA.
   This contains the visibility on transaction statuses, metadata on transactions etc.
   Example: If I’m paying to merchant X,

3. Remitter Bank: This is the bank that actually holds the customers funds, which need to be debited. It also holds the responsibility of authenticating the UPI PIN.

4. Beneficiary Bank: This is the bank into which the funds need to be credited. The bank that is receiving the funds in the UPI transaction is the beneficiary bank.

And to really understand the 4 party UPI model, and & why banks are doing here, it’s first important to understand what each of these players do

Above: The e2e transaction journey of UPI. I’d recommend using the above image to help guide through where we are in each leg

So, to basics then.

1. The merchant checkout: where the payment is initiated

This is owned by a payment aggregator or a payment gateway, either powering both the front end and backend of the merchant checkout, or just the backend in the case of enterprise customers, who prefer to build their own UI, and call PA APIs for the initiation and processing of the payment transaction. Now, just to understand this piece a bit better, you folks have probably heard a lot of chatter about Payment Aggregators building their own UPI switches, in partnership with some bank OR buying their own UPI switches or payment TSPs. Some key examples here:

1. Razorpay - a PA, which built its own UPI Switch with Airtel Payments Bank. Since it’s primarily a payment aggregator, its UPI switch will be primarily processing volumes on the payee side, not the payer side.

2. Cashfree - another PA. It has built its UPI Payee switch with NSDL payments bank. Again, no B2B pay, so this is only Payee.

3. PayU - bought Mindgate. Mindgate is a TSP that has UPI switches on both the payer & payee side. This is important, because Mindgate is the TSP provider for HDFC & SBI. Which means that every time you see a payer or a payee transaction on HDFC & SBI, it’s mindgate, and now, by acquisition, PayU that is processing it.

This will get clearer as we go through what each leg does:

2. Payer Side of Transactions: UPI App -> Payer PSP Bank -> NPCI - Central Mapper

When you initiate a payment transaction, either on the app, or on the merchant checkout, and the UPI App opens up, is when this leg kicks in.

So, when you’re doing a payment transaction on a UPI App, you probably see your VPA (virtual payment address) as abc@okhdfc, or abc@axisbank. Now, the “bank” here is the sponsor bank through which the UPI App / TPAP is connected to NPCI. This is also what I’m referring to in the previous section, when I’m talking about UPI Apps being powered by banks.

This is the payer side of things: where the Payer UPI switch (or the Payer PSP) comes in when there is some end user who is “paying” using their UPI App. This is easier to understand, as an end user. The VPA is stored with NPCI, along with a mapping of your account to your VPA & mobile number. That is how you’re able to pay directly to a mobile number or a VPA instead of having to enter user account details.

The Payer Side of the UPI transaction (UPI App + Payer PSP)

There’s another angle here: When you started out on a UPI App, the bank in your VPA was your actual account in which money was stored. That helped because then if your PSP bank on the payer side is the same as your actual bank that holds the funds, you actually don’t have to use NPCI infra to map your VPA to the customer bank from which funds are being debited (also called the remitter bank). The bank can resolve this internally. But it helps if you have multiple VPAs: abc@axisbank, abc@sbi bank, because then it helps to increase success rates in payment processing in case any bank is down. This is important to remember, as we get deeper into the payer -> payee -> remitter -> beneficiary story.

Some things that the Payer UPI switch (Payer PSP) does is:

1. Gets the payment initiation instruction from the UPI App. So a PhonePe would send the initiation instruction to the PSP bank. So in the case of a VPA being used of abc@axisbank, PhonePe would call the PSP Bank switch (this is the UPI switch sitting in the PSP Bank infra).

2. The Payer PSP then checks the payer VPA - so in this case if I am initiating the payment, the Payer PSP Switch would check if my VPA exists in the bank mapper (every bank also keeps a copy of VPAs it has issued). The Payer switch also checks if the linked account is active, if all KYC is done, and there is no issue on transaction limits (example: has the daily transaction limit of INR 2L been passed)

3. It then also does balance checks: does the account have enough money for this transaction. It also checks if the account is authentic: Example: is the device binding correct, is the SIM correct (more about this in this article). It also tracks any risk patterns

4. If all of this checks out, then it initiates the PIN entry, which happens on the NPCI CL page. The NPCI CL is embedded in the app SDK. The Payer switch invokes the CL, the end user enters the PIN, and it’s validated by the issuer bank.

5. Once the transaction is successfully validated, the Payer Switch then generates a payment message with payer details, and sends this NPCI’s central switch for storage.

3. Payee Side of transactions: this is the VPA of the merchant/end user that is getting paid

So, when you, as the person who has to pay: you’re either sending money to their number, or you’re sending money to their VPA, which could be: abc@icici. Now, when I initiate payment to this VPA, the UPI App, or the Payer PSP doesn’t really know who the VPA of the person I need to send money to belongs to, what account number this is, or is it even active. This is what the NPCI Central Mapper, & the Payee PSP help to do:

There can be two types of Payees here (and this distinction is important because it feeds into what is happening with PA’s investing in their own UPI switches)

1. The P2P side (peer to peer), where the payee (or the beneficiary) getting paid is another individual. So this could be me paying to let's say my sister.

2. The P2M side (peer to merchant), where the payee getting paid is a merchant. This is me buying something from Amazon.

In the case of P2P

The payee PSP bank is simply the bank behind the payee’s VPA. Let’s say I (Ambika) am paying Devki. My VPA is ambika@oksbi, and Devki’s VPA is devki@okicici.

• My remitter bank (the bank where my funds actually sit) is SBI. My VPA being used here is also @oksbi, so that is the payer PSP being used.

• Devki’s beneficiary bank (the bank where the money should land) is ICICI. Her VPA here is @okicici, so the payee PSP being used is ICICI

Now, when I make a payment, the transaction is triggered by my payer PSP bank (SBI in this case). If the payer PSP and the remitter bank are the same, SBI can directly map my VPA (ambika@oksbi) to my bank account & do balance checks, no need to hit NPCI’s central mapper.

But for Devki’s VPA (devki@okicici), my payer PSP bank needs to know where exactly the funds should go. Since my bank is SBI, and her bank is ICICI, I cannot map the VPA to the account number internally. This is where I use NPCI’s central mapper.

So the transaction is initiated in the above section from the UPI App, which sends these details to the Payer PSP. The Payer PSP then sends Devki’s VPA to NPCI’s Central Mapper, which resolves it to her ICICI account details. It also then checks with ICICI (the Payee PSP) for the status of the account, is it active, and validates the account, and sends the validation confirmation back to NPCI, which then triggers the credit & debit requests.

If, however, the payee PSP was also SBI, the same as the Payer PSP, then this step could also be handled internally without NPCI, because SBI could internally check on the address resolution, and validate the status of the account.

Once both VPAs are resolved, the debit request hits my remitter bank (SBI), and the credit request hits her beneficiary bank (ICICI).

Important nuances: The more ownership of more legs by a single bank, the less dependency on NPCI to map VPAs, and communicate between banks for fund routing → more efficiency and less costs

1. If the Payer PSP, Payee PSP, remitter bank, and beneficiary bank are all the same (example: both payer and payee have accounts in SBI, and both VPAs are @sbi handled by SBI’s PSP switch). This is because SBI has visibility on the VPA’s it has issued, and doesn’t need to route to NPCI to look this up

2. In the above scenario, the entire transaction can be settled internally by the bank’s PSP switch without hitting NPCI’s central switch for account resolution or funds movement.

3. NPCI may still log the transaction metadata for reporting, settlement reconciliation, and fraud monitoring, but the heavy lifting (VPA mapping, debit, and credit) is all intra-bank.

This is faster and cheaper since: 1) No interbank settlement is needed. 2) NPCI’s role is minimal (just network-level compliance/oversight).

The big takeaway is this: the more of these four “legs” (payer, payee, remitter, beneficiary) a single bank controls, the less the transaction depends on NPCI infra, which means faster processing and lower costs.

Payee PSP role in the case of P2M

This brings us back to why PAs are investing in either acquiring or building their own UPI Switches in the Payee PSP Bank. The UPI Switch is the piece of infra within the PSP bank that actually does the heavy lifting of connecting with NPCI to initiate and process the transaction.

While the high level flow remains the same, there is a nuance here, since here the merchant is onboarded by a PA, and the payee PSP switch here is built / bought by the PA. This is where the earlier point I had made about PAs building or buying their own switches comes into play.

This is more layered and operationally heavy. For this to play out, there is a step involved here, which is at the point of merchant onboarding on the PA, even before the UPI transaction has been initiated.

When a merchant is onboarded onto a PA, the PA needs a merchant VPA/terminal provisioned from a bank. This is essentially the merchant’s “entry point” into UPI. This is what gives the merchant the ability to accept payments. Large merchants are usually set up with multiple PSP banks so that their PA can route transactions redundantly across PSPs (to handle downtime and improve success rates). And the key point here: For the PA itself, one of these merchant VPAs is often tied to its in-house PSP switch (via its sponsor bank). That’s the preferred terminal for routing, because it gives the PA more control.

So I’ll give an example here: let’s say Merchant X does $100B volumes per year. This merchant doesn’t want to put all its eggs in one basket, and thus wants multiple options or “gateways” to process its payments, so that in case one bank goes down, it can route to other banks. So Merchant X will go to a Razorpay, and get multiple terminals procured, which means, it will be onboarded on multiple banks, with a VPA created on each one, so that at the time of transaction, it can be routed to the best performing bank. Let’s assume, Merchant X has 3 terminals for UPI when it is onboarded: merchantx@icici, merchantx@hdfc, merchantx@sbi.

Now, let’s assume Razorpay has built and deployed its own in-house switch in Axis. One of the VPAs onboarded the merchant on is merchant@axis, and more often than not, Razorpay will prefer routing to be done to this handle, as it is where it has more control and visibility, since it has it’s own Payee switch deployed here (more on the benefits later).

At the time of payment:

1. The customer’s payer app + PSP switch hits NPCI

2. NPCI resolves the merchant’s VPA (e.g. merchant@axis), and routes to the Payee PSP to check the status of the account (no blockers, its live etc). If all good, then:

3. A debit request & response goes to and from the customer remitter bank

4. A credit request & response goes to the beneficiary bank (which in this flow is the acquiring bank = Payee PSP = Axis Bank)

Note: In a P2M Flow, in the case of UPI flow, the money hits the account of the Payee PSP - in terms of UPI flow, the Payee PSP & the Beneficiary bank is the same.

The first hop of funds happens from the customer account to the bank which gave the terminal to process the payment, which is the Payee PSP (and in the UPI flow is also the beneficiary bank). Then, post the UPI flow, as a part of the settlement flow, it flows into the PA escrow accounts, and then is settled to the merchant business account. Though in some hybrid setups, the PSP VPA can still point to a different underlying account)

The Payee PSP Bank in the P2M model, plays an important role in settlement, data, reconciliation and refunds:

• The Payee PSP in this case can also be the beneficiary: In its beneficiary persona, it receives & settles credits: final landing point for funds before moving into the merchant’s settlement account (which can be the PA escrow, and then to the merchant’s business account)

• Maintains transaction states: success, pending, failure. Statuses are exchanged over UPI rails (NPCI ↔ remitter PSP ↔ payee PSP), usually in real time and mirrored back to the payer.

• Holds metadata: transaction IDs, merchant category code (MCC), customer VPA, payer/payee PSP details. It is useful for analytics, fraud monitoring, and routing intelligence. And maybe, from a PA perspective, it is possible to use this data on checkout to better personalize the experience / what methods to show / how to show etc to the end user?

• Reconciliation & refunds: Reconciling NPCI settlement files with their own ledger, handling reversals (T+1/T+2 settlements), refund initiations, and chargebacks

Now, as a PA, having a Payee sponsor bank (Payee PSP) where you have deployed this UPI switch infra being the one which receives the merchant funds AND has visibility on transaction status, metadata etc can be a big moat.

1. You have more visibility on the status of funds which is useful in recon with NPCI & banks

2. You have more visibility on the end customer transactions such as phone number, account numbers, transactions across MCC codes & merchants. So, you can actually map user ids across merchants, and gain a pretty good view of where that user is transacting. So, in a previous article that I wrote, where we talked about how apps are silently querying other apps to build a user profile, this is what the Payee UPI switch can do, just by looking at the transaction level data. You can read more about it here

3. All the data that the Payee PSP switch has access to can be fed into giving more personalized experiences at checkout, better risk monitoring and so on

What’s next here? Well, keeping the cost to one side (since monetization on UPI has still not been solved, and until that is, innovation will slow down, just from a value perspective, assuming monetization is solved: I expect PA’s to deploy switches in more banks:

The payee PSP bank isn’t just a passive receiver of funds. It’s the gateway that authenticates payee VPAs, anchors merchant onboarding, handles settlement, and ensures transaction state integrity. For PAs, this is why being tightly integrated with (or owning) a PSP bank is strategically so valuable. And, it’s not just these transactions: the Payee PSP also plays a big role in setting up recurring payments, such as UPI Autopay, which has really scaled in the last year, but more on that in the next article).

Some points to note here

Even when PSP and remitter are the same, the PIN validation & authorization still happens through NPCI rails (via UPI switch), not entirely “offline.” So while VPA resolution may be internal, funds movement instructions still go through NPCI’s UPI system.

The complete picture: more ownership, more efficiency, less costs (since per txn, banks have to pay a INR 1p switching fee whenever they use NPCI’s central switch)

Now here’s where we get to the interesting part: Till now I’ve explained the payer PSP bank, the payee bank, the remitter bank, and the beneficiary bank.

What has been coming out in the above piece is that, the more ownership the banks have of all 4 legs: either through TPAP / PA partnership, or by actually being the customer’s bank, the less dependency they have on NPCI infra, and they don’t have to pay the switching costs, so this becomes more cost effective. And this can also act as a valuable source of data for personalization, value added services to the merchant & the end customer.

So if we peek behind the scenes here, an interesting story starts to take shape -> where we can see which are the big banks actually powering these flows & betting big on UPI infra

NPCI actually publishes the data of volumes processed by Payer / Payee / Remitter & Beneficiary Banks. So let’s look at who tops the lists across each leg

So, high level, Yes Bank, Axis, HDFC, ICICI & HDFC top all 4 legs in terms of # of transactions, to have the biggest “on us” plays. Within this, Axis & Yes Bank seem to be the banks of choice, when powering the UPI App & PA / PG flows, because of their dominance on the Payer (UPI App + Payer PSP) & Payee (PA/PG + Payee PSP) side of things.

In fact, from a % percentage perspective, the volumes are even more stark: Axis powers ~34.56% of Payer txns, while Yes Bank powers 28.16%. And in terms of Payee PSP, Yes powers a whopping 52% of transactions!

And combining the above view with the top UPI Apps in India enables us to make some interesting inferences across the big players in each leg

✅ Payer PSP Leg: Top 5 banks power this leg, some UPI Apps such as BharatPe & Slice have their in-house bank stacks now, through Unity Small Finance Bank, and North East Small Finance Bank (aka Slice SFB) respectively

1. No surprise to see Axis, Yes, ICICI, HDFC & SBI top this list. They power their own bank apps which provide fairly significant volumes. Apart from that, these banks also power the top 3 apps in India:

   1. PhonePe: Yes, Axis, ICICI

   2. Gpay: HDFC, ICICI, SBI

   3. Paytm: HDFC, ICICI, Yes, SBI, Paytm Payments Bank (now blocked)

Something else to call-out here is that Juspay, is the leading provider of TPAP stacks, and according to their website, powers Gpay, AmazonPay, CRED, etc. Now, Mindgate is the UPI switch provider for HDFC & SBI. Juspay has payer side partnerships with Yes, Axis, RBL & ICICI

✅ Payee PSP Leg: This is the end user or the PA / PG side of things

On the B2B side, this is the terminal that the merchant is onboarded on, which can be either a PSP where the PA has deployed its own UPI switch, or not. Yes Bank tops this list, with 10B txns in July 2025, which is close to 3x more than Axis, which had 3B transactions. Followed by ICICI, HDFC, SBI - the usual suspects. What is more interesting is the banks that come below:

1. Airtel Payments Bank: #7 in terms of txns processed in July 2025, which is the bank that Razorpay has deployed its in house UPI switch in. Did 211M txns in July 2025

2. Unity Small Finance Bank: #9 in terms of txns processed in July 2025, which is Bharatpe affiliated, and powers probably all BharatPe offline QR + Soundboxes + any online volumes that they do. Did 116M txns in July 2025

3. NSDL Payments Bank: #15. Partnered with Cashfree to deploy its payee switch, and did ~43M txns in July 2025.

✅ Remitter Leg: Bank which issues customer accounts - top is SBI

This is the end customer’s bank - the customer who is making the transaction. There is limited UPI play here, this is mainly driven by the bank which has issued accounts to the most number of customers, and is topped by SBI which is not a surprise

✅ Beneficiary Leg: In a P2M txn, the Payee PSP & Beneficiary Bank are usually the same, and can be used to infer PA + Payee PSP partnerships

In the case of a P2P transaction, this is the bank of the end customer.

In the case of a P2M transaction, this is the Payee PSP through which the transaction has been processed. I expect this to mirror the Payee PSP leg, and this shows. Yes Bank tops both the Payee PSP & the remitter bank legs, in terms of # of txns.

Now, while I’m not aware of any big PA partnership here that has been announced publicly, we can draw some inferences through current UPI App & PSP partnerships. Both Paytm & PhonePe, which are both big PA players and UPI App players, have partnered with Yes, Axis & ICICI on the payer side of things. It’s a fair assumption to make, that they have partnered with these banks to power their PA (payee) side as well, and that could be another reason driving this volume high. If you look at the offline QRs deployed by these players PhonePe QRs are majorly of Yes Bank and Gpay uses Axis QRs and same for Paytm. Setu - a company acquired by Pine Labs has built its payee switch, in partnership with Axis. I assume it’s powering some % of PineLabs offline & online volumes through Axis. It’s also possible that these are direct merchant to bank PG integrations for these specific banks, which are not through PAs.

💡A way to see which banks are doing these merchant / PA / PG partnerships, either through a PA, or through direct integrations is to look at the Payee PSP & the Beneficiary Bank. Banks which show up in both are probably going this way: Airtel Payments Bank, Canara, NSDL & Unity seem to be focused here.

Banks that have the 4 leg play: so least dependency on NPCI to actually “switch the transaction” is negligible, and costs can be kept lower. The cost structure is twofold here:

1. The payer PSP has to resolve the Payee PSP address: Hits NPCI central mapper, and incurs switching cost. If the Payer PSP and Payee PSP are the same, then since the bank can resolve this internally instead of using the NPCI mapper, there could be a potential reduction in cost, since there seems to be less usage of NPCI infra

2. There is also a better experience that can be given here, because the bank has more visibility and control of the transaction, which can also increase success rates

3. The remitter has to move funds to the beneficiary account. If both are the same bank, then handles internally. If not, then they have to use NPCI IMPS rail (UPI is on IMPs).

So now, let’s look at who all have the most volumes, and presence in the On-Us transactions (presence in all 4 legs), and Yes Bank is absolutely killing it. Cumulatively powering: 24B txns across 4 legs in July 2025

This is where the power of the 4 party model can be seen:

1. If the Payer PSP + Remitter Bank is the same, you don’t need to go through the NPCI central mapper to check the Payer VPA validity. So here, most UPI Apps, in the case of multiple VPAs, will route the transaction through the VPA which is the customer’s remitter account.

2. If the Payer & Payee PSP is the same, then again, the Payee VPA resolution can happen internally, instead of using the NPCI central mapper. Again, this is a function of the UPI App having 1) Most Payer PSP partners, such as Phonepe, Gpay, Paytm which have 3-5 of the top banks, so there are most chances of the payer and payee PSP being the same. This is also an input when choosing which customer VPA to route through.

3. If the remitter & beneficiary bank is the same, then while the transaction record will go to NPCI, the settlement can happen internally in the bank.

And this is important because apart from the cost of a UPI transaction, which can be minimized if there are “on us” transactions - where the bank is the same, there is also a cost of using the central mapper - a 1 paise switching cost per transaction.

So what’s next here for banks, UPI Apps & PA’s in context of the PSP play?

➡️ For UPI Apps & PAs

1. Assuming cost is no barrier & monetization is not a problem, I expect PA’s to go after deploying their UPI switch in as many banks as possible for the Payee + Beneficiary play

2. The more banks they have, can this resemble network level control? A say in settlements, pricing, etc?

3. PAs with UPI Apps: Payer PSP + Payee PSP visibility which is more cost effective

4. Payments Banks / neobanks become important to power these flows - especially since there is a cost angle now, fintechs may be okay to pay, but then demand complete ownership

➡️ For Banks: Newer banks start out at a disadvantage - it’s a catch 22 situation. You need more users to scale, and you need to scale to have the cost advantage and pass it down, and especially seeing the monetization angle, and bank DNA + aversion to risk, i see the right to win existing here for just the bigger banks, unless there is some fintech + bank acquisition / merger like what happened with BharatPe & Unity SF, or North East SFB & Slice. (now called Slice SFB)

As a thought experiment, I’ve created what I call the UPI Power chessboard - where I see the current major players placed, based on their current strengths, biggest perceived weaknesses, and what I think a “best case scenario” for them is

The UPI Chessboard, which I’ve defined as how current players look like in their quest for UPI dominance. High level, this is what I see:

Fintechs:

1. PhonePe: Could scale both Payer & Payee, although currently not (as big) on acquiring. Offline presence through QR + Soundbox. Paytm is also a possibility here (not included in the UPI chessboard). It recently got approval to start onboarding merchants again on its acquiring leg, but since the block for last 2 years, it has been struggling on this side.

2. Razorpay: Could scale both Payer & Payee, although currently limited on consumer app. Offline through POS

3. PayU: no offline presence, no consumer app. Major UPI play for it is the acquisition of Mindgate that powers the Payer PSP switch for HDFC & SBI. Again, HDFC & SBI are balanced across all 4 legs, but not the major players here, so I don’t see their UPI play to be extremely strong

4. Juspay: Powers majority of TPAPs. Has partnerships with Yes, Axis, RBL & ICICI to power the Payer & Payee Side of things. The infra survivor with a great brand & reputation in the market

Banks:

1. Axis & Yes: These seem to be the “merchant first” banks. Majority volumes across Payer & Payee PSP legs. Power majority of the TPAPs, and are also the most open to partnering on the Payee side

2. HDFC & SBI: They’re still major banks and not to be underestimated. But they haven’t invested as heavily on the UPI front - either QR partnerships, or Payer PSP partnerships. Their scale lies on the remitter & beneficiary legs.

Of course, a lot of the investment & UPI strategy also depends on the monetization of UPI. A month ago, the government declared that there were no plans to levy charges on UPI. As a response, ICICI (and other banks expected to follow suit on this) have come back, and decided to charge PAs / UPI Apps 2- 4 bps per UPI transaction. Then I assume, as a response to the banks, the RBI governor came out and said that UPI may not be able to stay free forever. Eventually I do expect monetization to come. But when that will be - no one really seems to have a clue.

But this isn’t something that payments players can ignore. UPI investment is a requirement. The “cost of doing business” maybe. As more transactions happen on UPI, being able to provide a great experience on this payment method will not be a differentiator. It’ll be table stakes. The cost of staying in the game. Where the alternative of being one of the few laggards is extinction.

And the banks who seem to be betting big on this are Yes Bank & Axis Bank.