However, what was also interesting to note was the things it did NOT mention: which is how running a payments business, especially as a ‘start-up’ means that the odds are always stacked against you, because monetization happens on volumes, not margins. This is something I had covered in article below:

On the surface, it reads well. Trust, resilience, global reach. All the right words.

But here’s what I was really looking for. A few months ago, in the article above, I wrote about the structural squeeze on Indian fintechs - free DPI compressing margins, standalone TSPs disappearing, the license requirements constraining innovation, even in smaller fintechs, full-stack conglomeration as the only survival strategy. The question I ended with: does free DPI unlock innovation, or constrain it by eliminating economic incentives? So when the regulator releases a vision document for payments, the next three years, the first thing I’m checking: does it address any of what I flagged?

Some of it, yes. Most of it, no. And there’s a whole world - agentic payments, stablecoins, monetization, that I’ve been covering in in past articles, that RBI doesn’t even acknowledge exists.

I think what we do really well, especially from a central / governance perspective is “project” that we’re thinking about the future. What we don’t do well, is defining steps on how to implement some of these things. Which, if you think about, is the most important.

“Payments Vision 2028 recognises that digital payments continue to make inroads into all population segments (a fact objectively captured through RBI’s Digital Payments Index), and the challenge before the ecosystem is no longer one of expansion of reach alone, but of deepening ‘trust’ in payment systems, reinforcing resilience and expanding their global footprint. Anchored in the theme, ‘Shaping India’s Payment Frontier’, this Vision document focuses on user empowerment, safeguards against fraud, efficiency of cross-border payment frameworks and promoting ease of doing business. Regulations and supervision of payments systems, while continuing to be risk-based, would be guided by the need for innovation and inclusion.” - an excerpt directly from the Payments Vision 2028 document that RBI published.

Reads well. But let’s get into it in detail. What I’ve tried to do is go through the doc, which isn’t that long by the way, so I do recommend reading it for yourself. But I’ve tried to map it out into what the initiative is, and what the impact of this could be.

A pattern you’ll notice when you read the paper for yourself: a lot of “examine,” “explore,” and “review” in the language. Very few hard timelines. Very few measurable benchmarks. To sort of compare this to other themes I’ve been talking about - and what is top of mind for me is agentic commerce, I’ve talked about how the real bottleneck for agentic commerce isn’t protocols, it’s about the infrastructure readiness of real stakeholders who are actually involved in the money movement (card networks, banks, etc), which is something that is echoed in Adyen’s whitepaper about agentic commerce, and there is no clarity on that. However, that can be forgiven - very new market, and the whole “agentic” spiel has only been around for the last 2-3 years.

But my concern is that even when you’re talking about payments, and payments fintechs, which are 10-12 years old in India, you probably need a little more clarity and starting pushing on real implementation and “hard” timelines, not just “explore” and come back.

This is what I respected about the RBI circular on alternate authentication, which - if you recall mandated for 2FA in payments (which already exists), but one of the factors needing to be dynamic in nature (like an OTP, or authenticator apps), AND coupled with the fact that the overall view is to move away from OTPs, leads to a lot of interesting changes in the ecosystem. For example: if you’re on linkedin, you’ve probably seen how everyone is launching biometric based payments on checkout, utilizing biometric creds, and passkeys. That is because it’s been pretty obvious that the ask is to move away from OTPs.

Now, getting into the specifics.

What seems to be positive

Let me be fair first. There are things in this document that matter.

1. Fraud liability is finally shared between the issuer and beneficiary bank - shared incentives can add more scrutiny

❓The problem today: Today, if you get scammed via UPI, here’s what happens: your bank says “you authorized it, not our problem.” The beneficiary bank which is the the bank that received the stolen money has zero accountability. They have no incentive to flag suspicious accounts, freeze funds quickly, or cooperate in recovery.

✅ Solution: RBI is proposing to change this. Shared liability between the issuer bank (your bank) and the beneficiary bank (the scammer’s bank). Both are now on the hook. This is meaningful. UPI fraud surged to INR 1,226 crore in FY26. A big chunk of this could be prevented if beneficiary banks had skin in the game, with flagging mule accounts, freezing suspicious inflows, cooperating faster on recovery. Now, it is good that there are more stakeholders in the ecosystem that have a liability - it ensures that everyone is aligned, otherwise if there only one party in the transaction that is on the hook for this, it makes cooperation a lot harder.

👉 But my concern: This needs rule-based design. How exactly is liability managed? 50-50? Based on response time? Based on who flagged first? If the rules are vague, it could actually slow down relief rather than speed it up.

2. Cross-border is getting serious attention

❓The big problem today Today, if you’re building cross-border payment infrastructure, you need separate approvals under separate acts, from separate departments. It’s a nightmare. I’ll elaborate on this.

1. PSS Payment Systems and Settlements Act governs all entities, and mechanisms that operate a payment system in India. In a nutshell, if money moves domestically in India, then PSS governs the rails and operators, and so, a cross border payments platform first would need to have an authorization under PSS. So, methods such as UPI, RTGS, Netbanking, and players such as Banks, Payment Aggregators, UPI Apps would all be governed under this act.

2. FEMA (Foreign Exchange Management Act) Regulates cross-border flow of money and foreign exchange in and out of India.

3. An example: A cross-border payment app (say, Wise) would need PSS authorization for operating a payment system in India and FEMA compliance for the forex/remittance leg. That’s just unnecessary hiccups.

✅ Solution: RBI has proposed a single-window authorization combining PSS Act (2007) and FEMA (1999) requirements. So, for any cross border entity, now instead of having to get authorized under two separate Acts, this will be combined into one.

Other things that RBI covered under cross border are: 1) Dedicated reporting, which is tracking domestic trends and global developments separately and 2) G20 alignment, where efficiency metrics benchmarked to global standards. Now, the jury is still out on what this means since these 2 points mean that we’ll benchmark our products to global standards.

👉 However, my concern is that nowhere are stablecoins mentioned: I’ve spent the last several months writing about how stablecoins are becoming the default rail for cross border and machine payments. What surprised me that RBI doesn’t mention stablecoins once in this document, seeing that stablecoins are becoming the rails on which cross border money movement will happen. (more on this below).

But nevertheless, less regulatory friction for cross-border flows is unambiguously good. This is the one area where RBI is actively trying to reduce friction rather than add infrastructure. I’ll take it.

3. TReDS interoperability for MSMEs

Firstly, why should we care about TReDs? Well, TReDs sees significant volumes, with invoices processed totalling INR 1.38 lakh crore in FY 2023–24, marking an 80% increase over the previous year. And of early 2026, leading platforms are projecting over INR 1.75 lakh crore in annual transactions, so its a big channel for MSME’s to manage their cashflows, and what RBI is clearly betting on to drive the growth of the MSME sector.

Before, we get into this, let us quickly understand what TReDs is:

TReDS is an electronic platform where MSMEs can sell their trade receivables (invoices) to financiers at a discount, to get paid early instead of waiting 30-90-180 days for the buyer to pay. It is NOT a loan, where there is a loan you’re getting

Think of it as: an auction marketplace for unpaid invoices. I’ll give an example:

1. Let’s say there is a MSME (Acme Corp) that supplies goods to some Corporation (Corp X) and has raised an invoice of INR 10L. Acme Corp will receive payment in 90 days from Corp X.

2. But the problem is that MSME needs cash NOW to pay workers, buy raw materials, and just continue with business operations. They’re stuck until payment comes in.

3. TReDS essentially fixes this cash flow gap. MSME’s can upload invoices on TReDs platforms, the Corporation validates it, NBFCs / Banks and bid on the invoice. Whoever offers the MSME the best deal wins. So let us say NBFC X wins the bid, and offers the MSME 9.9L. The MSME gets INR 9.9L immediately and can continue operations. And the corporation pays NBFC X INT 10L in 90 days when the invoice comes due, making INR 10k.

❓The problem today: The problem: these platforms operate in silos. Each one has its own pool of buyers and sellers. So if you’re onboarding on TReDs platform A today, it’s a closed marketplace, where you’ll only be able to find financiers, if they’re onboarded on the same marketplace.

✅ The solution: RBI wants to improve the access that MSME’s get to working capital by proposing the following:

1. Interoperability across TReDS platforms: Honestly? Usually when anything comes up around interoperability I always get cagey. My big concern around interoperability has always been that this takes away from the key moat of any tech business. If you suddenly start making all this interoperable, then it reduces the margins and the moat that these businesses have. However, the reason that I see this as a “not necessarily something bad” is mainly because there aren’t that many TReDs platforms in India, only ~5 licenses have been given out. RXIL (backed by SIDBI (govt) and NSE (exchange), Invoicemart (Axis Bank + mjunction (Tata Steel & SAIL JV), M1xchange ( promoter-led - Mynd Solutions). Has raised some private capital but not classic VC-funded. C2FO Factoring solutuionsm and then KredX is which is promoter-backed. The point is, this works if there are few companies operating in this space. It doesn’t work if it becomes like ONDC - where everyone can plug into this network, and bigger entities which have put the effort to create their networks then essentially have to give access to it to all newer, smaller players.

2. Expanding access to export MSME receivables: Right now, TReDs mostly supports domestic invoices. Where, an Indian supplier, suppliers to an Indian company, and gets paid by an Indian lender. But now, RBI is proposed to also “explore” frameworks where an Indian manufacturer which exports goods also has a way to sell invoices.

3. Enabling factoring with recourse: This is more to do with who bears the risk if the buyer doesn’t pay the invoice. In the earlier example, we used Corp X which has an invoice payable in 90 days. This invoice has been sold to a NBFC. Now if Corp X doesn’t pay the NBFC, who bears the risk? In the earlier structure, this was “without recourse.” Which meant that the financier bore the full risk. Which led to them being SUPER risk averse, and being very careful about which invoices to fund, which resulted in many smaller or “riskier” MSME’s not getting access to capital. With recourse means means that here, the MSME is responsible for paying back the financier if the buyer doesn’t pay. Now, on the surface, this seems like a hit to the MSME - but I actually see this as a good thing. MSME’s may take the hit if some buyers don’t pay, but this actually derisks the financier, and makes THEM more willing to take the risk and fund more MSME’s if their downside is covered.

👉 My concerns: There are lots of good things here. This connects directly to the export factoring problem. Forex costs have been killing factor margins on SME invoices - the double conversion problem where USD gets force-converted to INR and then back. If TReDS platforms interoperate AND the FEMA foreign currency account unlock (October 2025) holds, the addressable market for export factoring grows significantly. More platforms, more buyers, more liquidity, better pricing for MSMEs. But my concerns: a lot of this is “being explored.” I don’t know what that means. At this stage, if a regulator has little clarity, then how much will be implemented.

4. Small Payment System Providers - a door for smaller fintechs to operate without taking the “full” compliance burden that a scaled up payment system adheres to

❓The problem today: I’ve actually talked about this in previous articles. While in 2025, with India’s updated Payment Aggregator guidelines moved to a one licence regime in payments - but functionally segmented by flow type and risk profile. Which is: one umbrella PA license, and then individual applications underneath it depending on where the entity wants to operate: online, offline, cross border import, cross border export.

This “umbrella license” policy is similar to other regions I looked at: Singapore, EU, and the UK, which usually have one overall license, and some sub segments underneath the. However, what is different from India and other regions is also stark.

1. There is no license separation between infra and actual fund flow, which results in everyone going after the same umbrella PA license in India, despite having no play in money movement. Example: even if you are NOT involved in fund flow, but just in payment initiation (think, a payment orchestrator, or even a UPI app), you would still need to probably get a PA license. This severely hits smaller fintechs which may never be involved in fund flow.

2. There is no compliance reduction based on entity scale in India: Compare this to entities in UK and Singapore. For newer / smaller entities operating at a smaller scale (details here), the license is different, and the compliance and reporting burden is lesser, allowing space for smaller players to come in and compete. In Singapore, MAS offers a Major Payment Institution license and a Standard Payment Institution license, so even small players can operate under regulation without the full compliance burden. And SPI & MPI is differentiated basis the scale they have: volumes: SPI ≤ S$3M/month (single service) or ≤ S$6M (aggregate); above this = MPI. SPI’s & MPIs can conduct the same activitie

✅ The solution: RBI is proposing a new category: Small Payment System Providers, with a perpetual regulatory sandbox. Lower entry barriers. Lighter compliance. A way for smaller players to operate while figuring out full licensing.

So, this is really good from the “regulatory” side of things. The regulatory declarations that a Pine Labs or a Razorpay which are processing hundreds of $billions are at a different scale. A small - just starting out fintech wanting to innovate on money movement should not have to adhere to the same regulatory requirements. They to do - which adds costs, overhead, and makes it hard to operate. And this is in line with what UK and Singapore have currently, so there are precedents for this.

👉 My concerns: I’ve argued in the past that standalone TSPs are being squeezed out of the market - the Signzy-PowerEdge acquisition was Exhibit A. Others: Razorpay buying a stake in Pop, PayU acquiring Mindgate (UPI switch) are all symptons of this. Even profitable, funded startups are getting absorbed because the economics of operating independently in India’s fintech market are brutal. SPSPs are RBI’s answer to the entry problem. And the fact that they have addressed this entry problem means that somewhere, someone has recognized that it is tough to operate as a small fintech player in India. But the entry barrier was never the JUST the license, it was the economics. Giving someone a license to enter a market with zero margins is still a market with zero margins. And that is something that is glaringly absent from the 2028 payments vision.

The Big Moves: Payments Data & E-Commerce Regulation

Two initiatives deserve their own section because they could reshape the market.

1. The AI-Enabled Payments Database

RBI wants to build an “AI-queryable payments data repository” for policy intelligence and supervision. On the surface, this sounds like a data nerd’s dream - a centralized, structured, AI-accessible database of India’s payments flows.

Practically there is still a lot that need to be done here: at the end of the day, a central structured AI accessible database of India’s payment flows has 2 problems:

1. Setting up a system like this for payments data requires standardization of data schemas: today every system will probably store and report their data separately. So there needs to be a clear plan on what this database will contain, and how it will be standardized so all the data from different sources is speaking the same language

2. How are you going to get big payment players to share their data? They have enough volumes to draw pretty decent inferences from it. And this is a moat for them: example; Stripe Radar uses the transactional data it has across all its merchants to match trends, and monitor risk and fraud, since it seems patterns across billions of transactions.

3. Who gets access? At what granularity? Is this consent-based (like Account Aggregator) or surveillance-grade? Will this be used for innovation or just for supervision? RBI hasn’t clarified.

More data is always better. But this is the same issue that we’ve come across in other payments models and initiatives that has been taken at a central level in India - there is a vision to provide a “greater good” to the ecosystem, at the cost of the major stakeholders in it. If designed well, this could become India’s version of open payments data. Researchers get better signal. Lenders build better risk models. NBFCs price credit more accurately. Policy becomes genuinely data driven instead of vibes-driven.

The problem with setting up these ‘grand visions’ of public infra is 1) execution is a question and 2) when there is monetization / comp designed, then its just strong-arming.

If this becomes another free public good, where payments data available to everyone, then further compresses the moat for companies that built proprietary payments intelligence. Companies that spent years building data advantages on payment flows could see that advantage evaporate overnight. So now, there is more free infrastructure, and less monetizable opportunities. This is the DPI playbook, applied to data.

👉 When this happens, then no one is incentivized to ACTUALLY make this work. Stakeholders do the bare minimum needed to “comply” with the mandate. The way I see this: firstly, execution of this is going to be a question, because I’m not even sure if the framework of this has been thought through. The second: if we don’t start thinking of this in terms of a sustainable business model, this is going to turn into something like CKYC - the right idea, but lack of incentives and “thinking” through the process results in rejection rates as high as 30-50%!

2. E-Commerce Companies could maybe come under RBI regulation because of the payments being processed through them

RBI explicitly says it will examine extending “direct regulation” to e-commerce marketplaces and centralized platforms.

The exact quote from the vision document: “E-commerce marketplaces and centralised platforms have been assuming significant responsibilities that could have implications on orderly functioning of the payments ecosystem.”

I’ve actually covered this in a previous article where I explore how lots of ecomm players are moving into fintech. You can check it out below:

Now, from an ecommerce perspective, getting into fintech makes perfect sense.

1. High volumes = big upside: Even a few basis points saved on massive GMV translates into significant absolute gains.

2. Own the full CX: Checkout and payments are critical to the user journey. Why let a third party control that experience?

3. Credit as a VAS: With millions of transacting users, offering embedded credit is a natural and high-value extension.

In short: Fintech isn’t just adjacent for ecomm it’s a logical, margin-boosting next step. The numbers back this up. In February 2026 alone, online marketplaces processed 114.52 million UPI transactions worth INR 6,461 crore. These platforms handle settlement, refunds, escrow, merchant payouts.

👉 But here’s my take on it: I don’t know if this requires RBI oversight. For those players who are getting into this space: Amazon, Flipkart etc, they have already picked up the licenses that they need to.

My prediction: This was that along with Flipkart, Amazon, players such as Meesho, Blinkit, Instamart, Zepto will also want to own more of the payments and money movement step. But they’ll do that via third parties, and some whitelabeled experience (like the Zepto x Snapmint collab to launch Pay in 3 on Zepto). Snapmint is a licensed NBFC that is doing this for Zepto. So this licensing is already being taken care of.

👉 My concerns: Bringing ecommerce players under the regulatory ambit of RBI may not solve anything except for added overhead on everyone.

There’s a difference between “regulate platforms that handle money” (good) and “create compliance overhead that kills quick commerce and small sellers” (bad).

The elephant in the room: What’s NOT in the document

Alright. Now for the part I was really looking for. A lot of times, the ‘absence’ of something speaks louder than what is actually mentioned. And there are some omissions in this vision document that are a bit concerning to me.

The most important: Does RBI address the structural squeeze on fintechs? No it doesn’t

In my past articles on UPI, DPI, and monetization, my core thesis (which has increasingly beein validated) is that India’s DPI approach - UPI, Account Aggregator, ONDC, ULI builds world-class infrastructure and positions it as free public goods. This drives incredible adoption and inclusion. But it also compresses the entire monetizable surface area for private fintechs. And the strategy for adoption seems odd: look at what happened with UPI.

UPI originally was being pushed by NPCI via banks, not fintech apps. And by the way: in all other markets - Pix being an example (Brazil version of UPI) it is driven via bank apps. But in India, banks were slow to adopt. That is when fintechs came in: PhonePe, Paytm, Gpay, and drove adoption with the hope monetization will come in. Adoption happened, but monetization didn’t, so they had to pivot to doing other things: broking (share.market, Paytm Money), lending, insurance, and essentially everything under the sun.

And now, after UPI adoption has happened, and customer behaviour is set, NPCI is promoting its OWN UPI app called BHIM App, targeting a 5% market share.

So, it isn’t enough that the question of “structural profitability” is not being addressed. Now, RBI wants to launch competing products that will compete with these fintechs in the first place.

NPCI made ~1552 Cr of profit in FY25. PhonePe had a loss of INR 1727 Cr in FY25. NPCI can afford to promote its own app, give cashbacks, and sign up Dhoni to promote the app. I have heard customer feedback such as “The BHIM app is what a UPI App should be. It isn’t cluttered, and isn’t trying to cross sell multiple products to me.”

That is fair feedback. But it is also happening because for fintechs, they HAVE to make money, and they HAVE to cross sell. BHIM doesn’t have to, since it is essentially a government initiative.

When the reference price is zero, margins collapse. And to add to that RBI is now introducing its own competitors into the fray (ONDC, ULI along with BHIM are examples)

Standalone players can’t survive. Full-stack conglomeration becomes the only viable model. And innovation slows - not because fintechs lack capability, but because they can’t afford to build at those price points.

In fact, RBI has leaned into the whole “free infra” piece even more, by promoting interoperability, and not talking about monetization at all

1. 🔴 Issue #1: Free DPI compresses margins not addressed: Not mentioned. Infact this gets worse, there is more “free infra” (assumed free due to absence of monetization framework) such as the AI powered payments piece. In fact, with the focus on “greater good” type initiatives, interoperability - somewhere, I’m questioning ohw sustainable this ecosystem is. We cannot keep relying on government subsidies. And let us be honest, in this whole “narrative” of keeping these as ‘public good’ it is the average Indian who is funding this from taxes. If I’m anyway paying for it (indirectly), then why not just make it into a framework that promotes innovation, instead of stakeholders having to rely on government handouts?

2. 🔴 Issue #2: 0 MDR benchmark not addressed: There is nothing on pricing or a monetization focus in the fintech sector. Now, while there have been reports that the Standing Committee of Finance is evaluating some MDR on UPI (per calculations, global benchmarks are at 0.3% MDR, and UPI requires 0.15% per transaction to sustain the eecosystem. For calculation details, you can check out my article on this here: [#56] FY25 Budget Implications on UPI (Part 1): MDR on regular UPI transactions is now essential. But it is very surprising that despite all the chatter, all the proposals, there is nothing about this in the 2028 vision document for payments!

3. 🔴 Issue #3: Innovation in products, but no incentives to make them sustainable: Interoperability in TreDs, the centralized payments data. Great initiatives, sure. Who’s going to pay for it? And then what incentives are there for businesses actually operating here?

4. 🔴 Issue #4: DPI as a competitor to the private sector. This gets worse. TreDs, PaSS etc. Add to this the whole push of ULI, ONDC. The BHIM App piece that I already mentioned. What’s the point of waiting for innovation to come in and building a competing product centrally? This actually de-incentivizes any innovation here.

5. 🔴 Issue #5: And because of the above, the whole issue of “full stack” being the only way forward, and it being an uphill battle for newer TSPs / players in the market to come in, since monetization depends on scale, is still not solved.

6. 🟡 Issue #6: Smaller TSPs should not have the same regulatory burden as scaled up fintechs: This is partially solved with the Small Payment System Provider (SPSP) tag - which doesn’t make regulation a blocker atleast. But, regulation was only one half of the issue. Monetization was the other. No mention of this in the doc.

The verdict: RBI doesn’t just not address the margin problem - it doubles down on the same approach.

More free infrastructure, more standardized rails, more public goods. The SPSPs framework is a nice gesture for small players. But it’s treating the symptom (hard to get a license) rather than the disease (nothing to monetize once you have one).

A concern: The Agentic Payments blind spot

And now for what I find most striking. There is absolutely nothing in this vision about agentic payments, and agentic commerce in general.

Globally, this space is moving at breakneck speed. Stripe launched MPP (Machine Payments Protocol). Coinbase’s x402 has crossed 150M+ transactions. Google launched AP2 and UCP. Visa launched TAP. Mastercard has AgentPay and “Know Your Agent” protocols. Alipay hit 120M weekly agentic transactions. And in the machine payments world, stablecoins are becoming the default settlement rail — Stripe acquired Bridge for $1.1B, Mastercard bought BVNK for $1.8B, Visa partnered with Bridge for stablecoin cards.

And, an argument that could be made is: it’s because the Indian consumer - the average Indian consumer is quite some time away from using agentic commerce. And more immediate needs are: more access to credit, insurance, savings, and wealth management products.

But, the agentic economy is not just about consumers using AI. It is also about systems being upgraded, so that they are “AI native” or “AI friendly,” so we are prepared for the next decade.

In some of my past pieces, I’ve talked about how AI is a layer on TOP of existing systems and data. And if those systems systems, and data are not AI friendly (and what I mean by that is: systems for agent identity, systems build for agent querying, which will need higher TPS as compared to humans, data schemas being standardized), privacy and encryption guardrails built to protect against jailbreaks, AI will never work. Garbage in, garbage uut.

RBI’s Payments Vision 2028 mentions none of this. Zero. Not stablecoins. Not agentic payments. Not machine-to-machine transactions. Not autonomous commerce. Not AI agents initiating payments.

In a document about the future of payments through 2028, the fastest moving segment in global payments doesn’t get a single line. That is very surprising to me. Because, its not really about consumer behavior at this stage. It is about system capability.

👉 In Agentic Payments for example, the real test is whether banking systems can adapt to recognize new payment authorities - AP2 mandates, Visa TAP tokens, delegated credentials. If the issuer bank doesn’t recognize an agent-initiated payment instruction as valid, it doesn’t matter how elegant the protocol is. And it isn’t even about these protocols - it is about using the computing power of LLMs, and AI to improve experience, and optimize away inefficiencies. That requires structural changes. RBI’s vision document doesn’t even acknowledge these protocols exist. It talks about a central payments data system that can be queried using “AI” but it really start at the foundational level - that to do this, it will also require systems to be AI first.

I predicted that “friction is a feature, not a bug” and that fully autonomous payments are years away. RBI’s silence on agentic payments actually aligns with this view - they’re not building for autonomous agent payments because they don’t see it as imminent.

Maybe they’re right for now. But the infrastructure gap between India and markets where these protocols are being actively deployed will widen. And when the shift does come, India will be playing catch-up. So the answer, at least for the next three years in India, seems to be: the banking system won’t adapt, because the regulator isn’t asking it to. And that is where my trepidation lies.

👉 And on stablecoins specifically, there is absolutely no mention: This is particularly jarring given that RBI’s own FEMA amendment (October 2025) unlocked holding foreign currency accounts for exporters for more time (1 month to 3 months). The cross-border section of this document talks about reducing friction - but doesn’t once mention stablecoins as a settlement rail, even as every major global payment company and network is investing billions in exactly that.

Despite the above, there are some opportunities that can be inferred by reading of this document

Despite the gaps, and maybe partly because of them - there are real opportunities if you read between the lines.

1. Cross border infrastructure - tailwinds

The single-window authorization is a genuine unlock. Anyone building cross-border rails: remittance, trade finance, FX, export payments should benefit from reduced regulatory friction. This helps both fiat-native models and stablecoin-settled models (like OpenFX, which settles FX on-chain with local fiat pools)

The FEMA simplification + TReDS interoperability + foreign currency account unlock is a three-part combo that could meaningfully expand the cross-border trade finance market. If you’re building in this space, the regulatory tailwinds are real. However, monetization questions etc are very real.

2. Fraud and risk infrastructure from a “beneficiary bank” perspective

Shared fraud liability + Cyber KRI framework = demand for fraud detection, risk scoring, and KYT (Know Your Transaction) tools. Every bank and non bank PSO will need better fraud infrastructure to manage their new liability exposure, from a beneficiary perspective. Before this document, the liability was 100% on the issuing bank.

3. MSME Financing via TReDS expansion

TReDS interoperability + export receivables access as well as factoring “with recourse” could be an opportunity for banks / NBFCs and especially some newer tech focused NBFCs to look at invoice discounting as a possible opportunity. The interoperability part isn’t great for the platforms that are facilitating this, but for lenders / financiers it reduces risk liability.

This could also signify tailwinds in the MSME financing space.

4. Enabling usage of payments data and analytics in a secure and monetizable way

While I’m not too bullish on this idea of a “central payments database” - I still have a lot of open questions on the practicality and execution of this. And the companies that have built proprietary payments data advantages could see that edge disappear - something like this is akin to “scaled up players” subsidizing efforts of newer competitors to build their own intelligence.

But it does look like that somewhere, the regulator view is that there is a lot of “alternate” data that can and should be used to improve risk models, lending, and so on. The opportunity then, are tools that enable this: data encryption and privacy, enabling computing on encrypted data and inference sharing without the raw data EVER moving. (Something that the company I current work at does by the way, so if you’re a payments company interested in exploring some of these options feel free to DM).

Now of course, a lot really depends on the opportunity to monetize this. If the view is that companies should share this free of cost, then good luck to everyone.

RBI Payments Vision 2028 is “payments plumbing” vision, not a “payments economy” vision. It talks about how money moves. It doesn’t talk about who makes money moving it.

Fraud accountability, cross-border simplification, this is all overdue, all welcome. It makes India’s payment infrastructure safer and more resilient. On those terms, it delivers.

But the structural issues that everyone who is a fintech operator has been talking about: margin compression, DPI crowding out private innovation, the zero MDR pricing problem, standalone players being squeezed out, remain completely unaddressed. If anything, this document reinforces that trajectory. More free infrastructure, more standardized rails, more public goods. The destination for Indian fintech stays the same: full stack conglomeration or death.

And the next wave of fintech innovation - stablecoins, agentic payments, machine to machine transactions, ensuring that systems are prepared for whenever this wave hits India, don’t exist in RBI’s worldview. The global payments stack is moving toward agent native, stablecoin settled, autonomous flows. India’s regulator is still building for a human to merchant, bank settled, friction as default world.

The opportunities are real - cross-border infrastructure, fraud tools, and MSME financing, But they’re at the edges, not at the core.

The core remains what it was: free rails, compressed margins, and a regulator that keeps building competing infrastructure while asking the private sector to innovate. At some point, something has to give. This document suggests that point isn’t 2028.

For those of you folks who have been following along, a theme that I’ve been trying to really understand over the last 6 - 8 months, is more about is the world of agentic commerce. You can read my previous articles on these below:

1. [#75] The AI Money Movement Layer: MCP, ACP & TAP are launched but are autonomous payments really the future?

2. [#80] Google’s UCP & AP2: Moving agentic commerce from just “plausible” to “scalable”

3. [#83] The AI Money Movement Layer (Part 2): 5 Blueprints Built on the Same Core Principles

TLDR, the hypotheses formed, and what the market seems to be validating are:

1. Agentic commerce is shopping x payments. Shopping can happen via LLM chats, chatbots etc, but payments (and fintech in general) is not just an “experience” layer. It requires trust. And that is why Open AI is rolling back its “Instant Checkout.” The vision for this was: Complete everything IN the AI checkout itself. But barely anyone onboarded.

2. There are fundamental issues with todays systems, which make agentic payments hard to pick up. I’ve talked about this before, but a quick example is why Alipay AI worked, and why others didn’t. Alipay owns the acquirer stack (payments PSP), and the issuer stack (customer app + takes the onus of verifying customer identity). So everything is just Alipay integrating. Now, take a look at current fiat systems:

But all of these payment protocols are still fiat stack first.

And secondly, and more important, all of these see this more as a human delegating a task to an agent, and then the agent completing the task end to end. The product being bought here is a “human consumable” good. In the case OpenAI’s - Instant Checkout - they partnered with Shopify - an ecommerce website. Razorpay partnered with Bigbasket. All human goods.

What hasn’t been considered (in the mainstream world, x402 has actually been around since May 2025) is an agentic flow for a “machine consumable” good. A better way to understand this: Consider a flow where an agent is carrying out some task autonomously. In that workflow, the agent needs to access a paid service or endpoint. This endpoint charged per API call. The agent has to do a payment or submit some sort of proof of payment to complete the task.

THAT is what Stripe’s MPP, and x402 are trying to solve. That if there is an agent carrying out tasks, and needs to consume some API which is paid, how do they complete this payment (usually a micropayment) WITHOUT having to constantly have a human in the loop?

Every payments player in the world today is trying to launch their own protocols for agentic payments.

Till now, the chatter in the agentic world has been more about users wanting to buy something, doing that shopping on a LLM layer, and then wanting to pay seamlessly, via or through the agent platform, either through some embedded, or a redirection experience. Google with its AP2 (mandate based auth) + UCP (a unified protocol to do shopping + standardize payments), Alipay (with its fullstack), Stripe (its ACP, which utilizes its SPT) all consider the flow in a commerce flow or what I’m calling a “human consumable” good. You can check out the table below.

So, then, in this whole agentic payments flow, while everyone and their aunt is trying to launch their own protocols, it’s also important break agentic commerce into: agentic commerce payments, and machine payments.

This space is more like a spectrum from micro- machine payments, to human in the loop is agentic commerce

And with these two sitting on opposite sides of the spectrum, as the transaction amount becomes bigger, and the frequency of purchase per user becomes lower, there is an increasing need for a human in the middle, and additional auth measures, such as 2FA, biometric, passkeys, and so on.

1. Micropayments in the agentic workflow for machine consumable goods: An agent is tasked with building something, or paying for something, and needs access to a paid service for this. Could be some APIs, or access to some data. Agent decides and pays autonomously. Protocols for this: x402, MPP (which we’ll get into later)

2. Agentic commerce for human consumable goods: A human is buying a “t shirt” or some item of furniture let’s say. So the agent helps discover, select, negotiate, and the human approves. The agent then needs to call checkout, and the agent then executes the protocol: UCP, ACP, AP2

What is clear is that while the agentic commerce stack will always have a fiat angle to it, the machine payments stack is very obviously betting on stablecoins as the default layer

Now, this market still has a long way to go. It is still early days. But, the deeper you go into understanding some of these systems, the more I genuinely believe that stablecoins will be the default layer for a lot of the agentic workflows. And specifically, for machine payments.

But should stablecoins be the native payment rail for machine payments?

In agentic commerce, it could still be fiat: if we go by the thought process that transactions for human goods is (relatively) more occasional, and of a higher ticket size. In machine payments, when we are talking about things such as paid endpoints and so on, and transactions can go into hundreds or thousands per day, stablecoins just make more sense, not just from a “number of stakeholders” involved perspective, but from a cost perspective.

1. Fewer stakeholders, fewer hoops to jump through

A traditional card payment touches 5+ intermediaries: issuing bank, card network (Visa/Mastercard), acquiring bank, payment processor, and sometimes a payment facilitator. Each adds fees, compliance requirements, and latency. Settlement takes 2-5 business days. Compare that to stablecoins. A stablecoin payment needs one signature from one agent. (which should be ideally a MPC based threshold signature to ensure maximum security). The transaction settles on-chain in seconds to minutes. No interchange network, no card association fees, no dispute arbitration layer. An AI agent with a wallet can autonomously pay another agent or APIwith no bank account, no KYC flow, no human in the loop. My core point here is that: Fiat payment rails were designed for humans transacting with merchants during business hours. Machines transact 24/7, at millisecond frequency, across borders. The legacy stack wasn’t built for this, and probably cannot support the volume of payments in any case

2. Fiat systems usually charge a fixed fee + some % of the transaction. In many cases, you can end up paying more in fees than the amount you’re receiving, in the case of a micropayment

Lets take an example. Let us assume that an agent needs to pay $0.1 for something.

Now, in fiat rails:

1. Payment amount: $0.01

2. Paypal charges (link to website): Charges 3.4% + a fixed fee. This fixed fee as per the Paypal website is $0.3.

3. So then: total processing fee = $0.30034 (3.4% of $0.01 + $0.3)

So, the merchant receives $0.01. But pays $0.3. Where is the sense?!

Compare that to stablecoin rails:

1. Payment amount: $0.01

2. Solana charges (link here): Can range between $0.0001 and $0.001.

So merchant here receives $0.009 - $0.0099 or ~90% - 99% of the transaction amount.

Now, there are other barriers that stablecoins obviously have to cross. They win on speed, structurally being able to provide micropayments, and the authentication (Stablecoins require a cryptographic signature, while fiat platforms usually require some tokenized credentials, and in some regions need a 2FA) The barrier to solve for stablecoins MAINLY as I see it is user familiarity. The fact of the matter is that there is no way to get around wallet funding. You can make wallet creation as seamless as possible, but there will be a wallet funding step, and for the average user, they may not even know what stablecoins are. But that is from an agentic commerce step.

For machine payments - its just a type of “currency.”

It looks like existing platforms with distribution: Coinbase and Stripe are betting on agentic machine payments and stablecoins

Stripe published its repos for machine payments. And for MPP as per the github repo, it support crypto payments, and more specifically stablecoins as well as fiat. x402 by Coinbase supports stablecoins (USDC exclusively). But before we get into what these are, let’s take a step back, and first try to understand the market for ‘machine payments,’ and why should we even care about this space?

What’s the market size for machine payments?

Honestly, this is hard to size. This isn’t a market that existed before, and there are a lot of assumptions we will have to make here. All the data I can find right now is for the entire agentic commerce market, which I presume includes both the transactions for “human consumable goods” and “machine consumable services.” Various estimates show that different reports are estimating this market to be in the 10’s if not 100s of $billions. Lots of assumptions have been taken, mainly around first estimating the total global payments volume. Lets map them out:

• In 2025 according to a Mckinsey report the global payments volume was $2 Quadrillion (that’s fifteen 0’s btw).

• Then, another Mckinsey report, also estimated that the agentic commerce market (volume, not revenue, I assume this includes agentic + machine) could reach ~$3T in 2030. As a % of total global payments volume, this is 0.15%. And then some % of this, I would assume would be machine payments.

• Very crude, but lets just assume the % of machine payments (of agentic commerce) to be 1%. No scientific reason, just taking this number randomly: Calculations suggest is a market of $30B!

So there is a significant enough market here, in terms of value. And today, in terms of ACTUAL traction, not some numbers done on a spreadsheet, suggests that while it is early stage, it is showing promise.

Let us look at another statistic. Coinbase’s x402 protocol has processed 150M transactions ever since it was launched in May 2025. And when I say transaction, what I mean is, any time an agent (or script) sends a payment through x402 to access a resource. So this can mean:

• Agent paying an API for data (market signals, sentiment, leads)

• Agent paying for compute or storage

• Agent paying another agent for a service

• Agent tipping, micro-purchasing content

This is a big deal. 150M transactions are not nothing. Granted, out of a global payment volume (# of transactions) of 3.6T, this is 0.00004%. A blip. But in terms of absolute transactions, and potential market size, ($30B), the number we calculated earlier, this could be big. And that is probably why everyone is rushing to launch their own machine payment protocols - like Stripe with MPP, and x402 with Coinbase.

What is MPP? (Machine Payments Protocol?): Well, it uses the long unused HTTP 402 status code to enable agents to pay automatically for resources

Well, this is a payments protocol co-developed by Stripe and Tempo and launched in March 2026. Tempo Labs is a blockchain startup incubated by Stripe and Paradigm.

MPP is made for an agent first world: it essentially allows AI agents to automatically pay for resources like API calls, data feeds, and computer power using a “challenge-response” flow, and it does this using the HTTP 402 payment code (unused since 1997!)

MPP is a request-response protocol that adds a payment step to any HTTP API call. That’s it. Everything else is plumbing. For the uninitiated, whenever you make ANY call on the internet, you’re making a HTTP call.

To understand MPP, lets go back to the absolute basics, and first understand what HTTP is.

Any HTTP call has the following components:

So, now, let’s say you want to check the weather in Chennai. You open up your browser: Google Chrome, and type in: what is the weather in Chennai? Your browser makes this HTTP call:

REQUEST:

• Method: GET (since you want some data)

• URL: https://www.google.com/search?q=what+is+the+weather+in+chennai+today

• Headers: User-Agent: Chrome/120 on Mac, Accept-Language: en-IN, Cookie: (your Google login session)

RESPONSE:

• Status: 200 (OK, here you go)

• Body: <html>...the entire Google results page...</html>

So, essentially your browser sent a GET request with your query in the URL, Google’s server processed it, and sent back the full HTML page you see.

Now, here’s what is elegant about both the MPP and the x402 solution. It doesn’t use anything that wasn’t there, which is where HTTP status code of ‘402’ comes in.

HTTP has existed since 1997 and is one of the building blocks of the internet.

HTTP responses have multiple status codes. 200 means: “here you go.” 404 means doesn’t exist. 402 already existed, but no one ever used it until now, which essentially is the response code for “pay me first.” So, now, to explain this in an easier fashion, let me use the same example I used above: fetching the weather, and show it also in an agentic workflow.

Workflow WITHOUT payment

Pretty straightforward. I’m using the example I talked about above. I make a HTTP call via my browser to Google. Google in turn makes a HTTP call to a weather API / server (using the exact format I mentioned earlier), gets a JSON response back, and then converts it into a pretty weather card that it embeds into your search results.

Workflow WITH payment using the Machine Payments Protocol

This is where the Machine Payments Protocol that Stripe co-developed with Tempo has come in. Essentially what is happening here is that, while today, this Weather API is free, let us assume in a world, the agent, or the LLM is making a call to a paid resource. Now, in this situation, instead of going through a human flow, the agent is able to leverage the 402 response code to understand that:

1. It needs to make a payment to get this service

2. It needs to make a payment in a way that the service can verify it.

But the 402 status code anyway exists. What is MPP coming and doing exactly?

Well, think of it this way. 402 existed, but there was no instruction on what to do here to proceed with payment.

👉 So, in a pre-MPP world, if payment was required, either there would be a response that said 402, and that is it, or some sort of custom message, which said: hey - buy a subscription, or something else.

MPP essentially gives the agent some instructions on WHAT it needs to do to actually proceed with this payment / or provide proof of payment, and access the service.

👉 So, in a post MPP world, while both sides do need to speak MPP, there is now a way to ask for payments, and for the agent to know, what it needs to do to verify the payment. The mppx library is the thing that generates that structured body. Without it, the server wouldn’t know what format to return, what challenge nonce to include, or how to verify the credential when the agent retries. So, here, the server (in this case the Weather API service) needs to have the MPP library installed so it can GENERATE challenges and VERIFY credentials. After the MPP library is installed, if this action requires a payment, the response back to the agent would be something like this:

Server: 402 Payment Required

• Body:

  • {“type”: “payment-required”, ← always this

    “challengeId”: “ch_abc123”, ← always present

    “amount”: “0.01”, ← always here

    “currency”: “usd”, ← always here

    “methods”: [...] }

For the agent to proceed, first it needs to have a MPP aware wallet, so that it can read the challenge, and then send the credentials. If only one side has it, nothing works: Example: Server has MPP, agent doesn’t → agent sees 402 and doesn’t know what to do next. If the Agent has MPP, server doesn’t → server never sends a proper 402 challenge in the first place

The next question I would have here, is: what is an agent wallet? And what needs to be done to make it “MPP aware?”

So, to think about it in a rudimentary way, think of this agent as a code running on a server. For it to execute this payment, it needs to:

1. Money somewhere: either in a bank account, or in a crypto wallet

2. It needs a way to move that money

3. It needs some sort of way to authorize that money movement: either access to some card credentials, or, what is in the case of crypto payments: needs to have some sort of MPC enabled wallet, which enables threshold signatures to authorize the transaction.

A point that I have come across is: why can’t you just give this agent access to a card or something?

This is an easy one to answer. Security nightmare. You cannot just hand over your card details or API keys. If this agent gets hacked, then your details can be used by anyone! So there needs to be some middle layer that already holds some funds, which have been pre-approved, or holds some hashed credential that references your real credential stored somewhere else. (An example is something folks are familiar with: the whole concept of card tokenization. The actual card details are stored in the network - like Visa or Mastercard, or now, increasingly PSPs. What the payment player, or in this case, the wallet stores is a tokenized reference to that card number, which the network, or the PSP can use the map, and look up the actual credential).

This is where the agent wallet comes in. This is the “container” that the stablecoins, in case of a crypto rail. In the case of holding a tokenized credential, (if fiat rails are used), a wallet may not be required, just access to the credential should be enough

This is essentially the wallet that the agent has access to, and that has the MPP server installed, so it can read the challenge, and understand what it has to do next to continue with the transaction. MPP is developed to support both: crypto and fiat rails. You can check them out more in Stripe’s documentation here.

The crypto native method in MPP

This is similar to the stablecoin payments stack I discussed earlier. This requires some sort of agentic identity (usually via an agent platform) to be registered. This probably requires some type of one time onboarding of the agent platform with whoever is providing the payment rail (if the Stripe MPP is being used, then onboarding would be required on Stripe).

This is how it goes:

The User flow (note this is the “payment initiator” so it doesn’t have to be an individual, it can also be a B2B player)

1. Agent platform (Crews, Google ADK, even a Claude, ChatGPT, which runs the agent that you as a user create) is onboarded as an agent on the entity enabling these rails (Stripe, Mastercard, Visa etc), and enable stablecoins / crypto as a payment method

2. This user would need to create some sort of wallet (if it is Stripe, then they would use Privy), and link this to the agent

3. This wallet is funded with some stable-coins, so there is some on ramp happening here: either via an off ramp provider, or via a direct exchange integration if it is a B2B agent flow

4. The key management is handled by an MPC provider (like Silence Laboratories), which shards the keys, to provide the highest level of security

The merchant flow (note: this is the “payment accepter” flow)

1. The merchant does need to sign up on Stripe, and first enable stablecoins and crypto. This is important, because in certain regions, this isn’t available

2. The merchant then needs to install the mppx (MPP) library

3. They then need to define what service is paid for (example, if an agent calls API X, is that paid? Or is API X free, and API Y is paid?)

4. They need to set a price per API Call

5. They need to set up the method that they allow (crypto - on Tempo)

6. Generate a server secret key (for challenge binding - the challenge needs to be signed by this key, and a hash created by the merchant for authenticity, and this is what the merchant checks against when the agent pays, and presents the payment proof )

Obviously, the above set up happens prior to the payment. At the time of payment, if this is a paid service:

1. When the 402 status code is sent, this contains the deposit address. So here, the “payment intent” has already been created by Stripe. The sequence is: - the agent calls the paid API. The merchant server calls Stripe: “Create PaymentIntent, crypto, Tempo”. Stripe returns: PaymentIntent + deposit address 0xABC. Server caches 0xABC. Server returns 402 with 0xABC in the challenge body

2. The agent selects the Crypto method to pay, accesses the wallet with the stablecoins, signs using MPC, transfers the money to the entity wallet, and then retries the original HTTP GET Call with the payment authorization (this is the challenge ID + payment credential) in the header.

   • Agent → Server: “GET /weather?city=chennai”

   • Authorization: MPP <credential>

3. Server checks the challenge validity, deposit address, and the Stripe monitors the blockchain (Tempo) and confirms when the funds land, usually in ~2 seconds, and returns the 200 response (OK)

✅ TLDR: The agent platform being used by the user needs to be onboarded as a platform on Stripe

✅ Both need to install the MPP library, so that the request / response structures are defined - each party knows what to do

✅ Both need to set up: the user needs to set up a wallet and fund with stablecoins. The merchant server needs to define endpoints, methods enabled, and generate the server secret key to sign the challenge.

✅ Payment happens autonomously since everything is already defined.

The fiat method in MPP

This is slightly different, since this doesn’t really require a pre-funded wallet. The key differences are, that there is no wallet created, just the agent has the payment credential linked. And, this is done using the SPT: so, in the crypto method, the Payment Intent is created before the 402 response code is sent, and in the fiat method, the payment intent is created after the 402 response code is sent.

So, breaking this down into the same user flow:

User flow (Client)

1. Firstly, whatever agent the user is using needs to be onboarded on Stripe

2. Then, the agent needs a Stripe-linked payment method. This means:

   1. A Stripe Customer exists (cus_123)

   2. A PaymentMethod is attached (card_tok_ABC) to the agent. This is done via Stripe Elements or API, where the payment method is created, attached to the customer, and then the customer ID and the payment method is stored in the agent configurations, so it knows that this is a payment method it could use.

   3. This is the “card credential linking” step - done once by the user

3. This is Key difference from crypto: There’s no “agent wallet” in the crypto sense. The agent just has a reference to a Stripe customer + payment method. The money stays in your bank/card.

Server (merchant side)

1. Server (Merchant) Side:

   1. Sign up on Stripe (this would be the standard flow - there is no need to enable stablecoins), and install mppx library

   2. Configure server (Define paid endpoints (i.e. which endpoints does the agent need to pay to access, set the price, set the Stripe Shared Payment Token method: accepted payment methods (card, Link), and provide their Stripe secret key to set this up

Payment flow

So, since this is fiat, this is a little different. It’s not as simple as the agent already having policies set up to pay. Instead, when the 402 status code is sent back (with the challenge, and the methods that the merchant server accepts, which could include both crypto and fiat), and the agent has the fiat method enabled, it uses the stored customer ID, credential, and calls Stripe API to create a Shared Payment Token (SPT). This is what is sent to the Server as a response to the 402 code.

The merchant server then sends the SPT (amount, customer ID) to Stripe. Stripe checks the details against the SPT that was created by the user’s agent (which should be the same). It verifies that everything is fine, and then the mppx library and Stripe create a payment intent for and then charge the card.

✅ TLDR: The onboarding steps on Stripe are similar. What is different is that for the crypto method, the merchant server is creating the payment intent, and sending back the deposit address along with the 402 response code. The open question I have here is what if both the methods are enabled by the merchant, and how will the merchant know in advance if the user will pay by crypto? I’d look at this the other way, and say that the mppx library probably enables the merchant server to send back the 402 response code, and ALL the options that the merchant has enabled, even if it doesn’t know what the user has. It’s on the user’s agent to pick what works best for them.

✅ Both need to install the MPP library, so that the request / response structures are defined - each party knows what to do

✅ Both need to set up: the user needs to set up a wallet and fund with stablecoins. The merchant server needs to define endpoints, methods enabled, and generate the server secret key to sign the challenge.

✅ Payment happens autonomously since everything is already defined.

A point to note here is that Stripe is the central authority here. Everything is done by calling Stripe to create a payment intent, create a SPT, and verify money movement. Stripe is taking the responsibility of being that central authority through which every transaction passes, and running their own risk / fraud checks basis that.

So that’s MPP. So then what is x402 by Coinbase? How does it work?

x402 is a payment protocol for machine payments, that was created by Coinbase in May 2025. It’s now reportedly maintained by the x402 foundation, which is co-founded by Coinbase, Cloudflare, Google & Visa, which joined later. It uses the same HTTP 402 status code.

Current scale: 75M+ transactions, $24M+ volume, 94K buyers, 22K sellers in last 30 days. So this isn’t insignificant. It’s still a blip in the ocean sure (reports suggest that global volumes are 9.8B digital payments a day), but this shows potential.

The two major differences between x402 and MPP is: in MPP, Stripe is the only verifying entity. In 402, Coinbase is the default, but there are multiple. And the second: x402 ONLY supports stablecoins, not fiat, unlike MPP, which supports both

From what I could gather (and of course, this is basis my reading and interpretation), x402 doesn’t really require onboarding on anything. Stripe and MPP for example requires onboarding because it is the central authority, and you are calling Stripe APIs.

👉 So like you install the mppx library, here, both parties need to install the x402 library (which is a line of code that probably goes like import x402). There is no central entity that entities need to onboard on.

👉 The payment initiator needs to create a wallet, fund it (on ramp), and link that wallet to the agent, and give their private key, along with policy set up, so that when the HTTP 402 response is sent, the agent can handle the response using the x402 library, and use the wallet to send over the payment credential

Now, this is where the difference in MPP and x402 comes in: there is a 3rd party Facilitator that enables wallet to wallet transfer - doesn’t require any onboarding like Stripe

In MPP, if its crypto, then the merchant server calls Stripe APIs to return back the “crypto method” and the “merchant deposit address.” If it is fiat, then the agent calls Stripe APIs to create a SPT, and share with the merchant. In both cases, Stripe is being called in the middle.

In x402, none of that is happening. When the agent calls the paid endpoint, if the merchant has the x402 library is enabled, then the x402 protocols are called, and along with the HTTP 402 reponse code, the merchant deposit address is sent.

👉 Now, here: the x402 library in the agent code reads the response code, SIGNs an authorization, and sends that back to the merchant server. The x402 library in the merchant server calls the Facilitator (which is Coinbase), which connects to the blockchain, sends details, and ‘facilitates’ the transfer. While MPP currently just supports Tempo (blockchain incubated by Stripe), x402 supports 10+ blockchains, including Base, Solana, Polygon, Ethereum and so on.

So, in MPP Stripe handles everything. It gives the library, gives its APIs to create the intent or the SPT, monitors the blockchain for fund transfer completion, and / or charges the customer card

Compare that to the flow we just walked through. x402 is a decentralized service. You just need a line of code to enable it (along with your wallet set up, on ramp and so on). The merchant needs to choose a “Facilitator” that communicates with the blockchain.

Now, x402 has seen scale (150M+ transactions), but it has been around for a year. MPP has just launched. The problem I have always had with blockchain transfers is the lack of regulation, dispute management, and a central authority who is actually imposing fraud and risk controls. That is being solved by MPP. So even though there is an “extra” entity here, and an extra step of onboarding / KYC etc, to create a Stripe account, and enable it - my view is, when you’re moving money, it is okay if there are a few extra steps. Friction is a feature here.

HTTP 402 is just a way to send back a payment requirement, and then require the agent to show proof of payment

This is not a situation where you can ONLY pay on the go. All it requires at its core, across protocols (MPP, x402), is just a way to prove that you’ve done the payment, or the payment is authorized. How to check it, or broadcast details, or facilitate fund movement (in the case of x402) is something taken care of by the installed protocol library. The agent just needs to show a payment credential, or an authorization. That can be pay per use, some sort of token received when the bundle was paid for (ex: enterprises may pay for 10,000 API calls upfront), or even a subscription token if its a subscribed service.

The direction is clear: stablecoins are where payments are headed - cross-border and agentic, human and machine. The market moves tell the story:

Stripe acquires Bridge ($1.1B, 2024), Privy (wallet-as-a-service), and incubates Tempo (blockchain + Paradigm-backed). It then launched ACP, SPT, MPP (2025-2026): Signal: Three protocols in 18 months - agentic commerce, shared payment tokens, machine payments, built on stablecoin rails, stablecoin wallets, and a purpose built chain for agent payments.

Meanwhile, Mastercard acquired BVNK ($1.8B, 2026). A Card network paying a billion dollar price for stablecoin rail, while Visa partners with Bridge + stablecoin-backed cards. The other card network hedging the same way. And OpenFX raised $94M (March 2026). This is a massive round for stablecoin-settled FX - keeps local fiat pools, settles books on chain with its local entities. This isn’t speculation anymore. The largest payment companies in the world are spending billions to position for a stablecoin-native future.

But here’s the honest assessment: we’re at the POC stage. Conviction is there. The product flows work. Stakeholders buy the concept. What we don’t yet know is which flows win.

Will it be MPP or x402 or AP2? Fiat-first with stablecoin settlement (OpenFX model) or crypto native end to end (Coinbase model)? Will agents pay on-chain per-transaction, or batch-settle through intermediaries? The infrastructure is being built in parallel by players who are each betting on different architectures. When the dust settles, some of these protocols and flows will be the standard, and some will be footnotes.

That’s the nature of a POC-stage market with trillion-dollar potential: the destination is visible, but the winning route isn’t.

1. [#75] The AI Money Movement Layer: MCP, ACP & TAP are launched but are autonomous payments really the future?

2. [#80] Google’s UCP & AP2: Moving agentic commerce from just “plausible” to “scalable”

TLDR: What I’ve tried to do over the last 6 months or so, is really understand:

1. What do we mean when we say “agentic payments?”

2. If agentic payments have to be executed, what has to happen?

3. What or rather, who are agentic payments even solving for?

4. And finally: Is this at a “pilot” stage, or this is at a stage where it can be “scaled?”

I’ll try to answer this through the course of this article.

The big idea, when we think about agentic payments, or even “agentic fintech” is that it’ll sit as a system or rather, a ‘sub-system’ that will be called by AI interfaces

The world has now started thinking about fintech and commerce experiences as a ‘system’ that sits within an AI interface. And when we think about this journey from a person's perspective, we think of something that goes like this:

• User: Hey Claude, buy me this Nike t-shirt at less than INR 200

• Claude: (salutes). Yes, doing right away (through MCP).

  • In a frictionless flow: Claude calls payment APIs, executes the payment, and the payment is done

  • In a flow with 2FA, or Human in the Loop: There is a PIN / Face ID step, but this needs to happen natively in the LLM chat. After that, the payment is done

Now, in both flows, the following needs to happen:

• The LLM (or agent) needs to be able to call merchant catalogues. This happens through MCP, and is solved today

• The LLM (or agent) then needs to be able to call Payment APIs. This can happen in 2 ways today:

  • 1) Each LLM needs to have an individual integration with whatever the merchant has built, which is most probably via the MCP. So, in this case, the merchant’s MCP has to handle everything. or

  • 2) Some sort of browser automation, where the agent does whatever a human would do.

There is no standardized way to call these Payment APIs today (this is where UCP comes in)

Also, anecdotally, having absolutely NO friction, is actually a problem in fintech flows, because this is sometimes perceived by the user as a flow that has inadequate risk checks. I’ll give you an example: With the “SMS less flows” that we are trying to implement, we use something called SMV - or silent mobile verification. All this essentially means is that we are using telecom APIs to verify the customer mobile number, instead of a manual SMS output. In a lot of cases, this happened in less than 1 second, but TSPs had to force-add 2-3 extra seconds, since they found the speed or the “lack of friction” decreased the user trust.

In agentic commerce we are trying to solve both the above (calling shopping and payment APIs within the agent platform), but at the same time, figuring out what the ‘right amount of friction is’

Which brings me to the first question. What is agentic commerce exactly? (Now, in my previous article, I did touch upon this a bit, so feel free to skip this section. But this note is important how I’m thinking about it, so for those of you folks who read the last edition in this theme, it may be a little repetitive. But bear with me, I promise there is a concrete point I’m making here!)

That is simple to answer: It’s any transaction flow, where agents initiate, authenticate, and go through the transaction on a human’s behalf. But, like I’ve done before, to un-complicate it, let’s break this down a little more.

Breakdown #1: Agentic Commerce is: Agentic (Shopping + Payments).

→ Shopping: This has to do more with being able to search agent catalogues, or LLM agents being able to connect with different merchants and so on.

→ Payments is the actual flow of initiating the payment (calling payment APIs), authorizing the payment (someone saying that ‘hey - this payment is authorized to happen, this is not a fraud’), stakeholders accepting that authorization (banks, and networks accepting this authorization), and then the actual money movement happening. A key point here is that MCP is a generic tool calling connector, while UCP is specifically for commerce.

That is where the MCP + a standardized payment protocol (UCP) comes in 👇

Breakdown #2: Agentic commerce doesn’t have to be fully autonomous. It can be partially autonomous too

Agentic commerce can mean everything from 1) fully autonomous, where the agent does everything on the person’s behalf, to 2) somewhat autonomous - where the agent may initiate payments, but there is some human step, which could be either ‘pre-setting up a mandate’ or a final authentication step within the agent initiated flow (like a PIN entry, or biometric authentication).

Breakdown #2 is where there are multiple models evolving: ranging from mandate based, to fully autonomous. Let’s break it down

I have covered some of these in part editions of this newsletter, so I’m not going to go through in detail. But TLDR, there are a few different models, by way of which this is evolving. And this also differs due to the way regulations and stakeholders are set up in the ecosystem.

I have covered the flows in how some models of agentic commerce will work. Again, some pieces you folks may have read before, but I’ve tried to go deeper, and really understand what is happening at each step here, and what the user case looks like

Model 1: The Alipay model (full stack + implicit habits). Specific to the fintech / regulatory set up in the region, and really depends on how much ownership is there across the issuer and acquirer auth stack

Alipay owns each leg of the transaction, and so - implementation here is very easy. A question I had is how, since at the end of the day, Alipay may be the merchant’s PSP, but the acquirer and issuer banks also have to agree to accept the “agents” identity here. Now, the way Alipay works is that:

1. When a user gets onboarded on Alipay, they HAVE to link their bank account. The issuer bank in this case is almost “handing over” the authority to authorize payments to Alipay - Alipay is taking the burden of verifying the customer credentials here

2. Similarly with a merchant, Alipay is taking the liability from the bank on onboarding, and authorizing the payment credit / refunds etc to happen

3. Alipay is also the rails in this case: Alipay maintains a ledger and moves money to banks at the end of the day through its internal settlement process.

4. The agent rules are stored in Alipay’s server

5. Alipay has 80M merchants and 1.3B customers using it. It has enough of a behavioural footprint for this to make sense at scale.

So, Alipay has all 3. Issuer bank authorization to move money. Check ✅ Acquirer bank authorization to accept payments. Check. ✅ And, a massive scale of merchants and customers to be able to execute this at scale (80M merchants, ~1B users - this seems high, but is what is publicly reported. I’d still peg this number at hundreds of million). Check. ✅ That is why Alipay’s AI pay hit ~120M weekly transactions in Feb 2026!

And because it has ownership of each leg, getting these banks to accept an agent’s authority, or do risk checks is easier: Alipay owns this, and gives a “liability guarantee” to the banks in case the agent deducts more that was supposed to happen.

In the Alipay model, because of the data they have on customer behaviour, they are able to make a payment truly agentic, just based on past patterns, and what they call “implicit rules”

What do I mean by “Implicit” rules? Well, they are “common sense” boundaries derived from your historical data. If you buy a $5 coffee every morning at 8:00 AM, the system creates an implicit rule allowing an agent to execute that specific transaction without asking you. Example: If a transaction fits your “Habit Profile” (Let us assume you, basis your behaviour patterns regularly buy coffee of less than $5, the agent is is allowed to autonomously execute. If it’s an outlier (ex: shoes worth $200), which cannot be verified basis behavioural trends, the agent triggers a manual HITL (human in the loop check) which could be PIN, tap or biometric check.

So, in an agentic flow: the user would type Alipay’s consumer app: “Hey, get me a coffee from merchant X.” Alipay takes the request, maps it against the user behaviour, approves it as the issuer bank, approves it as the acquirer bank, and then transfers the money at the end of the day, and records it in its ledger.

Model 2: The Network Rails: Mastercard, Visa, via platform / agent onboarding - similar to Apple Pay

I’ve talked about this in detail in previous articles, so I won’t go into details here. But essentially, the user needs to create an agent, and then Mastercard treats an AI agent like an entity that needs its own passport.

• Know Your Agent (KYA): Think of this like KYC. Before an agent can pay, it must be registered as a Token Requestor. It’s a sort of cryptographic identity that verifies what the agent is and its intended purpose.

• Digital Service Provider ID: When a transaction happens, the “merchant” doesn’t see your card number. They see a Digital ID that says: “Authorized by User X, Executed by ShoppingBot #402.”

• Guardrails are pre-set up: You set structural limits on that specific agent ID itself. For example: “This ID can only spend $100/month and is blocked from ‘Gambling’ or ‘Crypto’ categories.” It is like a corporate credit card with a built-in “Category Block.”

How does agent onboarding happen, and how is the agent actually given authority to make the payment?

1. Anthropic registers Claude as an agent platform with Mastercard/Visa (business deal, KYA review, API keys, like how Uber registered with Visa to charge your card).

1. You aka the user link your card inside Claude’s UI (like adding a card to GPay)

2. Mastercard issues an agentic token scoped to you + Claude + your rules

3. Claude uses that token when paying on your behalf

Maybe a more intituitive way to understand this is how ApplePay works

Here’s the thing. Giving an ‘agent’ authority to pay isn’t a new concept. This already exists! Think of all the times that you’ve added your card or payment methods to a separate device - ApplePay or Google Wallet. Let’s look at this example:

→ Platform registered with network (Visa / MC are the network in this case, and a Claude / Apple could be the platform)

→ User adds method into that platform (could be Uber, Apple, Claude - this is equivalent of adding your card to Uber)

→ At the time of adding this method, the card is tokenized, a reference ID to the token is created and stored with the Agent, which allows the Network to map to the correct card, and ‘keys’ are generated (symmetrical keys, aka same key stored in device and Visa servers in case of Apple Pay, public - private key pair in the case of Agentic Payments, with the private key stored in the agent platform servers, in this case Claude). The key is just a way for identifying that this device / agent is authorized to initiate this transaction and NOT a key to your money

→ In a real time flow, passkeys or biometric credentials unlock the private key access

→ Token (DPAN - which the the tokenized card details , agent token) + a request / cryptogram signed with the key is sent to VISA servers. This key confirms to VISA that a registered device or agent is initiating the transanction

→ Visa maps the DPAN to the user saved card (Identity) and authorizes transaction (time stamp, specific context etc) which is in the signed request / cryptogram sent

→ Issuer (Bank + network) approves.

The only difference here is between ApplePay and Agentic payments is that

1️⃣ In the case of Apple, the key is stored in the device (Secure Enclave - separate physical chip in the device, separate from the main processor, supposed to be tamper proof), while in the case of Agentic Payments, it will be stored in the Agent Platform servers.
2️⃣ In the case of Apple, the same key is stored in the device and Visa, while in the case of agentic payments, there is a public private key pair.

Quick thoughts: I am nervous about server side key storage (in the case of Claude etc) - this is a honeypot for attackers. Now, bear in mind, that this private key is not a key to the user’s money. It is a way for the Claude agent to identify itself and say ‘hey, I am allowed to make a request to transfer money. The next step of this is authorizing the payment, which is governed by pre-set up rules by the user, and ultimately VISA takes this decision. However, this is secure info, and ideally should have additional level of security. This is where the industry is moving: to Multi Party Compute (MPC), where this key is further broken and stored in separate locations, in which Silence Laboratories is doing some cool work

A user flow: User does a one time set up on ChatGPT / Claude for method linking. There may be a one time redirection here, since it’s a bad move to enter card details directly into the chat. I’m assuming a one time redirection, and basis that, the tokenized card details are stored with Claude. This is when the private - public key pair is also created. AND, the user has to create some guardrails. Then, at the time of transaction, Claude / ChatGPT will initiate payment using MCP / UCP protocols. Visa will check the agent identity (private - public key), check the method token (map token to real card details), check guardrails (request is within lets say $200). If all is well, it will approve the transaction.

Model #3: The mandate style: Google (AP2 Mandates, using existing mandate blocks, Razorpay + UPI reserve pay)

I’ve written about this in a lot of detail in the past, so I won’t go into it in too much of detail. You can read about it here. High level, this is a way to conduct autonomous payments by pre-setting authorization.

In the case of Razorpay x Claude x Open AI and UPI Reserve Pay, the payment instruction has been set up one time at the merchant

The user flow is as follows: I go to the merchant, and set up a UPI Reserve Pay instruction, which is essentially a payment block on the merchant, of upto INR 1L. This is a limit, against which a user can make multiple transactions on the merchant. It’s different from UPI Autopay, because Autopay is a standing instruction to transfer funds. It isn’t blocking funds in the user account for that transactions on that merchant. UPI Reserve Pay goes and blocks funds in the users account of upto some amount, and debits can keep happening against it. Example: If the limit set up on the merchant is INR 15k, the user can do fifteen, INR 1000 transactions on it and so on.

• Pros: Fully autonomous, and secure, since the user has pre-authorized this

• Cons: It needs to be set up at a merchant level. This may only really work for low value, high frequency transactions.

Google’s AP2: a trust layer that stores mandates

1. The user sets up a mandate on their user app or wallet. This user app or wallet has to be onboarded on AP2

2. The wallet, the user app, and the bank all have a copy of this mandate stored with them (since all have to be onboarded on AP2)

3. The Agent (ChatGPT / Claude) also has to be onboarded on AP2, so that they can sign requests (same logic as above, this verifies that this is a genuine agent initiating the transaction). So for the invisible flow to work

   1. The user must pre-set up the rules on their app / wallet

   2. The Agent (Claude): Must have an AP2 “Identity” (to sign requests).

   3. The Merchant: Must use UCP (Universal Commerce Protocol) to sign the shopping cart.

   4. The PSP (Stripe/Adyen): Must be able to “read” AP2 mandates and pass them to the bank.

   5. The Issuer (Bank): Must be able to verify the cryptographic signatures on the mandate.

The good thing about AP2 is that it is an open standard, so anyone can onboard, and then use it across entities. It isn’t like Stripe’s ACP, which can only be used on Stripe. The problem here though is the same: EVERYONE in this chain has to be onboarded on AP2. If even one isn’t, then it fails. And of course, the same mandate issue: For the user to go and set up mandates per merchant or category can get tedious.

But this is tough to predict, and we’ll see how user behaviour evolves.

Model #4: Tight, context bound token: Stripe (may be the way other payment gateway layers also go)

Stripe uses short lived context to ensure the AI doesn’t go rogue. This isn’t like an “agent” that is onboarded on VISA / MC previously, or some sort of mandate that is set up, like in the case of UPI Reserve Pay, or AP2

• Token Policy: When you chat with an AI (like ChatGPT), Stripe generates a Shared Payment Token (SPT). This token is “created” with a set of rules attached to it, and is created directly by the LLM Agent, by calling Stripe APIs (

• Dynamic Scoping: The policy is generated from the user LLM chat intent. If you say “Buy this $40 book,” the SPT is generated with a policy that literally says: MAX_AMOUNT: 40.00, MERCHANT_ID: 12345, EXPIRES_IN: 15m. This SPT is then passed by the LLM chat to the merchant, which creates a payment intent on Stripe.

• The Integrity Check: Stripe does the validation: it checks if the payment intent amount is < SPT. It checks if the token is expired or not, and if the merchant is as per the SPT. If the agent tries to use that same token to buy a different book or at a different store, the Stripe gateway rejects it instantly because the metadata on the token doesn’t match the request.

• These rules are stored at the Stripe layer, so essentially Stripe is taking that responsibility of making sure that no MORE than the authorized payment basis the token is debited from the client account

So, in a regular flow: Mode A: User in the loop (today)

• User says: Hey Claude / ChatGPT. Book me a flight from A to B under INR 15,000

• Claude / ChatGPT: “I found this flight for INR 12,000. Pay now?”

• User: “Yup, go ahead”

• Claude then opens Stripe Checkout link in browser. User: Sees INR 12,000 on Stripe page → enters OTP / biometric. There also be a flow where this opens in the Claude / ChatGPT chat window using an ‘Apps SDK’ type flow (like what Cashfree has done), so the OTP / biometric step still happens within the LLM chat

• Stripe: Charges card → confirms to merchant → confirms to Claude

So, in the new agentic flow: Mode B: Using Stripe APIs to create a Shared Payment Token, and validate without additional OTP / biometric step needed

• User says: Hey Claude / ChatGPT. Book me a flight from A to B under INR 15,000

• Claude / ChatGPT: “I found this flight for INR 12,000. User approves / clicks ‘buy’ in the chat interface OR could also be autonomous if Stripe tomorrow allows rules to be set up. In fact, with the rumoured Paypal acquisition by Stripe, this could give Stripe a user interface on which the user could set up guardrails very easily, and this could move them more to the Alipay model of things.

• Claude / ChatGPT: Issues the SPT, locks to the specific merchant, and gives a time out in 15 minutes

• Merchant gets SPT, creates a “payment intent” in the backend with Stripe

• Stripe checks the amount in the payment intent with the SPT. If the amount < = SPT amount, then the payment goes through

• Stripe: Charges card (customer details tokenized and saved in Stripe vault - product is called Stripe Link), so this can be used across any merchant on Stripe → confirms to merchant → confirms to Claude

Key point to note: Stripe’s moat: a seamless flow to transact, without pre-set up mandates or native biometric flows, or redirection.

Model #5: Autonomous only till authentication: native flow inside the LLM (Cashfree + Biometric)

This is pretty straightforward, and this is the human in the loop method. MCP is still being used to call merchant APIs, and the Agent is still calling Payment APIs - either directly (like in the the case of Stripe ACP), via UCP (Google implementation), or through merchant MCP (merchant MCP also handles payment). But in cases where there is 2FA, or an additional step of auth is required, that step happens natively within the LLM chat, not redirection.

Cashfree demoed this at the AI summit in Feb 2026, with OpenAI with Swiggy and Mastercard, which allows for native biometric based passkey authentication within the LLM chat. This is exactly like a payment flow today, except the interface is the LLM chat and not the merchant or the payment app.

So, there are different models here, all trying to solve for ‘in LLM chat’ payments, but through different implementations

• MCP → this is mainstream at this point. However, what I’m still on the fence about is if MCP will also be used to handle payments, or will there also be a UCP type implementation that stakeholders will do?

• UCP → Still early days, but this will essentially be another protocol that stakeholders will have to be onboarded on. Merchants will have to build the UCP schema within the MCP (MCP is like the pipes, and UCP is the language: remember, it helps standardize payment states). The thing is, it is still very new, so it’ll take time to figure out what protocol is here to stay: the big players that will win are the one that have distribution for sure, but will it happen via the MCP (with UCP schema), or via MCP calling Payment APIs separately is something we will have to see play out.

But, like with flows with lesser friction: this is probably going to initially work for low value, high frequency transactions.

UPI had 21B transactions in January 2026. And the total value processed in these transactions was INR 28.3L Cr. This is an average transaction size of INR 1305, or $14. This is after UPI processes ~70%+ of online digital transactions, but has some friction (PIN).

It really depends on user comfort. But a lot of the mandate based / guardrail based models of agentic payments will work for habitual, and daily lifestyle transactions. That is because I really don’t see users taking the trouble to do the one time set up, UNLESS they are transacting frequently enough

But despite the different models, the foundations of all AI agents in commerce remains the same:

But some things remain the same. The foundation is the following:

1. The Agent needs to be onboarded at a platform level on the payment providers: be it MC / VISA / Stripe or whoever. So a ChatGPT / Anthropic needs to be onboarded here, and a specific identity given to them so that stakeholders can check this is a verified agent.

2. The Payment method linking needs to happen on the Agent, via a one time handshake. At no point should the saved card details be exposed to the agent

3. Authorization needs to controlled very tightly: either via pre-set up mandates, or contextual tokens in the case of Stripe

4. There has to be a way for the PSP to validate the amount passed by the LLM: this happens through card mandates that the merchant signs, and the PSPs check against - they don’t just blindly trust whatever the LLM agent sends

5. Liability: Who takes the hit if agents go rogue?

Even in this new ‘agentic flow’ payment orchestration will still be required to help the agent route the transaction to the best PSP and method, and will sit on the UCP layer

To understand where they will fit, let’s first look at the e2e flow. Now, putting together everything we’ve been talking about in the above sections. Essentially, the LLM agent calls the merchant MCP, which then calls the UCP to call payment APIs of PSPs. And then subsequent methods are called, depending on what is set up / available, and finally the auth layer comes in, which can be user driven, or using pre-set up mandates.

Now: An open question right now (and this is probably some time away) is that how will the agent route to different Payment Providers or methods? It only has visibility on the methods that have been linked to it. Well, in its current form, the agent will go to whatever PSP is integrated on the merchant for agentic payments. Which isn’t that many right now, since it is still scaling. In the future, it’ll only be able to route basis the methods it has linked to it, and the previous success rates that different PSPs have. This could play out in 2 ways:

• Users link all their methods on Claude. Very unlikely.

• (Drumroll please): An orchestrator layer that has visibility on stored user credentials, and authentication mechanisms like Juspay. It sits on the UCP layer providing the agent intelligence on which PSP to route to basis which the agent takes a decision or show options to the user for a human in the loop flow

What about standalone agentic payment players? What is the scope for them?

I think anyone innovating on the rails is in for a tough time. Everyone big LLM and payment player is going after this, and is probably in a better space to win this, just because of the distribution and ownership of the full stack they already have. Look at the example of Alipay: 120M weekly transactions, and a big reason for this is because they have 1.3B users, and 80M merchants already onboarded. This gives them a lot of leverage with stakeholders, and they already own a big chunk of the stack. So:

• Building a platform JUST for payment agents? Tough: Most of the distribution is there with existing LLMs. Maybe for niche use cases: like BNPL agents? Tough to predict 🟡

• Agent orchestration: The key assumption here is that there will be multiple agents for commerce and payments. First principles: I feel this really depends on the user choice of LLM, and they will stick to that. But this is tough to predict, it is also possible that tomorrow a platform pitching “personalized agents for commerce” wins. 🔴

• Payment Orchestration: Existing orchestration players will win, the nuts and bolts are the same. Every existing PA has orchestration across PSPs and methods 🔴

• Standardizing Payment APIs: Google’s UCP is doing it across PSPs. However, it is tough to cover the long tail, and I feel that it is possible to build a standardization layer here for regional or niche payments. Example: BNPL as a method, or local card payments, or wallets may not be something all PSPs cover. However, the market size is something that may not be big enough 🟡

• Trust and identity of agents: Something I have been harping about this this piece, is that the agent identity needs to created, but at the same time, treated different as compared to a human, since there will be different risk rules as well. Right now, each agent needs to onboard on each platform separately, and have an identity / ID created. Example: An Anthropic needs to onboard on Stripe, Mastercard, VISA and so on. Some sort of cross platform agent identity standard, or scores for agent trust doesn’t exist today 🟢

• Agent specific fraud: Entirely new category. Existing tools don’t detect agent hallucination/prompt injection 🟢

• Data encryption in these new payment flows: Agentic payment flows create new payment flows that don’t exist today. (the whole MCP → UCP → in LLM chat → pushing context and so on). There are multiple unsolved problems: context leakage, cross-agent data sharing, encrypted enclaves, payment DLP

Here’s my mental model on this:

It is tough for newcomers to win on anything on existing rails (orchestration, processing, standardization). Incumbents have distribution, data, trust, and will add “agentic” as a feature. Like orchestration for example. But where standalone players do have a chance to win is on net new categories that don’t exist today. The reason for this is that these are not “adding agentic to existing payments.” These are “new problems created BY agentic payments”

But what I have gathered is: I do think we have a way to go to build the support layers for this

In-LLM payments are inevitable. The pipes are being laid: UCP for commerce, AP2 for authorization, Stripe SPT for checkout, Visa/MC agentic tokens for card rails. Every major player is building their piece. The framework exists on paper, but when it’ll actually fit together is something that will take time.

But fully autonomous agent payments, is something I’m still not bullish on. The history of payments teaches us one thing: friction is a feature, not a bug. Every payment innovation that scaled , from UPI, Apple Pay, contactless cards, they all keptthe human in the loop at the critical moment.

Removing that entirely, and letting an agent spend your money requires a level of trust in AI that doesn’t exist today and may not exist for years. Not because the technology can’t do it, but because a lot of things are not ready yet:

1. Fraud frameworks aren’t ready. Current fraud detection is built for human behavior patterns. Agent hallucinations, prompt injection attacks, are new threats with unproven defences

2. Data encryption is an afterthought. Payment data flows through LLM context windows, MCP calls, and agent communication. Is this actually safe?

3. Business models are unclear. Who captures value in this flow? If UCP is open, AP2 is open, and card rails are commoditized, where does margin live? The Stripe model (own the processor) works. The Visa model (own the network) works. But will the cost of agents themselves be worth the value they bring? Is there a direct revenue / GMV increase that can be correlated to agentic payments?

What will likely happen:

The near-term winner is assisted commerce: the agent finds the deal, builds the cart, recommends the best price, and presents a one tap checkout. The human confirms. This is already achievable (see Cashfree), and doesn’t require solving the trust problem. Fully autonomous payments will emerge in narrow, high-trust, bounded contexts first recurring subscriptions, and pre-approved categories

The companies that win won’t be the ones building the most autonomous agent. They’ll be the ones that make the human in the loop moment so seamless that it feels autonomous: a biometric tap, native flows, passkeys, while keeping every guardrail intact underneath.

1. [#73] From Zero to Live (Part 1): Building an AI powered app using Cursor, Lovable and other tools

2. [#76] From Zero to Live (Part 2): Testing Emergent’s AI built backend

I went and bought myself a Claude subscription (Claude Pro), which was ~ $20 a month. Reader, this is the CHEAPEST tier of Claude Code (which unfortunately does not have a free tier). And, being the cheapest, it also has limited tokens, which get over pretty fast if you’re just starting out on it. So it took me some time to figure out what to do with it, and how to optimize this (hint: set up a free API key for gemini, and run that within Claude, but more on that later).

So let’s start from the absolute basics. What is Claude code?

Claude Code is Anthropic's CLI tool - you run it in your terminal, and it acts as a coding agent. It’s not just your friendly neighbourhood chatbot where you copy and paste code snippets and context. It reads your files, writes code, runs commands, commits to GitHub, deploys apps. It's an agent that operates directly on your file system. You can pretty much do whatever you want with this, it’s just a matter of you setting up your prompts and planning correctly - and this is where Claude MD, and Claude Skills come in, which Linkedin is all awash with these days. But there is a tone of caution: if this is used well, this stack can turn AI from a smart autocomplete into a junior engineer, but if you don’t know what you’re doing, it’ll spin up a pretty looking UI that will be broken at the backend.

Public Service Announcement: While it isn’t hard to set up, it did take me an hour or so. After buying the subscription, you have to open up the Terminal on your own laptop, install it, and then authenticate yourself (since you need to buy a subscription to use this). And then of course, just getting used to the look and feel of how this tool works, connecting it with different sources of data, will take some time.

Phase 1: Installing Claude Code

If you’re moving your workflow into the terminal to use Claude Code, you’re going to meet a tool called Homebrew almost immediately. Think of Homebrew as the App Store for the Terminal. macOS is great, but it doesn’t come with a built-in way to easily install developer tools (like Python, Node.js, or Claude Code). Homebrew fills that gap. You type brew install <package>, and it handles the downloading, moving, and updating of that software so you don’t have to manually drag files into folders.

Why it failed the first time (The “Invisible Path” Problem)

If you tried to install Claude Code and it felt like you were screaming into a void, you aren’t alone. Based on my experience, the software usually is installed, your computer just doesn’t know where you put it. Every terminal has a PATH. This is a literal list of folders the computer checks whenever you type a command. If the folder containing claude-code isn’t on that list, the terminal just says: command not found.

From googling this issue, and using my trusted Gemini / chatGPT combination, the issue basically was, that the official curl installer sometimes finishes its job but forgets to tell your terminal’s “brain” (the .zshrc file) where the new files live. Usually while installing via npm, the files often get buried deep inside a folder like /opt/homebrew/lib/node_modules/. And the terminal doesn’t know where to find the file. So this is something I needed to add.

The Fix: Telling the Computer where to look

The “aha!” moment came when I manually added an alias to my ~/.zshrc file. By telling the terminal exactly which file to trigger when I type claude, I bypassed the broken “plumbing” entirely. Again, this was by using prompts on gemini / chatGPT on my browser because Claude has a finite list of tokens, I didn’t want to use them up just trouble shooting. But after it is set up, it looks something like the below:

Now that Claude was set up, I ran some quick prompts on it - like “Hey create a webpage that shows the time and weather”, just to get a feel for how the tool works. Pretty straightforward. A simple prompt and its able to use free APIs to spin something up that you can run locally.

So that is learning #1 for you folks that want to start using a codex or a claude code to start working. It can take a bit to set this up. Don’t be disheartened - just keep doing what you’re doing (if what you’re doing is copying and pasting the prompt into different LLMs and figuring out what is next).

Phase 2: Building a live project and deploying to github

To really get a feel for things, and like I’ve said before, I believe you only really learn by doing, I decided to build something that had a few more moving pieces, and deploy it on a public link, which I can share around with friends and family and get feedback. For deployment, since I have deployed past projects on Github, I figured that for simpler projects and static HTML files, I could just use Github pages. Pretty straightforward. I built a Crypto Price Tracker & Arbitrage Detector (Static HTML). This was fairly straightforward.

1. I built it as a single HTML file: so there was no issue with the backend, and I could rest it pretty easily locally, and it runs entirely in the browser. For those of you who have read my previous articles, you know the issues I have had with “the backend.”

2. The features were simple enough. I wanted it to tracks Bitcoin, Ethereum, and Solana prices, as well as some US pegged stablecoins, and then calculate the potential for stablecoin arbitrage across 20 currencies

3. I wanted up to date information, so I added an auto-refreshment feature every 30 seconds via CoinGecko API (free)

You can check it out at the live link here.

I used this project PURELY as a way to get a feel for Claude Code, and understand where and how to optimize the workflow

I pretty much ran out of tokens fairly quickly on this one, because I kept tweaking, and changing things. I wanted the design to be changed, I wanted there to be less load time, and going back and forth took time. Clearly not very efficient, and for me personally, when working with tools, there is a certain way I like to operate: For example: I’m particular - I want structured planning, limited and defined sources, and full visibility into execution. So instead of re-explaining myself every session, I created my Claude MD file

For those of you who’ve been on Linkedin, Claude MD and Claude skills is all that everyone has been talking about. That is because, in a way, how clear and concise your Claude MD and Claude skills files are, is also how efficient your workflow is. It is a
KEY part of the planning - and in a world where execution is getting faster and faster, and tokens, and the energy it takes to generate said output are finite resources, clarity of thought is key.

Phase 3: Setting up my Claude MD and Claude Skills files

The CLAUDE.md - Your “Operating Manual” for the AI

CLAUDE.md is a file Claude Code reads at the start of every session. I wrote the first iteration of mine as a full operating manual, and I wrote it from the perspective of someone who would use this for research, building small prototypes, but at the same time, also has finite tokens that she doesn’t want to use up.

1. Project locations - where every project lives (~/Desktop/claude-projects/), and where my specific PRDs and documents are, along with assets that I want to use (this could be figmas, images and so on). As this evolves, this can also have a roadmap section, where it can check and iterate against the roadmap files and what the definition of done is.

2. SOP: Detailed plan before executing, always. Draft plan, with detailed specifics → bump it up to me for user reviews → I will either give suggestions to the plan, ask for more clarity, or then proceed with implementation → Claude implements. No exceptions.

3. Testing rules: Agents for testing, reviewing, and deployment

4. Deployment rules - Python apps go to Streamlit Cloud, static HTML goes to GitHub Pages

5. Token optimization: Since I’m on Claude Pro, I do have to look at resource scarcity, so I elaborated on token optimization: writing files complete in one shot, modular (<300 lines each), cap research at 10% of tokens.

6. Project documentation: every project must have a project_summary.txt with 9 mandatory sections (concept, tech stack, database, data sources, APIs & costs, refresh schedule, deployment, use cases, next steps). This was key for me - I need to be able to go back and explain and understand why and what I built

This took iteration. It wasn’t a one-shot write. I refined it across sessions as I noticed Claude doing things I didn’t want, skipping plans, over-engineering, wasting tokens on research. After I iterated on the crypto tracker project, I build out my Claude MD files, and then to make it better, I did one research based project (for personal use) to iterate, and figure out where else I could optimize my workflow

For those of you who follow this newsletter, one theme that I do follow closely is fintech valuations. So I decided to build out a workflow that would help me research this stuff faster.

I called this project the Fintech IPO Tracker (CSV + Research) - clearly my creative juices were flowing. At its core, this project did the following:

1. Historical valuation tracker for 21 fintech companies (2022–present)

2. CSV snapshots by region, quarterly update schedule

I used this to build out specific skills files in my Claude arsenal:

• An IPO skill file, since this is a theme I keep coming to, where I defined how I want this research done, which sources (since there are many sources, I defined specific sources in my skills file), and how to store it, and update it.

• I kept running out of tokens on research, so I installed gemini, and created a ‘research’ skills file. And added that for any research based projects, Claude should prompt me to use Gemini, so that I could prevent my tokens from burning (more on how I did this below).

Here’s an example for what the output looks like each time I run my IPO research skill in my terminal. This format below is basis the asks, data points, list of start-ups to track, the specific sources that should be used for this (since for research based tasks, there is the possibility of the agent picking up a lot of trash), and other points I’ve mentioned in my Skills files. It did take a few iterations to get here, and it is something I continue to iterate on.

Both Claude MD and the skills are like directions for Claude. But there is a difference: Claude MD is a set up for universal rules that apply to every session, while skills are more like ‘domain experts’

• Example - In my Claude MD, I have clearly called out deployment, planning, project location etc

• In Skills, it’s only if a specific task is picked up. Example, ONLY if I want IPO research, will it look at the skills file, and see how I want this data presented, and which sources to go off. Example above: Only if I ask for IPO research will it trigger the skill file, and give me an output like the above

Phase 4: Optimizing my tokens through Gemini CLI within Claude to optimize tokens

I installed the Gemini CLI (gemini --model gemini-2.5-flash) to offload research tasks from Claude. The logic: Claude tokens are expensive; Gemini’s flash model is free. So my research.md skill forces the agent to ask which model to use. before every research task. Research runs through Gemini, code and implementation stays on Claude. Honestly, this was a game changer, and really enables me to optimize my workflow on the $20 subscription I’m on currently. This was fairly easy to do - again, just get Gemini / Claude to prompt you. The steps are fairly simple.

The Gemini CLI Setup

1. https://aistudio.google.com/api-keys: You go to this link and set up a Gemini API key. Just use the free tier - that is what I did.

2. MCP setup: I then added the same API key to Claude Code as an MCP server claude mcp add nano-banana-pro --env GEMINI_API_KEY=AIzaSy... -- npx

3. I then took the Google API key and configured it in two places:

   1. The Gemini CLI config file (for terminal use)

   2. Claude Code MCP (for use within Claude sessions)

The CLI works fine for text/research

Using Gemini / Gamma for UI/UX (Instead of Figma)

Figma requires a paid plan for serious work, and now Anthrophic allows pushing claude code generated UI directly into figma, but $20 a month is as much as I want to spend on AI right now. Instead, I used Gemini’s image generation models (via the API) to generate dashboard mockups and UI concepts. The free tier has limitations (image generation quota hit zero quickly), but the approach works - describe the dashboard you want, get a visual back, iterate. I also used Gamma (AI presentation tool) as a fallback for generating polished dashboard visuals. To be able to use gamma through Claude, just create a free account, and connect Gamma through its MCP server.

As a side project, I also used one of the articles I wrote, plugged it into Claude, and used Gamma to generate a presentation. It’s one I had written a couple of months ago on license aggregation in fintech, and you can check it out here: #79: Do all roads in fintech lead to license aggregation (Part 7). The prompt in the terminal is below:

And gamma usually does a pretty decent job of putting together slides if the context is fairly well set out (which I like to believe it was). You can check out the full Gamma presentation here.

Phase 5: The big project I built was the stock screener, that I deployed on Github and Streamlit (again, recommended by Claude).

1. NSE Stock Screener (Streamlit + Python + SQLite)

1. Full stock screener for ~2,200 NSE-listed equities with 6 months of rolling data

2. 8 screening views: price drops, consolidation, volume buzz, sector rotation, red flags

3. 12 Python modules, each under 300 lines

4. All free APIs - NSE bhavcopies, Yahoo Finance, NSE FII/DII data

5. Deployed on Streamlit Cloud with GitHub integration

6. Local caching for faster loading

7. A submit feedback tab which connected to google forms, and Claude could access, so I could get a daily summary of open tickets with priority and effort

8. Went through 8 commits, from initial build to UX overhaul to adding promoter holdings as another tab to refer to.

This is something that I plan to use to continue to iterate on. It did take some time to build it out (and this is something I added to my Claude MD files. Some examples: Every time I would ask it to refresh data, it would reload ALL the data, so loading time was very long. So then, I had to ask it to cache data to reduce the loading time. I also had several issues with the look and feel, and took some tweaking before I was finally happy with it)

Some things that I built out were a ‘feedback’ tab, which was linked to a google form, stored in a google sheet, which Claude had access to, and could give me a summary of every time I ran the “check tickets” command in my terminal. Example is below:

As someone who works in product, this is a pretty powerful feature for me. Instead of having to consult with multiple tools, and have multiple “stakeholder” discussions, if I am able to connect all my tools and sources of information into one platform, be it Claude, Codex, or something else, that is truly what will enable folks to become that “AI powered PM.”

Phase 6: Setting up my workflows for productivity

After I built these out, I felt pretty confident on using Claude. And so, I turned my attention to how to optimize my daily tasks.

1. Connected it to my gmail, my google drive, and my calendar

2. Used it to get a daily summary of personal work pending, a summary of past emails, and documents that need to be worked on

3. I also use it for a summary of meetings for the day, and any docs / pre-work required for the same so I can prep accordingly

4. I haven’t connected it to my Slack or Whatsapp yet, but I see that is where this is heading for me: having 1 source of data for ALL my tools, and being able to manage and organize my day from here. The platform play is very real.

Where I see this going at an individual level:

1. Give access to data and automate as much of my workflows as possible. I already have my daily email summary and meetings schedule set up as a daily command. Adding my other sources of updates: such as Whatsapp, and Slack to it will give me one place to look. And also, writing out workflows and logic to be able to mark something as P0 / P1 tasks so that it is easier to prioritize tasks at the start of the day is something that will be ongoing.

2. Depending on the function you’re in, setting up commands to get a daily list of open items, previous day summary, and key metrics to track at the start of the day, will definitely help with productivity

3. Experimenting with multi agent workflows: I’m on a budget here, and am obviously being a little careful with it and avoiding burning tokens. But essentially, I’m experimenting with setting up ‘roles’ and have very specific tasks and roles defined for each agent, which in the long term will save costs, and time. This also minimizes agents hallucinating, and broken error loops. This is especially good if you want to build in specific workflows for industries OR even break down tasks for internal reviews and testing, and assign a different agent to each.

An example: To experiment with this, I built out a simple fact checker, but instead of defining a single, sequential workflow, I defined 4 different agents, with different roles, and specific responsibilities.

This is the best way to understand the value of multi-agent workflows over a single agent. I wanted to aggressively fact check any claim I put into the prompt, so I also built it using DuckDuckGo search, and Gemini 2.5 to break the claims into sub-claims and verify, otherwise I’d be out of tokens before you can even say “Claude.” In this case, I broke the fact checking process into 4 different roles.

1. The Researcher: Purely for breaking the claim into sub-claims, and then searching the web and gathering information. In the screenshot below, you can see that the Researcher passed 8 sources of information to The Skeptic - which is the next agent in the workflow

2. The Skeptic: To rigorously verify if the sources are credible or not. And if the sources are not credible, then reject them, and demand the Researcher to find more sources. In the screenshot, to check my claim of “Water boils at 50 degrees”,” The Skeptic rejected 7 sources, and accepted 1

3. The Adversary: This was KEY in the workflow. This agent had to actively argue against the claim, and act as the devil’s advocate. This is key in testing workflows, and even code in my opinion. A single agent isn’t good at arguing with itself. After weighing the pros and the cons, the Adversary would have to hand over the evidence to the final agent - the Judge

4. The Judge - which is the final agent, which weights all the evidence impartially and then takes a decision.

You can check it out here: Painted Stork - Fact Checker. Note: I am using my free tier of Gemini, so there are a limited number of API calls I can make every minute, and in a multi-agent workflow this gets exhausted very quickly.

If you want to build it out for yourself, you can use the below tools. But essentially, by defining roles, and giving each agent access to “micro-context” and a limited set of tools, you can reduce hallucinations at scale. If you give one agent access to multiple tools, and responsibilities, you risk the agent using Tool 1 for Task 2, and so on, or not being rigorous enough in stress testing sources, or workflows.

And that is why there is so much of excitement around a vertical fleet of agents

Multi agent workflows are the logical conclusion for enterprise-scale AI. While a single “smart” agent works could work for simple hobby project (like my Fact Checker, even though I opted for a Multi Agent Workflow), the future of the enterprise belongs to the Vertical Fleet.

We’re talking about specialized agents with micro-context, which are high performance “specialist brains” designed for one single leg of a long task. You’re also able to make these agents adversarial, which is tough to do in a single agent workflow - a single agent isn’t very good at arguing with itself

Why startups will own this and why you can’t just “build it in-house”

A lot of people think, “I can just prompt Claude to do this myself.” For a prototype, that’s true. But the gap between a “cool demo” and a “production fleet” is where the next generation of billion dollar startups will be built.

• The proprietary “Context Moat” aka the Subject Matter Experts: For the same reason that you probably won’t immediately start trusting a Gemini for legal advice, and you’ll probably hire a legal firm that uses Harvey. You want expertise in the area - workflows knowing what and where to look for things, and where you’re most exposed. Startups won’t just sell you an LLM wrapper; they’ll sell you a pre-tuned fleet that already knows the “laws” of a specific industry (ex: healthcare compliance, or a highly regulated fintech onboarding / KYC flow. They’ve done the thousands of hours of prompt-tuning and “hand off” logic, and even source checking, flow optimization logics that you don’t have time to do in house.

• Infrastructure over Intelligence: Building a fleet requires more than just code. It requires specialized infrastructure for Agent Observability (knowing exactly where a handoff failed) and Automated Governance - tight rules and guardrails about what an agent can and cannot do. Startups are building not just the workflows, but also the operating system for these agents, which is far more complex than a simple script.

Example: If it is a complex task, the agent, in order to complete that task may simply ‘skip some steps’ or based on the first few sources it finds, formulate a hypothesis, which may be contrary to what actually is the case. In some cases, if the guardrails are not set up, it may burn up millions of tokens trying to achieve a task. If edge cases are not thought through, it may get access to customer personal information - a clear violation of data privacy acts.

If the task is too complex, it may even get confused, and contradict itself. And if it has access to multiple tools, it may start randomly start using the wrong tool to solve the wrong problem. That is the point of a multi agent workflow. While this can take more time to set up, this essentially breaks down the roles into smaller pieces with ‘mini-context,’ and give it ONLY the tools it needs. It also enables serious cost savings: you can use the more expensive ‘higher IQ’ model for actual reasoning work, and lower IQ model for simple web scraping tasks, collating information and so on.

What actually works in Claude Code today

What worked well:

1. With these tools, prototyping is the EASIEST thing in the world to do. Building full apps from scratch in a single session and the stock screener went from zero to deployed in one sitting

2. The CLAUDE.md system is genuinely powerful - once tuned, Claude follows your workflow consistently. And skills as reusable playbooks save massive time on recurring tasks.

3. Direct GitHub integration means no context-switching for version control - being able to directly update, and rewrite files, and push context from claude avoids switching tools and is genuinely powerful. Bringing in more tools into this interface through /mcp really does feel like a game changer

4. Being able to run other LLMs in Claude is great for cost optimizations - it really allows me to optimize workflows and increases the stickiness factor. I don’t switch just because my Claude tokens are over, I can continue with other tasks that can be completed using a free / cheaper model

Learnings:

1. Writing a good CLAUDE.md and skills takes real iteration - you discover what to add by watching it do things wrong. I’d suggest, if you’re new to it, build a couple of projects, and constantly iterate.

2. Token management is real - you have to be deliberate about what you spend tokens on, unless of course, you’re willing to pay the $200 per month on Claude Max. This is where being able to run free LLM models in the Claude interface came in

3. You need to understand your own workflow before you can teach it to an AI - this tool rewards people who already think in systems. Don’t just blindly copy Claude MD or skills files that people are randomly sharing on the internet. Take the time to understand what YOU need, and then basis that connect to different tools. The opportunity to personalize is immense, and now is the time to really tap into this.

The LLM layer is moving fast and absorbing middle layers

My earlier hypothesis on Part 2 of my “zero to live” series was twofold. One - that some of these platforms are moving really fast, and absorbing middle layers, such as UI generation and so on. Which makes me question what way platforms such as Lovable etc are going. I tested them out a bunch of times, and I still see them as prototyping tools - I would not trust this code in full production, I’d instead use a Claude Code or a Codex which can write code, actively test and retest, and then directly push to Git. And as a Product person, I’ll still use this for prototyping, but I very much preferred this to a Lovable experience.

But only time will tell how this evolves. But, the 1 terminal or interface, within which you can talk to and run multiple tools is where the momentum seems to be shifting.

The second point: Everything that I have done here, is at a personal level. These workflows are not tough to build, it requires you to spend some money, and have patience, but that is it

Prototyping is no longer the flex people think it is. In 2026, if you have a Claude / Codex license and a pulse, you can build a V1. Prototyping has become a commodity. The bottleneck isn’t creation really. We’ve spent three years obsessing over “AI native” individuals. We celebrate the person who can use Cursor or Claude to spin up a workflow in an afternoon, or use the computational ability of a LLM to bring down time taken to do tasks from lets say days, to within a few hours. While that is fantastic, the bigger unlock is still pending

From an organizational perspective, if you look at where an organization’s time actually goes, it’s not in the “Aha!” moment of an idea. It’s in the mundane, low level friction of existence:

• The cross-functional review and sign-off - different teams have different inputs that need to be incorporated

• The security review - compliance, legal and infosec have recommendations

• Extracting data from the legacy CRM or finding the right email is an incredibly manual process - which requires a lot of search, downloading of CSV, uploading and then running excel formulae.

• Multiple sources of data that don’t speak to each other: Requires extremely manual workarounds, and just cleaning up and mapping the data to a single identifier on which analysis can be done can be a messy and time consuming task. And then, bringing all that information together and then making complex permutations of data manually.

• General KT and handovers: Bringing a human (or an agent) up to speed on three years of messy documentation.

• Edge cases that constantly require manual intervention, and a panel to be convened to make the decision on that edge case: Using humans to handle every edge case instead of building review only systems.

My point being: The onus is no longer on the individual to “adopt” AI. Everyone already has. The onus is now on the organization to enable it, to actually get rid of the aforementioned blockers in the above workflows. For this, every organization needs to set up the following:

• The Model Context Protocol (MCP): Bringing all tools (Gmail, Slack, Jira, Codebases) into a single, secure server that any authorized agent can pull from.

• Guardrails: Role based access - just because someone CAN access a tool, doesn’t mean they should

• Organization based API access: Today, connecting my tools to a Claude workspace requires me to set up individual API keys. We need to move past “Individual API Keys” to a centralized, governed gateway where data actually flows securely.

• Automated Governance: Turning “Cross functional sign offs” from a two-week email chain into a 60 second agentic audit.

The win isn’t building the tool. The win is enabling the stack. If your organization isn’t building the scaffolding to let these prototypes live in the real world, you aren’t an AI native company. You’re just a company with a few people who are good at demos. Stop panicking about whether your employees are “using AI.” They are. Start panicking about whether your organization is enabling them. The next 2-4 years will be defined by the Organizational AI Stack.

The Organization AI Stack

1. Everything starts from the data layer:

You cannot build a “Digital Employee” on a garbage foundation. An Org-Level Stack starts with:

• Human-Readable Schemas: If an AI agent has to guess what COL_PRD_V2_FINAL means, it will fail. We need clean databases with clear row/column naming.

• Universal Identifiers: Data sanity across silos. One clear ID for a customer, one sanitized name for a product event. If the data is “dirty,” the agent’s logic will break

2. Connectivity: APIs and MCP

It is a profound waste of time for every employee to “figure out” how to connect Claude to their Gmail or Codebase. I know it was for me, even using it in my personal tools. The organization must provide:

• Pre-built MCP (Model Context Protocol) servers and llms.txt maps that give agents instant, secure access to company tools. A centralized library of internal servers that allow Claude or other agents to securely read your Jira, edit your GitHub, or check your AWS spend in one click.

• The Death of Manual Processes: If a workflow requires a human to “Download a CSV, upload to Drive, then analyze,” that is an organizational failure. The stack should allow an agent to call an API and bridge that gap autonomously. I want to be able to pull the data directly in my workspace and be able to talk to it. That requires the data layer to be top notch.

3. The Orchestration Layer (the skills and MD files, as well as multi agent logic for agentic workflows)

The org doesn’t just run prompts; it runs Agentic Workflows.

• Agentic Guardrails: A central server (like Maxim or Bifrost, which handle routing of requests to LLMs basis downtime, and monitor performance, hallucinations, and data leaks) that intercepts every AI call to check for PII leaks, budget limits, and “hallucination scores” before the user sees it.

• Organization “Skill” Library: The organization maintains a version controlled repository of Claude Skills (SKILL.md files) that define exactly how the company wants specific tasks done (ex: “How to write a PRD,” or “How to automate QA Testing.” ). While I spent time doing this for myself personally, an organization will have certain processes / templates that it will want to follow

• Human in the Loop (HITL) Triggers: Workflows that automatically “pause” and ping a human on Slack when an agent hits a confidence score below 80% or a high financial risk threshold. And defining what that confidence score looks like

4. The Governance & Permissioning Layer

We need to treat Agent identity as seriously as Human Identity, so that we can track what agent did what where.

• Agent Service Accounts: There needs to be a way to track what is happening, and by which agent. You can audit exactly what “Agent - 042” did in the database at 3:00 AM.

• Task Based Access Control: When and why can agents access information? Example: An agent can read the customer information database ONLY if it is currently assigned to a specific analytics task.

• Claude Compute Credits: If a team’s agents are burning through INR10k in tokens with no ROI, the system automatically flags the agent, and pauses operations until there is sign off.

5. The Leadership: The CXO Championship

This is not a “Tech” problem; it’s a Strategy problem. Building an AI stack require an some sort of AI Architect Role, which is a new breed of employee whose sole job is to map workflows, write granular Claude Skills, and define the “handoffs” between human and machine. It also requires an AI team, whose focus is to make sure everything is set up, from tool migration, to data labelling, to MCP server set up, and then testing, and ensuring as much of the complexity is abstracted away, so that agents can work seamlessly.

There needs to be recognition that this is something that is required for long term survival, and is not something that will contribute to short term revenue or cost optimization. In fact, in the short term, costs will probably increase, due to more tools, and more costs.

But I have reservations: We are at a crossroads with AI adoption right now

In Atlas Shrugged, Ayn Rand’s protagonists (Dagny, John Galt, and Hank Rearden) aren’t just “smart” - they are intimately connected to the details of their craft. They know the exact temperature at which their steel melts, and the tension of every cable on their bridge. It’s not just enough to have the finished result, they also need to know everything that goes into actually making this. In 2026, we are at risk of losing this. When we outsource the search to an agent, we often accidentally outsource the understanding.

I believe that in a lot of thinking based tasks, the answer is the commodity, and the real asset is actually in the search for the answer

If you ask an AI for the “Answer,” you get a static fact. It’s like being handed a fish (the “give a man a fish analogy comes in here”). But if you take a tough question and pursue it yourself: You encounter adjacent information that the AI would have filtered out as “irrelevant.” It helps you build intuition, - you understand why the answer is what it is, which allows you to pivot when the context changes. It also helps you develop a ‘gut feel’. An AI can give you a “Truth Score,” but it cannot give you the “gut feeling” that comes from seeing a pattern across six conflicting research reports. For me personally, the greatest learning that happens is when I create a hypothesis, and chase down research reports, and read them end to end, to not just understand if my hypothesis was proven or disproven, but to also understand WHY, versus using an AI for a summary. Note: I’m not saying that we shouldn’t use AI for research, but we should be very clear in the role that AI is playing for us

If we’re outsourcing our thinking, and our opinions, then what is the point of anything?

For those of us that grew up in the pre AI era, and even in the pre-commoditization of the laptop and smartphone era, a lot of our research was basis what we read, the public newspapers, and really searching for those credible sources and forming an opinion. And in the process of DOING that is where learning, and growth and discovery happened! If an organization becomes “too efficient” at using AI to synthesize reports, it is possible that it eventually loses the ability to critically audit those reports. You end up with a team of people who are “Managers of Managers,” but no one knows how to fix the machine when it breaks - which is exactly the problem that Atlas Shrugged addresses in its core plot points.

One of my favourite quotes, which I feel becomes more and more relevant as we move into the age of AI is:

“It’s the questions we can’t answer that teach us the most. They teach us how to think. If you give a man an answer, all he gains is a little fact. But give him a question and he’ll look for his own answers.” - Patrick Rothfuss (The Wise Man’s Fear)

The other question I have is: do we really understand the potential socio-economic dangers of this technology?

We don’t have to look too far to understand what can happen if this goes wrong. One of my favourite shows: Person Of Interest, is built on this exact premise. A billionaire has developed a computer program for the federal government known as "the Machine" that is capable of collating all sources of information to predict terrorist and to identify people planning them. But it develops a mind and motivations of its own, and faction of super powerful people (probably billionaires) want to use it for their own ends.

Karen Hao, the author of “The Empire of AI”, draws parallels between The Dune series and our current AI predicament during her appearance on Hasan Minhaj’s podcast, “Hasan doesn’t know” (a deeply revealing interview on how AI is being developed and deployed). I’d like to expand her Dune analogy out a little bit more. The Dune series is set in a universe, where there was a ban on thinking machines roughly 10,000 years before the book started. This was also called the Butlerian Jihad, but essentially an AI took over planets, that used humans as servants / cattle. After humans overthrew the “thinking machines” there was a ban on all such machines, and the commandment was set up “thou shalt not make a machine in the likeness of the human mind.” (Also mind you. Dune was written in 1965 - so for Frank Herbert to imagine a universe back then, where you had supercomputers, AI, world takeover, and then a BAN on AI is pretty phenomenal stuff by way of creativity, seeing that this was about 60 years away).

The Dune novel series is set in a universe where these thinking machines are BANNED - due to cognitive atrophy, and increased power imbalance.

But the point is: there are two things that the Dune series argues. 1) That depending on machines made humans domesticated and “soft.” And 2) The books also talk about that it wasn't just the AI itself that was the problem, but the power imbalance it created. A few people who controlled the most powerful machines were able to enslave the rest of humanity. The Jihad was a movement to reclaim human autonomy from those who used AI as a tool for tyranny. Sounds familiar?

There’s a more articulate way the below interview has put it. Take a look. It is only about 10 minutes.

Here’s the thing. Does AI make my life easier? Yes it does. Does it enable me to get smarter, and do more things? For sure. There is also genuine potential for improving the world: An example: AlphaFold is powered by Google’s DeepMind. It essentially is able to predict a protein's 3D structure from its amino acid sequence with high accuracy, and it enables researchers to understand protein functions, speed up drug discovery, and advance biological research.

Now, I don’t claim to understand all of the above. But there is value that these supercharged computational LLMs bring in actual medical and research breakthroughs: things like curing cancer, understanding our history and who we are through genomic sequencing, and genuinely making the world a better place for the next generation.

But we need to also understand the impact of this on the human race and the environment

There is genuine fear among folks about AI taking away their jobs. Like the interview that Sam Altman gave, where he compared AI agents to humans, if that is the perspective that you look at AI with, then jobs, and people’s livelihood are in danger. This is over and above the concerns I have, about this having the potential to actually make people dumber.

The second is, that this will increase the divide between the more and the less privileged. AI tools are expensive. It costs me INR 2k a month, JUST for Claude Pro. Claude Max can go upto $200 a month. Add to it other tools that you want to use: Figma, Gamma, API calls for OpenAI / Gemini and so on. Who’s paying for all this? Organizations sure. But folks who want to learn these tools? Who’s going to fund them?

There is also an impact of building data centres - it requires enormous natural resources - land, water, and energy. I remember reading that data centres can consume upto 5 million gallons of water a day for cooling. An article described a data centre as a large whirlpool, sucking out everything from nearby regions, impacting water quality, and electricity. Check out this video interview here, where a couple living 400 meters away from a Meta data centre in Georgia, USA shows the disruption that this has had on their daily lives.

So who and what are we building all this for? To maximize shareholder value? Or for actual individuals?

It is the in the interest of the people in power to promote the idea that AI will take away jobs. As Sam Altman says: Humans take 20 years of life, and all the food you eat before you get smart. The implication being: AI agents are way cheaper. It’ll increase profit margins, and give even more power to the people who already have it

There are benefits of this technology. I’m not saying there are not. We see that with Alphafold.

But at what cost? Increasing the rich - poor divide? Replacing humans with agents, without a plan for employment for those folks out of jobs, which could lead to more poverty and homelessness? Reports suggest that by 2030, as many as 12–14% of workers may need to transition into entirely new occupations. There is no serious plan for how that happens. Which could lead to more poverty, more homelessness, and a widening of the rich-poor divide that’s already at a breaking point. The UN isn’t mincing words either - they’ve warned that AI’s economic gains remain “highly concentrated,” with the benefits favouring capital over labour and reducing the competitive advantage of low-cost labour in developing economies.

And these massive data centres that power these models? OpenAI has partnered with Tata to build 100MW of AI data centre capacity in India, with plans to scale to 1 gigawatt. A S&P Global study projects that 60-80% of India’s data centres will face high water stress this decade, with consumption expected to more than double - from 150 billion litres in 2025 to 358 billion litres by 2030. Altman, while in India, called concerns about water usage “totally fake.” The data says otherwise.

After seeing the UN’s inability to intervene meaningfully in Russia-Ukraine, the global trade agreements the US seems unbothered about breaking, and the complete failure of international bodies in Gaza, I have very little faith in any global governance structure to actually get anything done. These bodies exist for the sake of existing, and nothing more.

But unless we can get a clear answer, at a global level to the question of who we are solving for through this technology: is it the billionaires, the select few? Is it organisations? Or is it actual individuals?

If it is anything but individuals, we are right to be concerned.

But the point is, Credit Lines on UPI, as a concept, have been around in the market since 2023. It’s been more than 3 years. And when it initially came out, no one was really sure what to do with it. Or even, what it was. Was it a new payment method? A new payment rail? Who was it even for? This is something Manan (Product & Strategy @ Vegapay) and myself have been discussing for quite a while - not the pronounciation (although that is also important), but what’s the potential?

Well, CLOU was promoted as being the messiah for small ticket lending in India. It aimed to bring together the best of both ‘affordability’ and ‘customer experience’ albeit in a kosher way that all regulated entities were comfortable with. But to understand this, let’s go back to the past.

How small ticket lending originally worked: This is the original LSP and lender aggregator model, and the problems

Well, the original LSPs (or lending service providers) were the Zestmoney’s of the world. They really put small ticket lending on the map, and were a key reason for the DLG (Digital Lending Guidelines) that came in. These players had the right idea - and essentially introduced the idea of ‘checkout affordability,’ which brought together the supply of credit, and the customer demand, at a specific point in time. Unsecured lending went up, with Zestmoney doing INR 300 - 400 Cr per month, Axio doing (I would hazard a guess, that there were similar volumes), Shopse doing probably half that in their offline model. While the demand, and the supply was there, what wasn’t there was a robust business model.

Credit goes to these players (excuse the pun): They highlighted the need for a model like this, and did whatever innovation they needed to make this work. (A key one being FLDG)

The concept of FLDG helped boost approval rates, but placed huge risk on the system

These lenders were able to boost approval rates with a concept called FLDG. FLDG is “First Loss Default Guarantee” where the fintech would commit to covering xx% of the lenders losses. To give you an example:

Let us say, lender A has disbursed 10 Cr through Fintech X. Fintech X has agreed to give a FLDG of upto 10%. This means that Fintech X will cover ALL losses of lender A, upto 10% of disbursal, which in this case is 1 Cr. (there is some negotiation here, it can be total disbursal, principal outstanding etc). So, in the case that Lender A loses INR 90L, fintech X will cover this entire amount. If lender A loses 5 Cr, Fintech X will still only cover 1 Cr and no more.

Problem #1: Approval rates were boosted because of the FLDG concept. Lenders knew that upto xx % of losses would be covered, so they didn’t do the due diligence that they should on some of these customers

When this model originally started, FLDG was as high as 100% of the disbursed amount! And then gradually this reduced to about 10-20%, but the amounts were still extremely high. That is one reason DLG came in, RBI got extremely cagey with a ‘non regulated’ entity taking so much of risk. And if these risks blew up, and the fintech was unable to pay, it could cause a collapse of certain financial institutions!

Note: Although DLG mandates FLDG to be ~ 5%, there are a lot of ways to get around this, you can put an ‘equivalent’ deposit in the bank the size of the credit supply you want, or even have a lien on a FD, in the name of the lender giving the supply of credit.

Problem #2. Lack of lender liability: there weren’t any guidelines around this, so a lot of lenders offloaded KYC and customer verification onto the fintech itself

The customer here would be a customer of the fintech. The fintech would onboard the customer, do the KYC, and match the profile of the customer to the lender policy. All the lender had to do was accept the customer profile, accept the documents that the fintech had collected and verified, and just disburse. The customer wouldn’t even know who the lender was unless they bothered to check their email, and that too, the email they would get would be from the fintech, specifying the details of the loan. Naturally for most customers, they probably didn’t read it in detail, assuming that all was well.

Problem #3: Not being able to get to the right TG:

There were two types of customers that these fintechs pulled.

Customer type #1: Low risk customers, who had options to take other credit products, and probably had 1-2 credit cards. And they weren’t willing to pay any interest or extra fees. So the ‘3 month no cost EMI’ was set up for customers like these. And someone had to bear the cost of the interest on the loan. This would end up being either the fintech itself (under marketing expenses, and especially if the merchant had a lot of leverage - like Amazon), or in some cases the merchant would bear the cost. (the concept of subvention). So here, there were high marketing expenses

Customer type #2: This customer type wanted the credit. They needed that affordability. But these was also the desperate customer, and NPAs and collection costs were higher

There were customers in the middle - that were probably customers who didn’t have as much access to credit as they’d like, but at the same time, were not at risk of default. But in this model, identifying them was difficult, since every customer was a NTB (or new to bank customer), and the lending was mostly happening via NBFCs.

Problem #4: transparency in general: these small ticket loans were given by an entity under the term ‘credit lines’ when they were essentially small ticket loans

You had a player like Fintech X telling the customer that they were eligible for a credit line of INR 1,00,000. But this wasn’t actually a credit line. Every time the customer transacted, there would be a small ticket loan that was taken. Example:

• The customer was told that they got a INR 1,00,000 credit line from the fintech. Actually this was just the total drawdown amount. The customer would then transact at various places using this, and instead of being reported as a usage against that limit, it was reported as an individual loan! Example:

  • Electronics: INR 10,000: actually reported as a 10k loan to the bureau

  • Clothes: INR 5000: reported as a 5k loan to the bureau

And customers were never aware of this! In their minds, Fintech X gave them the credit line, and they were using it like they would a credit card. They didn’t know that Fintech X was just the aggregator, and in the backend, it was a Piramal, or a ABFL giving the loan. And that in reality these were small ticket loans, and if you take multiple small ticket loans like this, it’s going to really damage your credit score. Which is what happened: customers found their credit scores affected, and severely hurt them when they tried to apply for auto / home loans on other platforms.

There were a bunch of players operating here, some are still operating while some got acquired / pivoted their business model

1. Lazypay: in-house lending arm of PayU, powered by PayU Finance, an NBFC. Operations slowed down a bit in 2021 - 2022 after the crackdown on unsecured lending. In FY25, PayU got investment from its parent entity, Prosus to boost its credit offering

2. ZestMoney: Was doing INR 300 - 400 Cr per month. NPAs boomed, marketing expenses went through the roof (3 month, no cost EMI), ended up being sold in a fire sale to DMI Finance in 2024. Zestmoney had an in-house NBFC.

3. Axio: Again, was doing 200 - 400 Cr per month, majorly through Amazon. Was wholly acquired by Amazon in 2025. Axio also had a in-house NBFC.

4. Slice: Tied up with banks (SBM) to use their PPI license to issue cards linked to a PPI wallet, which were infused with small ticket loans from the partner bank. Essentially it was a small ticket loan pretending to be a revolving credit line. DLG came in, and shut down this model, and Slice merged with NE SFB in 2023 to become a small finance bank. My bet? RBI provides a way for SFBs to become universal banks after 5 years of operations, and among other things, the bank also has to be public. I expect an IPO soon. I had written a piece on SFBs, that you can check out here: [#78] Banking in India: FDI investment, bank consolidation, and the “great re-bundling”

The point being, that due to regulatory uncertainty, a lack of systems being set up to actually support this (credit bureau, loan vs line, targeting the right customer base), in hindsight (which is 20/20) this was always going to see roadblocks

1. Fintechs with no regulation, and lack of capital adequacy to adhere to were giving massive guarantees in case of failure! If some sort of massive default happened for a fintech with very high FLDG, and it was actually required to pay it up to the lender, it quite probably would not be able to, and cause a collapse

2. Not able to target the right customer: Going after the credit worthy customer required huge expenses to subvent the interest. Going after the risky customer required funds to manage NPAs. And fintechs seemed to be unable to actually isolate the ‘right’ customer for this product - the customer with a bank account, and not enough access to credit.

3. Not able to find a balance between affordability and customer experience: The onboarding flow to actually get this was very long and convoluted. Only the customer who REALLY wanted the credit would go after this. It was not seamless enough to attract the customer who maybe had another option. The affordability AND good customer experience was not being met, players were either solving for affordability (Zestmoney, Axio), or for experience (Slice, Jupiter, and 1-click players such as Lazypay, Simpl etc, although I would argue it wasn’t really a credit product, it was a 1-click payment product that was being powered by credit)

4. Ecosystem wasn’t set up for these sorts of credit products: All these innovations in credit, required systems that were flexible enough to understand. Things like ‘partial cancellation,’ (imagine you buy 2 t-shirts, return 1), or grace period (3 days no interest in case the customer forgot) were things that existing bank systems find tough to understand, requiring a lot of manual recon. And of course, whole issue of credit bureaus treating each transaction as a separate small ticket loan, instead of credits and debits against a line really ended up screwing the credit score of a lot of customers

What we do owe thanks for to these OG players, is that they brought to light a market that clearly existed - what was needed was to figure out the right model that could serve it sustainably

• Demand: atleast 1000 Cr per month (if I combine all online / offline small ticket lending sources) ✅

• Product Opportunity: Being able to provide “affordability” options, with a good customer experience ✅

• Distribution: Already existed via consumer apps, checkout pages, and POS terminals offline, where the supply of credit could be connected to the customer at the time when they needed it ✅

CLOU (clue? clow?) solves not just for the affordability + CX piece, but also the regulations of it all

I’d say that Credit Lines on UPI is an outcome of all the original innovation that the OG lending fintechs did. And it solves for most of the problems that exist.

1. It solves for ‘experience’ because it is a product that is marketed towards the ETB (Existing to Bank base). Let’s break down the bank customer base shall we? In any bank, 10 - 20% of the creme de la creme customers are the ones that get a credit card. There are still ~80-90% of customers who have a bank account, and probably half of this who are credit worthy. So the whole “additional effort” and the ‘friction’ that exists in user onboarding journeys for NTB (new to bank) customers goes away, since this already a customer known to the bank. I equate this to a flow that is similar to a customer using their mobile number to avail of offers, here I assume there would be a PAN entry step as well.

2. It solves for affordability, credit lines start at INR 10k, but I’m assuming the sweet spot would be INR ~30 - 50k (and these can be revolving / non revolving).

3. It de-risks the bank since this is a customer already known to them. Through other features on UPI such as Autopay, the user can also set up repayment, which helps reduce collections cost for the bank, AND makes them amenable to take lower exposure on a higher number of customers. I’ll give an example: banks (and even NBFCs) don’t really like small ticket lending that much. Because the cost of NPAs and collections is usually not worth it, and at an absolute amount, higher than the revenue they’re probably making from a INR 5000 loan. Now, if there is a seamless way to set up collections, then this cost reduces, and probably makes the economics look a lot better

4. Distribution is solved, which increases usage, and revenue TAM: 400M individuals are anyway on UPI. This is a method on UPI rails. So it’s not an additional headache, like it is in current lending flows, the process of using this to pay is fairly seamless, and it is familiar, unlike currently flows across lenders which are fragmented

5. Monetization seems to be there: The reason why earlier lending fintechs went bust (apart from general operations in the ‘grey’ area of regulations), was also because monetization was tough. Lenders would make money through the interest, merchants would benefit from the increased frequency and average order value (10-15%) due to a credit method being enabled, and the lending fintech would make money through processing fees (and that also would be lost by the time you account for marketing / subvention expenses). 1.2% MDR is mandated on interest free lines.

A common question I hear is: Isn’t this the same as a credit card? What is it actually solving for?

Well, yes and no. Is a credit card a credit line? Sure. But banks see a credit card product in a very specific way. A ‘Credit Card’ product is defined. It’s been around for a while. It has defined systems, and defined policies. Banks mandate that a credit card can ONLY be treated in a certain way, and only CERTAIN customers are actually eligible for this. An example:

1. A credit card is not a very flexible product. It provides a revolving credit, with some % if you don’t pay on time.

2. There is a minimum payment, or complete payment option available at the end of every month

3. Only the top 10-20 % of the bank customers get the credit card. It also comes with a host of other perks (lounge access, reward points, which by the way are funded by the issuer bank only, so there is vested interest in giving these perks to the top customers who probably don’t use all of them)

4. It’s built with a premium customer in mind, it’s not seen as ‘entry level’ credit.

At its core, that is not at all what Credit Lines on UPI are solving for, and there-in lies the difference

In a nutshell, Credit line on UPI, or a CLOU, is a revolving or a non revolving credit line. It is a ‘small ticket credit limit, that allows banks to take less exposure on thin file, or riskier customers, but still on customers that they know.

It is primarily aimed at the customer who needs this credit, and not necessarily a premium customer. Think of it as a construct that allows credit to be given in an incredibly flexible fashion. Example: You want a 1 week, no interest limit? Sure, we can give that via CLOU. How about 2 months, @ 10% interest? That is possible too. And, unlike the core UPI method, which is 0 cost, this is a way of getting UPI stakeholders to actually make money. There are 2 models:

1. Interest free lines: These have 1.2% MDR

2. Interest bearing lines: These have zero MDR

Just looking at the type of investment, and the stakes that existing fintechs have on UPI, I’d actually expect them (once CLOU scales) to invest heavily here, as it allows them to attribute some of that revenue to the core UPI, which is currently a cost centre, not a revenue generating asset.

There’s also another angle: Credit Cards are inherently a more expensive method for the bank

Credit cards have a gross interchange of ~2.1%. After accounting for network fees, BIN fees, technology costs, and blended merchant categories, the net interchange in a bank’s P&L is ~1.2%. CLOU has a gross interchange of ~1.2%. After adjusting for network costs, lower interchange merchants, and zero-MDR categories, the net interchange is ~0.85%. While this appears lower on the surface, CLOU removes several structural cost layers that exist in cards:

• No BIN ownership costs

• No plastic manufacturing or delivery

• No card lifecycle management in core systems

• No re-issuance or replacement costs

• No POS-linked reward or lounge infrastructure

• As a result, the effective unit economics per active user are comparable to, and in some cases better than, cards, despite lower headline interchange, because there are fewer costs, easier distribution, and easier usage.

Distribution and activation further strengthen the case. CLOU is embedded within high-frequency UPI flows, leading to:

• Lower customer acquisition cost

• Faster activation compared to cards

• Higher transaction density, even with lower initial limits

CLOU are also more capital efficient than term loans

Capital efficiency is essentially how much lending exposure can a lender take for each unit of regulatory capital it must hold. In simpler terms, If Product A and B both are required by RBI to hold INR 100 as a capital buffer (almost to protect against losses in case the customer defaults), and Product A generates INR 10 as profit, and Product B generates INR 50 as profit, then Product B is more capital efficient.

Capital recognition: When and how much of a credit exposure gets counted toward risk weight assets, which determines how much regulatory capital the lender must hold. Credit Cards are super efficient here, since the lender holds capital of the ‘drawn limit’ and a % of the ‘undrawn limit.’ Example: The user’s limit is INR 100. The user has utilized INR 60. Capital is held against this INR 60, and some % is held on the balance INR 40, which is usually 20-25% (called CCF or credit conversion factor). Credit Cards are efficient since capital is not held against the whole INR 100. Loans are very inefficient, since capital has to be held against the entire disbursed amount. Revolving credit lines are closer to credit cards, while non revolving credit lines are closer to loans with 1 key difference: the capital buffer ideally should be taken against the ‘drawn amount,’ not the total sanctioned amount.

Ranging from most capital efficient to least capital efficient, I’d rate it as:

Credit Cards → Revolving Credit Lines → Non Revolving Credit Lines → BNPL / Checkout EMI → Personal Loans

Okay, sounds good in theory. But what is the actual scale and ecosystem readiness for CLOU? It has been around since 2023

Lets take a step back to answer that. What is needed for CLOU to scale, firstly?

1. Systems that support a flexible credit construct: The likes of Vegapay, Credit+ allow banks to actually handle new and flexible types of credit products. I’d say this is in the market. In fact, Paytm Postpaid via SSFB, BharatPe Pay Later with YBL, and Navi have all been launched via Vegapay

2. Bank buy-in: Banks have to buy into the concept of a credit line, and understand that this isn’t a product that will cannabilize their existing credit card base, but rather, enable them to give credit to the base of customers that currently do not get it. My view? This will probably take a bit of time, since banks aren’t really the suppliers that are giving small ticket loans, those are NBFCs. Which brings me to my next point

3. NBFC enablement for Credit on UPI: What is the current product that this competes again? Small ticket lending. Who powers that? NBFCs! So by opening this to just banks, you’re not really solving any problem per se, banks were never REALLY looking at going after this segment with hammer and tongs. It’s the NBFC enablement, which wants to do small ticket lending, which will solve for this

4. Distribution via UPI Apps, and merchant networks: UPI Apps are easy. But a big part of small ticket lending also happens via checkout - the erstwhile checkout affordability, which contributed to majority of Zestmoney and Axio volumes, especially on e-commerce. Being able to 1) Get merchants exited about this, via co-branded lines and 2) work with suppliers for a simple activation flow at the time of payment - usually merchants are against this, is another lever. This also helps reduce CAC, and makes this easy to activate and distribute.

5. Usage is easy - it can be used anywhere there is a QR: Theoretically, this is true. Practically though, I will say that this does require merchant buy-in, since this is a method which could possibly have MDR attached to it.

CLOU also solves a long-standing gap in Indian lending: profitable, compliant small-ticket credit. Unlike BNPL, which RBI mandated must follow credit-card-like guidelines if interest-free, CLOU products are structured cleanly as OD, EMI, or card-equivalent products from day one, avoiding post-facto compliance risk. Importantly, CLOU is emerging as a large scale NTB (new to bank) and NTC (new to credit) acquisition engine. Banks are acquiring customers at very low marginal cost while remaining profitable, something that card programs increasingly struggle to achieve.

In terms of scale, it was around ~100 Cr per month in 2024. Some % above this is probably what it is at today

Now, real talk. I’ve spent this whole article talking about how the construct of “credit on UPI” will take off, and how it is the next big thing in credit in India. I think what has a lot of people excited, that just in terms of how this offering is constructed, it can actually solve a lot of existing problems in the current construct of credit products in India.

As a product, it is primarily built to target not the top 20% of customers, which are being served by a Credit Card (Mastercard, Visa, maybe Rupay), but the middle, which don’t have access to a credit card yet, but want some sort of credit account that they can use seamlessly and wherever they spend. Right now, those customers shop using consumer loans, or take personal loans, and then use that for their expenses. THAT is the base that CLOU is targeting. Again, very high level numbers, but the personal loan market in India is INR 11k Cr. And just in terms of fintech lenders (I’m not counting players like Bajaj Finance etc that are present in offline stores), the consumer loan market is INR 1k Cr. These are big numbers that Credit on UPI has the potential to tap into.

So then why hasn’t it taken off yet?

Well, that is a good question. Multiple reasons:

1. Customer education on what a “credit line” is, is still probably not where it needs to be. Customer education → demand → supply will catch up

2. The ‘right’ suppliers of credit aren’t enabled on this. There’s a reason SFBs (Small Finance Banks) have moved on this - they are the challengers. But to truly open this up to the masses, we’ll need it opened to NBFCs

3. Merchant narrative needs to catch up: The actual tech going into enablement is not tough, but the ‘why’ merchants should enable this is something that is still evolving.

4. From a bank perspective, I’d say policy and underwriting haven’t reaaaally caught up to what this product is - it’s not yet another credit product for the premium base, but an entirely new credit construct, allowing banks to serve the 70-80% of its base that doesn’t have a credit card. To do that, risk teams need to start looking at customers differently: types of use cases, (gold, education, travel etc), the rate of activation, and be willing to take lower exposure but across a wider range of customers

An open question I have is on NBFC enablement: how will this work?

Let’s assume that this does open up to NBFCs and NBFCs can then give credit lines. How will this model actually work? It’ll solve for affordability for sure.

1. From an experience perspective, the first credit line will require full KYC. So unlike the bank flow, where the customer is already known to them, there is some friction that is introduced in this journey. But that’s okay. I see that as the first time a user is opening an account with a financial institution - the friction is expected, especially if this is a customer that wants / needs this credit.

2. The second is that the NBFC account will have to be linked to UPI rails, I’m assuming no problem in either, but this is a change in the current construct, which only allows PPI / bank accounts linked to UPI. Again, not a challenge, just something I’m calling out.

This isn’t really a specific product play, but an ecosystem evolution. And so, for this to take off, the ecosystem needs to open up on certain pieces

I’ve broken it down by the following:

1. Does the customer know about this and understand this product? Not to the extent that is needed, but I’d say that with the recent launches of Paytm and BharatPe, we are getting there 🟡

2. Do merchants understand this product, and the value it brings to them: Again, I’d say similar to the previous point. Not to the extent that is needed for this to take off, but something that is evolving. (example: credit increases frequency and average transaction value) 🟡

3. Do the payment players support it at the time of transaction? Example, at online checkout, and offline POS terminals, can customers see this as a way to pay? 🟢

4. Is the right supplier of credit enabled for this? Example: NBFCs are the entities that power small ticket lending in India, not banks. If they are not enabled, then the supply will never truly be there to help scale this 🔴

5. Are systems enabled? Are there credit line management systems? Is the infra ready? Can apps enable this? 🟢

By the looks of this, it seems like the ecosystem infra is ready to take off. What is missing are key levers to enable this, which are customer awareness, the merchant narrative (which are getting there to be fair). The key unlock will be NBFC enablement, and once that takes off, I see customer awareness going up as well.

So that is the first part. The ecosystem is ready. What is needed is some sort of inflection point, that will really be the ‘spark’ that makes this scale.

The second piece that needs to play out is monetization

There are two models.

1. 1.2% MDR on Interest Free lines

2. No MDR on interest bearing lines

I’d done some calculations earlier on what it takes for UPI to pay for itself, and you can check out the details below:

But TLDR: 0.15% MDR on P2M transactions > INR 2k is enough to pay for the ecosystem. So, I’m assuming that 1.2% on Credit Lines on UPI is good enough to make sure that no one is losing money on this. But that is on the interest free lines.

On the interest bearing lines, I’m assuming that this will mirror the current construct of interest bearing EMIs. In the current construct of loans:

1. The lender charges some interest

2. The merchant pays some MDR for this method. This is either paid by them, or its subvented by the fintech facilitating this

3. Sometimes the fintech also charges a processing fee, either to the merchant or the customer for helping facilitate this transaction

But in interest bearing credit lines, there is supposed to be 0 MDR.

So then, there is probably still going to be some processing fee that the fintech facilitating this makes, the lender makes interest, and the folks on the infra side make their money from the cut that the bank / fintech is getting.

I’m harping on about the monetization because at the end of the day, this has to make money for stakeholders to invest in this

We saw that with UPI, that leaving the ‘market’ to figure this out is perhaps not the best way. It’s probably better if there is a defined structure that communicates the value, and monetization potential clearly, for all models, to ensure that this takes off. Market awareness, and the NBFC unlock is what is now needed.

Some things that I’m excited to see play out:

1. NBFC unlock - if this does happen, then the ecosystem will blow up, and this will drive customer AND merchant awareness

2. New credit products that are not bound to traditional 3/6/9 EMIs or 30 day revolving credit. With players such as Vegapay, Hyperface, Falcon and Credit+, I think this really depends on how creative merchants / lenders are, and how flexible systems are. I think the standard 30 day revolving credit, or the 3/6/9 month EMIs that were defined could change, with the type of credit really evolving depending on the use case.

3. Co-branded credit lines: Like a Paytm / BharatPe, but this is still at a UPI App level. I was thinking more in terms of merchants, especially those with frequent purchases. Example: a Zomato / Swiggy credit line that is payable every week

4. A credit orchestration play: An assumption here is that a customer could have multiple credit lines for multiple merchants use cases, if we assume #3 will play out. And in any situation, when there are multiple providers, there is an opportunity for an orchestration level player to come in, and in real time, direct the user to the most relevant credit method available.

All of this is exciting, no doubt. But what we will have to remember is that this is an ecosystem play, and multiple players need to be aligned for this to scale

A word of caution though. There’s a growing narrative among new age apps and infra players, that simply enabling credit on UPI is a path to winning the market. That framing misses the point. Credit Lines on UPI are not a distribution advantage by themselves. They are, at their core, a balance sheet and infrastructure efficiency unlock - a way for lenders to deploy capital more flexibly, reduce friction in disbursement, and potentially cycle capital faster. That, and the fact that this can be used via UPI rails reduces the barrier to entry significantly. That matters for lender economics, but it doesn’t automatically translate into customer adoption.

But let’s go back to the basics here for a second.

Customers don’t choose products because of the rails. They choose based on approval rates, pricing, UX, trust, and contextual relevance.

Distribution still matters. Underwriting still matters. Merchant integrations still matter. Positioning still matters. An app offering traditional loan products with better reach, stronger risk models, or clearer value propositions can outperform a CLOU native product despite CLOU being structurally more efficient for lenders.

The infrastructure is largely in place. What will determine outcomes is execution across the stack: policy alignment, compliance, risk discipline, distribution depth, and product design. It is important to remember that CLOU is an enabler, not the strategy.

But what is clear is, that the ecosystem is betting big on this. Maybe fully autonomous payments still have risk and user adoption barriers, some part of these flows will be agent first. Shopping for sure.

But to take several steps back, what is an agent exactly?

An agent is like a really smart assistant that can do your shopping and pay for things by talking to different apps and websites for you.

This is an “Explain it like I’m 5” definition. But at its core, thats what an agent is. It’s a piece of software, that you’ve given some pre-defined authority to, that can then execute tasks on your behalf.

If I had to break down agentic commerce, I’d start by splitting it into two distinct parts. The first is the shopping experience itself, which is browsing a catalogue, comparing products and prices, and building a cart. The second is agentic payments, which is where much of the current attention is focused: how an agent actually completes a transaction once the decision has been made. You can read more about this in part 1 of this article I wrote a few months ago.

The Painted Stork

[#75] The AI Money Movement Layer: MCP, ACP & TAP are launched but are autonomous payments really the future?

The big talking point over the last month has been the launch of agentic payments. There are 4 things that stand out for me…

Read more

6 months ago · 8 likes · 2 comments · Ambika Pande

At its core, all these different protocols are coming in BECAUSE it looks like the ecosystem is moving towards fully agentic or agent assisted execution. Now, in this shopping example, imagine if every e-commerce website had a different way to say “I’m ready to pay.”

• Store A says “Payment is authorized,”

• Store B says “Payment requires action,”

• Store C says “Payment is processing,” and

• Store D says “Mandate is pending.”

The agent would need to learn a completely different “language” for every single store, and with 100 stores, that’s 100 different languages. Now scale this: if your agent is shopping at 10 stores a day, that’s 10 different languages to speak, 10 different ways to check if payment worked, and 10 different error messages to understand. And one mistake means a broken payment, and at millions of transactions, the system collapses.

So how do you make the entire flow easy for agents? As with most things in technology, making something easy usually starts with standardizing protocols.

The way I think about agentic commerce is through one question: how do we make the entire process easy for agents? The answer, unsurprisingly, is protocol standardization. What we’re seeing now is orchestration and standardization being layered across every step of the commerce journey.

Continuing with the previous example, these protocols ensure that all ecommerce websites speak ONE language (”incomplete” means need your PIN, “processing” means payment happening, “completed” means done), so your agent learns ONCE and works EVERYWHERE. Without standards, agents break when they see new payment states they don’t recognize; with standards, agents handle millions of transactions across thousands of merchants using the same simple rules, because complexity breaks at scale, and standards prevent that.

But before diving into those layers, though, it’s worth stepping back and mapping how agentic commerce originally emerged, and what the flow looked like before these standards existed.

2021: Launch of LLMs, with OpenAI

Took everyone by storm. Everyone and their aunt was on OpenAI, using it for research, playing around with it, and writing linkedin posts using it. And naturally, with this new interface creating a critical mass of users, the next thing that immediately came in, was - how will shopping work here

The TLDR: two broad structures were emerging in how these protocols handle the authentication and payment flow:

2024: Enter the Model Context Protocol

Launched and open sourced by Antrophic, it was designed to standardize how AI tools exchange data, and talk to each other. This was quickly taken up by almost every LLM, with each building their own MCP. At its core, the MCP provided a standardized way for apps / merchants / and any third party websites to be able to talk to LLMs, and essentially pull details, such as caalogues, prices, and eventually initiate payment through the LLM. The MCP helped the customer via ← LLM chat → merchant to actually bring the shopping experience into the LLM.

This agentic payments idea was taken up by almost every merchant x payment player, trying to solve for an end to end autonomous flow. And they tried to solve it through different ways.

2025 - present : Protocols for agentic commerce, Mastercard, OpenAI, Visa, Stripe, Google, orgs building “AI first”

All big network players debuted their own protocols for enabling agent led commerce and payments, which was enabled through LLMs and MCPs, and now further focused on how agents would be given authority to access stored user credentials to initiate the payment, and whether stakeholders would recognize that authority. These approaches broadly fall into 2 buckets:

1. Mandate-first approaches:

1. Razorpay x OpenAI (UPI Reserve Pay) : Pre-authorized payment blocks at the merchant level

2. Google AP2: A trust layer that stores mandates and validates payment instructions against pre-set rules

Alipay AI Pay: A trust layer that stores guardrails and stores these guardrails on Alipay servers. Now, this isn’t EXACTLY a mandate, it is more like setting guardrails. Banks have been onboarded on Alipay’s Agentic Commerce Trust (ACT) protocol, where they recognize the authority of this guardrail. The user pre-sets these rules, and at the time of transaction, the agent retrieves it from the ACT and banks authorize it. This recently hit 120M transactions in one week!

Note: Alipay is a little different, it operates as the issuer and the acquirer AND the network, so the number of stakeholders it has to manage is lesser

Alipay as the ‘issuer’ for the end user: Authentication & PIN

When a user “onboards” onto Alipay, they create an ‘identity’ on Alipay.

• Authentication: Alipay handles all the “hard” security. Whether it’s a FaceID scan on your phone or a voice-print on your smart glasses, the merchant never sees your PIN or password.

• The “Mandate” Handshake: Because you trust the Alipay app, you feel safe setting a rule like “Let my AI glasses buy coffee under $10.” You are authenticating the Policy, not the individual cup of coffee.

Alipay as the ‘acquirer’ for the merchant

Merchants don’t just “accept cards”; they plug into the Alipay Ecosystem.

• When Merchant X onboards, they use Alipay’s ACT Protocol APIs.

• This means they are ready to receive “Agentic” requests. Instead of waiting for a human to scan a QR code, their system can talk directly to an AI agent because both speak the “Alipay language.”

Alipay as the ‘network’ via the “Single Ledger”

This is the most important part. Because Alipay is both the Issuer and the Acquirer, the “movement” of money is often just a row change in their own database.

• Standard Way: Money moves from Bank A → Network →Bank B (takes 1-3 days).

• Alipay Way: Money moves from User’s Alipay Balance →Merchant’s Alipay Balance.

• This happens in milliseconds. Because Alipay “sees” both sides of the transaction, they can guarantee the money to the merchant instantly. They don’t have to wait for a clearing house because they are the clearing house.

Note: This is essentially how Alipay works in China. When a user / merchant onboards on Alipay, their respective banks see Alipay as a ‘trusted proxy’ i.e. any future request from Alipay is treated as valid by the bank. And that is how this agentic protocol is so quickly able to get buy in - it is a closed loop model.

2. Non mandate, agentic approaches: either by pre-authorizing an agent to execute certain actions OR by creating a single use token defining narrow context (for security)

1. OpenAI x Stripe ACP: Delegated payment tokens created on-the-fly for specific transactions.

2. Visa TAP: Trusted agent protocol using stored tokenized credentials

My view then, and now remains that in payments, friction is a feature, not a flaw. That extra layer of authentication builds trust. Users want to know their money isn’t moving invisibly.

But there have been two significant updates since that piece that are worth unpacking:

1. Mastercard’s AgentPay protocol has entered the autonomous/agentic camp

2. Google’s Universal Commerce Protocol (UCP) launched, fundamentally changing the infrastructure layer

While the first article focused on WHAT these protocols do differently, this piece is about how the pipes are changing to enable an agent-first commerce world.

I’ll first talk about Mastercard AgentPay, purely because it has similarities to Open AI and Stripe’s ACP.

Mastercard AgentPay - Mastercard coming in with a OpenAI x Stripe-esque flow

Mastercard announced AgentPay in early 2025, and at first glance, it looks similar to the OpenAI x Stripe protocols, for agentic payments using tokenized credentials.

1. Extends Mastercard’s existing tokenization infrastructure into the agent space

2. Introduces Agentic Token - which are essentially tokens with embedded agent identity and authorization. Essentially when the agent is invoked, it passes checkout context in the form of a single use token (which puts constraints on that transaction, so that the token can be used ONLY for that specific payment (usually a tokenized card already) - merchant, basket size, and so on). The network / issuer authorizes and the payment is authorized (depending on risk rules also running, if risk demands, then a final human step could come in. Four things are happening here

✅ Card authentication: It’s a stored card that has been tokenized. This happens even without in agent in the loop payment

✅ Standard risk authentication: Evaluates each transaction based on past trends and patterns. This also happens today

👉 Agent authentication (this is new): This as far as I understand is registered beforehand by a merchant / platform that allows agentic payments. So it would be the merchant agent ID that is being authenticated here.

👉 Transaction authentication (this is new): Happens via the single use, contextual Agent token

The distinction between Mastercard AgentPay and VISA TAP

Visa TAP is the equivalent of giving an agent approval to transact on your behalf. In a nutshell, imagine you are giving the agent your credit card, and allowing it to transact on your behalf, within defined boundaries. Here, VISA requires the user to pre-authorize the agent to act on the users behalf.

That’s not to say 2FA will not be required - in India, SEA regions, 2FA is centrally mandated, so the final step will require user intervention

Even with AgentPay, the agent may still need to trigger biometric authentication or PIN entry to complete the payment. This isn’t a bug, it’s by design. Mastercard is acknowledging that fully invisible payments may not be what users want. So AgentPay sits in the autonomous/ agentic camp, but with intelligent friction baked in.

But with OpenAI’s App SDK allowing native embedding of authentication flows directly within the LLM interface, this friction becomes almost invisible to the agent while remaining visible to the user. The agent initiates, the user authorizes via biometric, or passkeys, seamlessly. That’s the sweet spot. And that seems to be EXACTLY the way some payment aggregators are thinking about it.

Update: 17th Feb 2025: At the AI Summit held in Delhi, India: Cashfree launched Cashfree here, a way for users to execute UPI and card payments natively within the LLM chat

My hunch is, especially in regions where 2FA is mandated, this is the best of both worlds. It prevents friction from redirection by handling the payment within the same window, but at the same time, it keeps enough friction for the user to have ‘trust’ that the payment is being authenticated the right way.

The Real Infrastructure Story: Google’s Universal Commerce Protocol (UCP)

What is interesting is how Google is approaching this. Everything is being looked at from a way to simplify the agent experience. You can check out the developer documentation here.

While protocols like AP2, ACP, TAP, and AgentPay define how agents authenticate and move money, they all faced the same underlying problem, which is that every payment provider speaks a different language. So, essentially, MCP reduced integration complexity for both merchants and LLMs - it gave both a standard way to integrate with LLMs, and now with MCP gateways, instead of merchants integrating with each LLM’s MCP, they can now integrate once with the MCP gateway. This gave merchants also a standardized way of interacting with LLM chats to pull things like products / pricing

But the problem of standardizing states across payments still exists

What I mean by that is, is that different payment providers have different ways of communicating the same state. Some examples:

✅ Razorpay uses states like "created", "authorized", "captured".

✅ Stripe uses "requires_action", "succeeded". Example below:

For an AI agent trying to complete a checkout across multiple merchants using different payment providers, this variability is a nightmare. The agent has to:

1. Learn different error codes

2. Handle provider-specific edge cases

3. Interpret different status workflows

4. Manage different retry logic

And that is exactly what Google’s UCP is trying to solve - by abstracting away the the complexity that comes when agents have to deal with multiple payment providers of the merchants.

That is what UCP is. It doesn’t move money. It doesn’t authenticate users. And it doesn’t compete with Stripe or Adyen.

Instead, UCP is a standardization layer that sits on top of payment aggregators and methods, creating a universal language for agents to interact with checkout flows. So how the MCP was a standardization layer that sat between LLMs and merchants, UCP is a standardization layer that sits between the Agent and the payment providers. Think of it this way: AP2 is the trust/mandate layer, while UCP is the distribution/standardization layer sitting on checkout. Let’s walk through an example.

Without UCP

1. Agent initiates payment at Merchant A (uses Razorpay)

   1. Agent must understand: payment.status = “authorized”` → proceed to capture

2. Agent initiates payment at Merchant B (uses Stripe)

   1. Agent must understand: payment_intent.status = “requires_action”` → trigger 3DS flow

3. Agent initiates payment at Merchant C (uses Adyen)

   1. Agent must learn another set of states and error codes

❌ Every new merchant integration = learning a new payment provider’s quirks.

With UCP:

1. Agent calls Merchant A’s UCP endpoint → gets standardized response: `status: incomplete, action: requires_authentication`

2. Agent calls Merchant B’s UCP endpoint → gets same standardized response: `status: incomplete, action: requires_authentication`

3. Agent calls Merchant C’s UCP endpoint → same structure, same logic

✅ The agent only needs to understand one set of states, regardless of what’s happening underneath.

Sidebar: The difference between MCP and UCP is the layer they’re standardizing

MCP (Model Context Protocol):

Enables LLMs to call merchant APIs and access catalogue data, so essentially allows for agent to merchant communication. Example: product browsing, cart creation, order initiation, and in some cases payments as well.

UCP (Universal Commerce Protocol):

Standardizes checkout/payment states across providers. Even if the MCP allows the LLM agent to pull merchant details, the merchant will still have multiple payment providers. Some type of payment orchestration will happen at the time when checkout is invoked. The agent will have to handle different responses from different methods, and different payment providers themselves. That is where UCP comes in. It gives a standardized way for the agent to communicate across different payment providers.

Example: “Complete payment” → UCP returns standardized state regardless of underlying PA

How MCP + UCP + AP2 work together

Let’s walk through a real transaction:

1. Agent initiates payment: User says “pay now” in ChatGPT

2. Agent calls merchant’s UCP endpoint: “POST /ucp/checkout” with order details

3. Merchant’s UCP layer determines payment method: Could be AP2 (mandate), Stripe (delegated token), or stored card

4. If using AP2:

   1. UCP calls AP2 to check standing mandate

   2. AP2 validates: Does this match user’s pre-approved spending rules?

   3. AP2 authorizes consent across stakeholders

   4. AP2 returns response to UCP

5. UCP translates AP2 response into standard format:

   1. If approved: {status: “processing”, next_action: null}

   2. If needs auth: {status: “incomplete”, next_action: “requires_authentication”}

6. UCP returns to agent: Agent sees standardized response, acts accordingly

The agent never knows if the backend used AP2, Stripe, or Razorpay, and it doesn’t need to know. It just knows the payment is “processing” or “incomplete”

Why this matters: Google is building the pipes for agent-first commerce

What Google has done with AP2 + UCP is create a two layer infrastructure:

1. Layer 1 (AP2): The trust layer allow for somewhat autonomous payments

   1. Stores and validates mandates

   2. Provides authorization framework

   3. Creates new authentication paradigm

2. Layer 2 (UCP): The distribution layer, allow for easy agent integration

   1. Standardizes agent-facing APIs

   2. Abstracts provider complexity

   3. Enables one-integration-many-merchants model

This is the plumbing that enables AI-assisted commerce. Compare this to the current state, where every PA has different APIs, every merchant has different checkout flows, every agent integration is custom. This then becomes a problem for a world where agentic commerce is first.

Protocols will help standardize the ecosystem, enabling faster scale up of agent assisted actions

1. The first wave of agentic payments focused on protocols, how to authenticate, how to authorize, how to move money.

2. The second wave is about infrastructure - how to standardize, how to scale, how to make agentic commerce viable for 10,000 merchants, not 10.

Google’s UCP is an important development in this space because it’s not trying to own the payment flow, but instead it’s trying to make everyone else’s flow accessible to agents. If UCP (or something like it) becomes the standard, we’ll look back at this as the moment agentic commerce became possible rather than just plausible.

But let’s not forget: the most elegant infrastructure in the world can’t force users to adopt fully autonomous payments if they don’t want them. The future is agentic, for sure. The only question is how much of it will be autonomous and how much will be intelligently assisted. My money’s on the latter.

While we’re on this point of agent / agent assisted work, this “lack of protocol,” what is missing in today’s workflows - and i’ll explain through an example that probably hits closer to home

I’m sure we’ve been reading all about it. How if you don’t adopt AI you’ll get left behind. But this works in 2 ways:

1. At a personal level, adopting AI in your workflows. Maybe for building personal projects, apps, automating certain workflows (like note taking, research, and so on, even PPTs etc). I’d say most folks are getting up to speed here - almost everyone is using some sort of AI tool to assist them, especially in repetitive tasks. Most knowledge workers are here ✅

2. At a professional level: This is where we’re falling short. Because there is confusion - at the professional level, we’re mixing up personal workflows vs professional. Even at work, I use AI at a personal level, for my own work, research, and deliverables. But using it at a professional level, requires these “protocols” for a lack of a better word, to be set up at an organization level. Most companies are stuck here. ❌

Issues such as: messy organizational data (product names inconsistent across systems), no standardized protocols (each department has different processes), edge cases everywhere (manual workarounds that AI can’t handle), high stakes (mistakes affect customers, revenue, compliance), and system dependencies (needs to talk to 10 different tools correctly).

Lets take an analytics example. I want my AI agent to be able to pull data, clean it, sort it, and then give me an analysis of what I want. In an ideal world, the employee asks for analysis on Q3 revenues in the AI agent, and the AI agent returns the answer.

But there is a lot that is required for this to work. You need:

✅ Databases set up properly: Product categories standardized (not “Electronics” in one DB, “Consumer Electronics” in another), and revenue tables need to have consistent schemas, consistent date and revenue formats

✅ Clear data dictionary: AI knows which table to query, which fields mean what, and how to JOIN tables correctly

❌ But what actually exists: Data in 3 different systems, product names spelled differently, categories changed halfway through Q2, scattered data across Excel, some in SQL, some in Salesforce

Result: Garbage in, garbage out. AI returns wrong numbers, employee loses trust, goes back to manual work.

When a company claims they’re building AI-first, I don’t ask about their LLM choice or their agent capabilities. I first ask to understand their workflow

I ask: Show me your database schema. Walk me through your customer onboarding workflow. Explain how code moves from development to production. Because AI’s value isn’t in the interface, it’s embedded in the workflow. AI in the professional space is not about buying employees AI subscriptions, and “building a personal project using Cursor” which is a low stakes, and a relatively un-messy task.

The real test of an “AI first” company is in their plumbing.

If your product taxonomy is inconsistent, your AI will return wrong answers. If your onboarding has manual workarounds, your agent will break on edge cases. If your deployment pipeline requires three Slack approvals, your AI can’t ship code autonomously. The companies actually building AI-first aren’t the ones adding chatbots to their UI, they’re the ones who rebuilt their foundations to eliminate complexity at every layer. Clean databases, standardized processes, documented edge cases and automated pipelines is not “jargon” anymore, it is what is ACTUALLY required to make this AI stuff work.

Companies skip this because it’s boring infra work, and a painful process that requires cross functional buy-in. It has no immediate impact, it can take months if not years. And if the key tracker for companies is “revenue” then it’s hard to attribute anything to this immediately. But without it, AI will only work for personal productivity, never professional automation.

The future is agentic, the only question is how much

Here’s where I land after watching this space evolve:

1. Agent initiated payments are inevitable: Shopping in LLMs provides exponential value through personalization. Payment initiation needs to follow.

2. Infrastructure standardization will happen. UCP like layers will emerge across because the current complexity is unsustainable. And the companies that are truly able to optimize will build systems foundations first, keeping an eye on ease of automation.

3. Trust layers will be required. Whether AP2, AgentPay, or something else, the ecosystem needs ways to verify agent authority, and the ecosystem needs to also recognize the authority of said agents, which probably requires stakeholder buy in.

4. You’ll also need a way to encrypt this data - agents should ideally be able to execute without being privy to private information. If there are agents who are doing this on behalf of the customer, they will have customer details that ideally should not be moved.

What’s uncertain:

1. How autonomous will payments actually be? My bet: less than the hype suggests. Friction will remain a feature. OpenAI’s apps SDK allowing embedded authentication flows will probably be a big deal, since it will open up the floor for native experiences, while maintaining data security sanity.

2. Will mandate based approaches scale? Setting up mandates per merchant is cumbersome. Category-based mandates require infrastructure that doesn’t exist yet.

3. Will banking systems adapt? This isn’t just a fintech problem. Core banking systems need to recognize AP2 mandates, AgentPay tokens, and delegated credentials as valid. That’s a multi year effort.

The likely outcome: I think we’ll see a hybrid model emerge:

1. High frequency, low value transactions: Mandate-based (AP2, UPI Reserve Pay) for repeat merchants like groceries, food delivery

2. Medium value, occasional purchases: Autonomous with 2FA (Stripe ACP, AgentPay) with embedded authentication

3. High value, infrequent purchases: This will have a human element to it, with explicit confirmation. High chance that this remains as is, and never becomes agentic.

A note of caution: while I’m kicked about all these models coming in, what is key to remember is that authorizing agent access to personal details comes with a level of risk

You’re giving the agent authority to act on your behalf. And even though you’re defining boundaries clearly, what if there is a “bug” or a malfunction in the code, which gives the agent authority over and above what it has been given OR the system malfunctioning, allowing the agent to go beyond its limits?

And the second, the agent does have access to valuable information: it may not be payment details, which are encrypted, but behavioral data, which is valuable.

In this case, while we’re solving for customer experience and ease of enablement, what we also need to keep in mind is, these need to go hand in hand with data privacy protocols, and stringent risk measures.

1. Consolidation of licenses across payments (PA), cross border payments (PA-CB), prepaid instruments like your wallets, prepaid cards - which is more of a method / loyalty instrument play (PPI), NBFC (for lending), broking, getting a UPI certification (the latest being Zet), and Account Aggregators (AA)

2. Certain stack specializations playing out:

   1. NBFC + PPI + UPI App for a combined lending and wallet play, to act almost as a method of payment.

   2. Full stack payments play: PA (which as per the November 2025 RBI guidelines also includes the PA-O (online), and PA - P (Physical), PA-CB, UPI App,

3. Crossborder being a standalone play: The likes of Brisk, Skydo, and Xflow sit here, with the logic (and rightly so), that cross border payments, both inward and outward remittances are big TAMs, and complex enough to warrant single minded focus.

You can read more about it in a past article I wrote, below:

2025 also brought with it updates in how these payment licenses specifically are seen, which now cover use cases across online, offline and PA-CB, instead of separate licenses (PA vs PA-CB), or lack of clarity (where does PA-P sit)

In the last year, the Indian payments landscape has consolidated significantly , and not just in sheer volume of licences granted, but in regulatory clarity and structural definition. Whereas earlier frameworks (2020, 2021 and the initial PA‑CB regime) left gaps in how different payments businesses mapped to risk, capital and customer flows, RBI’s Regulation of Payment Aggregators Directions, 2025 has, for the first time, provided a unified umbrella with clear sub categories

It also makes the requirements more stringent: with stronger compliance, more oversight, and more compliances around escrow, and fund flow in general, to reduce risk of arbitrage, and fund co-mingling. Some key call-outs

1. PA‑O (Online) and PA‑P (Physical) are now accepted as defaults for domestic acquiring and remote payments

2. PA‑CB (Cross‑Border) is bifurcated into Inward (I) and Outward (O) flows: essential for international transactions.

3. Entities operating in both PA-O, and PA-P need to use the same escrow for both. This is interesting to me, not just because it reduces regulatory arbitrage (high risk concentrated in one escrow, using funds of one escrow to cover the liquidity crunch in another), but also because 1) it unifies risk at an entity level, and 2) it also seems to indicate, that more and more a pure online or pure offline play doesn’t work, and this is a consequence of a lot of players going after both a PA- O and PA-P license. Big entities such as Razorpay, Pinelabs, are already in online and offline. PayU is the next player trying to go offline as well with a (reportedly) strategic acquisition. Zoho launched with both the PA-O and PA-P plays. This also means that for players such as Cashfree (which is going heavy on crossborder, or smaller players such as Easebuzz, there could be possible activity offline here)

What is interesting is that RBI, through its 2025 guidelines has moved to a 1 license regime for payments, which is functionally segmented

This has moved to a one licence regime - but functionally segmented by flow type and risk profile. This is similar to other regions I looked at: Singapore, EU, and the UK, which usually have one overall license, and some sub segments underneath the.

However, what is different from India and other regions is also stark.

1. There is no license separation between infra and actual fund flow, which results in everyone going after the same umbrella PA license in India, despite having no play in money movement. Example: even if you are NOT involved in fund flow, but just in payment initiation (think, a payment orchestrator, or even a UPI app), you would still need to probably get a PA license

2. There is no compliance reduction based on entity scale in India: Compare this to entities in UK and Singapore. For newer / smaller entities operating at a smaller scale (details here), the license is different, and the compliance and reporting burden is lesser, allowing space for smaller players to come in and compete. In Singapore, MAS offers a Major Payment Institution license and a Standard Payment Institution license, so even small players can operate under regulation without the full compliance burden. And SPI & MPI is differentiated basis the scale they have: volumes: SPI ≤ S$3M/month (single service) or ≤ S$6M (aggregate); above this = MPI. SPI’s & MPIs can conduct the same activities

But what is interesting to me, is that against this regulatory backdrop, and the way these payment licenses are structured, there are some archetypes that are coming up in payments.

I’ve come up with five strategic clusters: I’d actually say there are 4, with a sub-segment of the cross border strategy, which is the “online only strategy.” But more on that in the coming sections.

1️⃣ The “license as a shield” strategy

This group holds PA‑O and perhaps PA‑P: driven by necessity rather than growth play. These companies use the licence primarily to service domestic payments and hedge regulatory risk. They typically do not prioritise or pursue cross‑border flows in terms of mone movement, but rather are adjacent to the core flow. But since there is no ‘infra only’ license unlike other regions discussed above, we could see players get in here. Some examples of players here:

• Decentro: A fintech providing API solutions for KYC, payments, and lending. Does not handle the money flow, but is payment adjacent. In EU for example, the PISP license (Payment Initiation Service Provider) would suffice. In India, it has the PA‑O, PA‑P (Its PA-CB application was returned)

• Digio: Provides identity, e-sign, and payment APIs. It just has a PA‑O license. Again, no direct involvement in the fund flow.

• Khatabook: A business app for kiranas. Helps for payout and payment enablement as well, but again, no fund flow. PA‑O only

• Navi: This is another example I spotted, and an update from September ‘25, when I last did a deep dive in this space. It is a UPI App and and has a NBFC license. It’s PA license is in progress.

My view: While it is possible for these players to go into a fully blown “money movement” strategy, chances are that they will not, purely because the market is already crowded, with few players owning distribution and how (Razorpay, Pinelabs Paytm, come to mind).

And hence, the license appears to anchor them as an RBI licensed payments entity, despite not being involved in actual fund movement, helping preempt regulatory questions later. I expect other API first payment businesses, and even UPI Apps (such as a Navi) to get in here, purely so that they are a ‘RBI regulated entity,’ and RBI doesn’t panic at the thought of a non regulated entity processing billions in payments.

2️⃣ Full‑Stack Payments Businesses: All four licences

This is the strategic payments elite - those who have secured PA‑O, PA‑P, PA‑CB I and PA‑CB O, and in some cases a UPI App. They can serve domestic and international flows end to end. This covers everything, from customer distribution (Razorpay - Pop, Pine - Fave, Paytm etc), to merchant distribution, both online and offline, and both the inward and outward crossborder remittance licenses.

As of Jan ’26 the following sit here:

1. Razorpay

2. PayU Payments

3. Pine Labs

4. Paytm Payments

5. Cashfree Payments

6. Easebuzz

7. Airpay Payment Services

8. First Data (Fiserv India)

9. Lyra Network

10. Toucan Payments

11. Nomisma (ftcash)

12. MMAD Communications (Mpay)

This group defines payments as a fully‑fledged business: not a compliance checkbox. Here, cross‑border becomes product strategy, not just regulatory box‑checking. There are some interesting names here: Airpay, Lyra, Toucan, etc, which aren’t really what I’d call “market leaders” in payments, but could be setting up for either entry, or acquisition by bigger players just for the license.

3️⃣ India First Payments Plays: PA‑O / PA‑P Only, but no cross border

These players have built strong domestic franchises but have not (yet) pursued cross‑border licences. Examples:

1. PhonePe: Just PA‑O, and PA‑P, which is surprising to me, I expected PhonePe to get into cross border. My view is that it is probably a matter of time. Right now the focus is on the mega IPO to happen in 2026, and post that this will come into play.

2. Zoho Payment Technologies - PA‑O, PA‑P

3. CCAvenue (Infibeam): PA‑O, PA‑P

For some, cross‑border may remain a later strategic play. For others, the domestic margins and product ecosystems are ample in themselves, but with margin compression happening in domestic payments, it is only a matter of time before they expand (looking at CCAvenue here). Other players, like in the case of Zoho have a core business, such as CRM, which is the main revenue generator. I’m assuming the payments products launch in 2025, is some strategic play, which in its initial days will be funded by the $1B in revenues that it generates from its core CRM product.

4️⃣ Cross‑Border Only / Emerging Xborder Plays

Perhaps the most interesting frontier in 2026 is pure cross‑border payments - players targeting export/import flows without a domestic franchise anchor.

Right now, BriskPe and Skydo sits definitively here. BriskPe with PA‑CB I & O only, and Skydo with PA-CB I (as of 2026). Essentially this is a standalone cross‑border aggregator without PA‑O/PA‑P licences. From a pure export‑import stack perspective, this is a bold archetype that could become more common.Other players with PA‑CB ambitions in process include:

1. Xflow: In-Principle Authorisation Granted, 🟡 cannot operate

2. Paymate: Application under process, 🟡 cannot operate

3. Payoneer: In-Principle Authorisation Granted, 🟡 cannot operate

4. Paypal: In-Principle Authorisation Granted, ✅ can operate

5. Wise: In-Principle Authorisation Granted, ✅ can operate

6. TradePe: In-Principle Authorisation Granted, ✅ can operate

Additional cross‑border native players should emerge in 2026. This cluster represents the rise of the Year of Xborder Payments - where flows aren’t just added as a bolt‑on, but are the business centre. Expect this to accelerate as export‑oriented commerce and digital services monetise global demand. What is also interesting to me is that Skydo JUST has a PA-CB I (Inward) license, not the Outward license as well. Two things could be possible here: 1️⃣ The inward remittance market is big enough and has enough complexity to support a standalone business, or 2️⃣ Skydo is strengthening its inward remittance stack, and will eventually go for outward as well. However, I couldn’t see Skydo in the “application in progress” section on the RBI website, so I assume its the former and not the latter.

5️⃣ The Online Only archetype: have a domestic and cross border license (atleast one of PA-CB I / O)

I wouldn’t really call this a 5th archetype, but rather a subsegment of the 4th one - the cross border stack. I define this as players with payment aspirations, but more from a global payment stack. There are enough players that sit in here - which have a PA-O license, and atleast one of the PA-CB licenses, either inward or outward remittance, for it to warrant a separate section. This is what the data says:

Most PA-O players either don’t touch cross-border at all, or eventually add PA-P as they scale, signalling largely domestic ambitions, as seen with players like Zoho or Infibeam (CCAvenue). The ones that continue to remain online only tend to be more infra led and globally oriented.

1. Adyen India: Global payment player present in ~100+ countries. Has a PA-O + PA-CB- O

2. Boku Network Services: Global company, HQ’ed in London, US, and UK. It also has a PA-O and PA-CB O

3. Juspay: The big indian infra player, and looks like it will continue to stay in infra. It has already launched in multiple countries across 2024 and 2025. It has all 3 online licenses: PA-O + PA-CB I & O. The PA-CB licenses are a new update as of Jan ’26. This was not the case in the Sep ’25 licensing landscape - signalling both regulatory appetite and Juspay’s execution on international ambition.

4. Pay10, Payglocal, Unlimit India, and Worldline all have a PA-O + PA-CB I & O. Now with these players, they aren’t BIG in the domestic side, but I’m assuming this is more for optionality, the goal is to scale the global stack. The domestic PA-O license is just for regulations.

So, the themes that I’m watching in 2026 are

✅ Cross border strengthens as a standalone product stack:

2026 is shaping up as the year where PA‑CB becomes a standalone product stack, not just another licence tick. It is possible we see import and export centric API products, embeddable inflows/outs, and merchant facing foreign collection tools. For example, Skydo which has a PA-CB I, could show specialization in specific flows.

✅ Regulatory Optionality as Strategy

Choosing which licences to pursue now reflects strategy - regulatory hedging, domestic scale, global aspirations, or export first models. This segmentation will only sharpen in 2026. Every fintech worth their salt and which have some scale will have SOME license under RBI, and in the absence of infra only licenses, the PA becomes the usual suspect.

✅ Escrow and Compliance as Competitive Moat

With RBI’s unified escrow/KYC compliance norms baked in, players who build operations and risk controls around them will differentiate on reliability, and not just pricing.

But what is clear is that where a company sits on payments licenses at an aggregated level is a statement about ambition and product direction

Looking forward, the real story won’t be how many licences exist, but how they are leveraged, which products they enable, which flows they optimise, and which markets they unlock. If 2025 was the year of regulatory consolidation, 2026 looks like the year of strategic deployment. And they’ll likely probably fall in one of the above archetypes defined.

Hope everyone had a restful New Year. To kick things off, I wanted to start with something fundamental: how the banking ecosystem in India is evolving. Banks sit at the core of fintech, money movement, and credit creation, and a lot of the shifts we’re seeing across fintech right now make much more sense when you look at what’s happening here.

So for the first edition of the year, this is a deep dive into how India’s banking stack is changing, and why that matters for the future of fintech.

A few interesting movements in India’s banking ecosystem signal where the industry is headed in the next 3-5 years:

1. AU Small Finance Bank → universal bank license (2025)

2. Fino Payments Bank → Small Finance Bank license (2025)

3. Protean (an AA) → 4.95% stake in NSDL Payments Bank (2025)

This tracks with a broader trend: fintechs going after banks through mergers and acquisitions. Slice merged with North East Small Finance Bank to form Slice SFB (Dec ‘24). BharatPe and Centrum formed Unity SFB. Paytm was a payments bank until it got banned, I expect it to revive once it pays its regulatory dues.

There are emerging themes that seem to be driving the evolution of the banking sector

1️⃣ Government / policy themes

1. RBI wants to drive FDI in PSU banks to increase governance, transparency and capital efficiency. The current cap is ~20%. While it’s unlikely this will jump to ~49% (as recent news suggests), most PSUs currently have ~10% FDI, so we could see an influx of foreign capital.

2. RBI wants to consolidate smaller PSU and RRB banks to improve scale, strength, and governance. Phase one completed ~2020: PSUs reduced from 27 to 12. Major mergers included SBI with its 5 associate banks and Bharatiya Mahila Bank; Bank of Baroda with Vijaya and Dena Bank; and similar consolidations at Canara, PNB, and Union Bank.

2️⃣ Long term monetization strategy needs

I’ve written extensively about how fintechs in India are moving to full stack or lending due to limited monetization avenues. TLDR on how this is playing out with banks:

1. Fintechs becoming banks: There’s a clear pattern of fintechs wanting bank licenses to control more outcomes. Slice formed Slice SFB. Jupiter has been pursuing a stake in SBM for 3 years. Paytm got a payments bank license before being banned. PayPal applied for a US bank charter in 2025.

2. Every bank wanting to become a Universal Bank: AU SFB pursuing universal bank status, Fino Payments Bank upgrading to SFB, and Protean buying into NSDL Payments Bank: all point to the same monetization imperative driving the industry.

But why is everyone trying to become a bank? Fintechs first came into the picture because banks didn’t provide the optimal customer experience

Fintechs entered the market with a clear value proposition: banks weren’t providing optimal customer experience. “We’ll be the middlemen, optimize everything, and get your work done.” The market scaled, fintechs raised capital, and did a solid job redefining what financial offerings should look like:

1. Payment aggregation: Razorpay, Pine Labs, Cashfree

2. Neobanks and lending: Jupiter, Slice

3. Lending / BNPL: Zestmoney, Axio, Fibe

4. Payments and product access: PhonePe, Paytm, GPay, CRED

5. Wealth management: Zerodha, Groww, and vertical products like Stablemoney (FD-first)

Most of these companies were founded during India’s fintech boom: between 2015 and 2021 (Pine Labs, founded in 1998, is the obvious exception). The household names are customer- and merchant-facing platforms: the apps people use daily.

And there’s another layer, of further unbundling: fintechs working behind the scenes, enabling service delivery. The infrastructure players. Mindgate and Olive deploy UPI switches in bank infrastructure. Vegapay partnered with BharatPe and Paytm to launch Credit Lines on UPI. Falcon builds core management systems for banks. Finbox and Setu power lending journeys and bill payments: Setu runs CRED’s bill payment backend; Finbox raised $40M Series B from Westbridge.

The point being: fintechs started by unbundling the banking stack.

Fintechs showed up and said: let us own the customer. We’ll handle onboarding, support queries, and aggregate the banks. You focus on being a bank. Then TSPs. the fintech infrastructure players entered with a narrower pitch: there are specific technical flows (payments, lending, KYC) that need expertise. Let us own those. And all was well for a while.

Then, 2 things happened.

1. With billions pumped into fintech, companies adopted a “win at all costs” strategy.

Capital was abundant. This funded “grow at all costs, monetize later” strategies. A loss leader approach: acquire customers first, figure out revenue later. It made sense a decade ago. Then fintechs realized this doesn’t work. The expectation of zero-cost pricing became permanent. Even after gaining critical mass, raising prices meant newly-funded competitors would undercut them with near-zero pricing.

But the “zero pricing now, raise pricing later” strategy worked initially because pre-UPI, payment methods (cards, netbanking) had minimum pricing set by banks or networks: 2% MDR on cards, for example. Even if offered at a loss, merchants understood there was a cost, and that providers were subsidizing to let them trial the service. Pricing would eventually come.

The second part of the long-term monetization view was cross-sell. But unless you pulled off what Paytm did: Soundbox + lending innovation, it doesn’t work. Your core offering has to make money.

2. DPI: with UPI as the game changer came in mandated as free.

UPI now accounts for ~60% of payment volumes for any payment company. More if your average order value is around or below ₹1,500 (UPI’s AoV). With UPI expected to hit ~90% of total volumes, pricing pressure will only intensify.

This wasn’t just “a special merchant offer”: it created a market expectation that UPI is “supposed to be free.” Merchants refused to pay. Fair enough. (Credit on UPI, cards and credit lines may provide some rail monetization hope, but we’re still far from that.)

The result: UPI grew adoption, GMV, and MTU TAM, but compressed revenue TAMnot just for merchant-facing providers, but for everyone in the chain. Players building around DPI rails (payments, data sharing, identity, and now lending and e-commerce via OCEN, ONDC) had lower revenues.

Eventually, banks, where core flows happen (UPI, AA) put their hands up: “Things may be free, but we have infra costs. You pay.” This is what happened with ICICI in July 2025 (and likely Yes Bank, Axis Bank the banks powering most UPI transactions).

👇 I ran numbers on how much Credit on UPI (cards and lines) needs to scale to pay for the free UPI (on savings accounts) mandate. The numbers:

At 2% MDR, Credit on UPI needs to be at 7.32% of UPI P2M value

Overall, when I look at credit card volumes in India, and CC as a % of total P2M transactions, this is around 17%. So targeting a 7.32% for Rupay + Credit Lines on UPI is feasible theoretically. What will impact this is merchant and customer adoption, although with recent Credit Card launches by PhonePe and Gpay for Rupay on UPI, may signify that this is ready for takeoff. But only time will tell, and this is not time that fintechs may have.

So then, my takeaways are threefold:

1. If your core offering doesn’t make money, you’re in a tough spot. Cross-selling to a “free or near-free” base requires massive effort into other revenue streams, and it hasn’t been successful for players without scale.

2. If your core offering is built around free or near-free rails, it won’t make money: especially if you don’t own direct connectivity to the core rail. Example: in payments, only banks can connect to UPI rails.

3. If you’ve built something that requires banks to act (move money in UPI, share data in AA) and the bank isn’t making money, then you won’t make money either.

And that is why everyone is gravitating towards a few themes:

✅ The volume game (which gives leverage), but it's won. PhonePe, Paytm, GPay on B2C; Pine Labs and Razorpay on online and offline merchant sides.

✅ Wealth management, intrinsically profitable. Almost every wealth player is profitable: Angel One, Zerodha, Groww. There’s margin to go around, and opportunities to build for specific customer pockets, and product pockets mass middle, mid-to-low income, savings and investment (like Bachat), or FD / MF first such as Stablemoney, PowerUp.

✅ Go wherever the bank makes money. With margin compression in core DPI services, the strategy is to follow bank revenue. The major source: lending (interest income). That’s why we’re seeing a surge in lending and lending-adjacent fintechs: credit management systems, lending TSPs, alternate credit scores, etc.

The problem with “go wherever the bank makes money”: big banks have little incentive to move unless there’s value in lacs of crores, and smaller banks lack risk appetite.

It’s almost a catch-22:

1. For big banks, moving anything takes months, if not years. Heavily regulated, massive organizations, constrained by policy and opportunity size. For HDFC (₹346k Cr revenue FY25), would they make internal changes: new CMS/LMS for a credit product, or partner with a TSP, for a INR 1,000 Cr/month GMV lending opportunity? Revenue is single-digit % of that. While massive for lending TSPs/fintechs (Zestmoney and Axio were each doing INR 400 Cr/month at their peak), it’s a blip for a big bank.

2. For smaller banks: challenger banks like SFBs (AU SFB, Ujjivan SFB) or newer universal banks (IDFC First, Bandhan), this could be interesting. They have user bases of 2.6M (Ujjivan), 12M (AU SFB), to 35M (IDFC, Bandhan), which is one-tenth of established banks like HDFC (120M users). They want to grow and are willing to take more risk, partnering with TSPs and fintechs to acquire customers or merchants. But they can’t handle risk, and one big fraud case in credit or payments can wipe them out. In non-credit businesses, monetization is limited, and it’s a “loss leader” game. Even with the spiritual will to enter, the ability to fund losses is constrained.

To solve for different types of products that require banking flows (payments, deposit only, credit) is why India introduced tiers of banks

Perhaps this is why India introduced tiered banking licenses: to solve for these exact constraints.

Payments banks, small finance banks, and universal banks, with each tier designed to match different risk appetites, capabilities, and business models. The idea: give players the right-sized playground to operate in, based on what they can handle and what the market needs.

But now, we’re seeing movement: payments banks want to become small finance banks, and small finance banks want to become universal banks. Why?

Monetization and profitability are capped at the lower tiers, and RBI’s FY25 banking report suggests this is intentional (you can read it here) If you can only take deposits, or must lend primarily to the priority sector (underserved - earlier 75%, now 60%), your ability to make money is constrained. This base is inherently riskier, with limited ability to take large ticket amounts or repay consistently.

The numbers tell the story:

1. Payments Banks (Fino, Airtel) in FY25: $7-10M profit

2. Small Finance Banks (AU, Ujjivan) in FY25: ~$150M profit

3. Universal Banks (IDFC, Bandhan) in FY25: ~$250M profit

That’s a 10-20x difference.

And these banks all started operations around the same time: 2014-2017. Despite similar timelines, the difference in what they can/cannot do in lending and the inability to make money elsewhere is driving everyone up the chain. Fino wants to become an SFB. AU wants to become a universal bank.

Now, unless the government mandates a way for payments banks or SFBs to make money or provides some “extra” incentive for staying in that tier, everyone will move up the chain. It’s a pure business call. But even then, it doesn’t solve the underlying issues: improving operations and efficiency at banks, or enhancing their ability to take calculated risks.

And that’s where two things seem to be moving in the banking landscape in India.

1. RBI supporting FDI in PSU banks - it may improve operations, but only if management autonomy and performance linked incentives are addressed

Let’s dumb this down a little bit. RBI essentially wants to bring in foreign direct investment into Public Sector Banks. Why? Multiple reasons:

• PSU banks in India are essentially your commercial banks in India, where the government holds > 50% stake. The key players here are your erstwhile State Bank of India (SBI), Punjab National Bank (PNB), Bank of Baroda (BoB), Canara Bank, Union Bank of India, Indian Bank, Bank of India, Bank of Maharashtra, UCO Bank, Central Bank of India, Indian Overseas Bank, and Punjab & Sind Bank. They’re important because

• They are known to have extensive presence, not just in your urban and metro areas, but also rural areas

• They help implement government welfare schemes. Not that private banks don’t, but if the government does not have majority interest then it cannot drive this through private banks, it can only incentivize OR if they want to strong arm, then introduce bills or policy. But that is an extreme step

• There is also a lot of trust that customers have in PSU banks. Since it is government backed, it is very unlikely to fail.

Now, the problem with PSU banks is that there is absolutely zero incentive for them to innovate, bring new products to the end customer, and take risks. Not that there is for private banks, unless there is profits to be made, but there, they are still profit minded. Take a minute and think about it. When you think of a PSU bank, what comes to mind? Extremely slow moving. Bureaucratic nightmare. Backward tech systems that take years to upgrade. Unwilling to adopt new technologies.

The hypothesis that RBI seems to be working with here is that FDI investment will help solve some of these issues. FDI then brings in more transparency, operational efficiency, and global best practices. The bank is then also judged against global comparables. Since there are significant foreign capitals, sharper questions are asked, less opacity, low margins are questioned.

And it’s not that PSUs are a stranger to this. This already exists. As of the March 2025 quarter, specific examples of foreign shareholding in major PSU banks include SBI (9.6%), Bank of Baroda (8.7%), and Canara Bank (11.9%).

A point to note here is that the FDI investment limit in India in PSU banks remains ~20%, and hence, if you see the above numbers, they don’t breach that limit, which are all ~10% or lower. In contrast, large individual FDI deals have primarily occurred in private sector banks, which have a higher FDI limit of up to 74%.

There has been market speculation and government consideration of raising the FDI limit for PSU banks to 49% to attract more capital, but the official limit remains 20%. In fact, we’ve seen a sharp drop in the market share of PSU banks ever since the government came out and clarified that right now there are no plans to increase this to 49%. So clearly, the view in the market is that increasing this limit to 49% somewhere will help. Whether that really is the case or not is anyone’s guess. In private banks, while the cap is 74%, most don’t exceed 55%. In fact, in the case of Yes Bank, and Axis bank, the FDI is ~45 - 48%, well below the 74% cap. But the point is, that there needs to be atleast 40-50% ownership allowed.

Now, I have a few things that I’m thinking about to unpack this FDI piece further, and what will actually drive better operations

Just because the Indian government is pro FDI doesn’t mean this will automatically make PSU operations more efficient.

1. First, the Indian government needs to increase the PSU cap to atleast 26%, and provide a path to majority investment.

26% ownership is the magic number for minority investors. It’s essentially the minimum amount of votes that are required to block / veto any major decisions, which usually require 75% consensus. Anything below that is not worth anyone’s time. And further: this needs to provide a path to full control. So, if FDI is capped at 20%, then you’re not going to get significant investment in PSU banks, instead foreign investors will focus on the private sector: an example is the Japanese holding group: MUFG taking 20% stake in Yes bank, and committing to bring this ownership up to ~25%. That isn’t happening in PSU banks.

Now, while minority foreign investment brings capital, market discipline, and global best practices, FDI investors care primarily about profits and dividends, not really day to day control. The government retains majority ownership and voting rights, protecting policy objectives. PSU banks, being backed by the state, are less likely to fail, making minority FDI a low risk tool to encourage transparency and governance improvements. And all this is fine: but taking a stake without having atleast veto rights is a bit concerning to any investor worth their salt.

I’d also look at this from another perspective: for the government, this is all capital tied up in the market. You can’t really use it. Instead, liquidating those positions will free up more capital for them, which then they can use for other purposes: maybe to revitalize smaller banks, infra related activities (God knows metro cities in India can use this, shoutout to Bangalore potholes).

They key point to note here is that FDI improves bank operations only when at least 2 of these 3 exist:

1. Management autonomy

2. Performance-linked incentives

3. Regulatory pressure or market discipline

FDI alone = insufficient. What RBI will have to do is give management autonomy to drive outcomes and make it worth their while. And then policy and regulations need to drive innovation and best practices. Look at the salary of the SBI bank chairman vs private banks. The SBI Chairman’s salary has increased, drawing INR 63.87 lakh in FY2025 (including basic pay, DA, and other components). This increased from INR 37L in 2023. In comparison, in FY2025, HDFC Bank CEO earned significantly more, with a total package around INR 12.08 crore (INR 3.09 Cr basic + allowances + bonus).

The second thing that seems to be happening is consolidation of smaller banks to give smaller banks a better ability to absorb shocks, and handle risk taking appetite.

This has happened to some extent: it is so that smaller, weaker banks have more leverage, and the ability to absorb shocks, so that they can take more risks. There are some new reforms being planned for the next year, you can check out the link here. But essentially, there is a focus on bank consolidation, both for PSUs, and RRBs (Regional Rural Bank, the policy being enforced is 1 state, 1 RRB)

Consolidation also increases the banks issuer base and market reach, lending and credit expansion capabilities, and profitability and operational scale, while smaller banks struggle with limited capital, technology, and talent, and consolidation allows economies of scale and operational efficiency.

However, there is also a risk here: that of too much consolidation, also consolidates power, and reduces options in the market. And we’ve seen consolidation in the market play out in a bad way in other sectors: With the streaming platforms: JioStar, Prime Video and Netflix, ads are running rampant. And, the less said the better about Indigo, in retaliation to less favourable policy decisions in the aviation sector, decided to hold the government and the country hostage, by not complying. So, RBI needs to be cognizant that this does NOT happen here.

So then, to improve efficiency and risk appetite, RBI is making moves:

1. The government recognizes banks are inefficient and wants to bring in FDI to fix this, but unless they increase the threshold to at least 26%, it won’t help much.

2. There’s focus on market consolidation to increase bank strength and improve governance, but it remains to be seen how they’ll protect against consolidation risks.

What is NOT solved: Incentives for banks to invest in certain revenue streams or innovation, and performance-linked incentives that would further drive this.

Now, add to this the facts I discussed earlier.

That fintechs have realized that unless they’re:

1. In a space where the bank also makes money, they also won’t, thus moving into credit products, with a focus on eventually becoming an NBFC, or in some cases, a bank (more in point 2).

2. Some fintechs have taken the leap to become banks themselves, versus just NBFCs for credit, to gain flexibility across operations—banks can also handle payment flows. That’s why Slice and BharatPe, despite having NBFCs for credit (BharatPe with Trillionloans, acquired controlling stake in 2023; Slice with Quadrillion Finance, acquired in 2019), also got SFB licenses, giving rise to Slice SFB and Unity SFB.

3. No incentives for banks operating in payments bank/TSP spaces or priority sector lending, and with profits being 1/10th, will naturally result in banks like Fino and AU SFB moving up the chain.

4. A fourth point, not specific to banks: while fintechs are tech-first and understand flows well, cracking lending and credit requires the right team. Lending is more than “solving for UX and workflows”-it’s about reducing cost of capital and managing NPAs. Team quality and experience matter enormously here.

So now, if I put all of this together, these are a few predictions I have with how this is going to evolve:

1. Private Banks will raise FDI, but PSU’s will only be able to attract serious investors if the below happens

• No investor worth their salt will get in for a stake less than 26%, since that is what gives them control and veto power.

• Management autonomy, and incentive linked compensation is introduced

• There will also have to be incentive linked compensation to specific revenue streams, such as digital banking, maybe even DPI schemes, to promote investment and innovation

On a side note, there seems to be a lot of interest from Japan based corporations in India’s financial system.

I expect this trend of investment from Japan to continue, not just in banks, but in the Indian fintech landscape. This is a positive outlook on India’s credit and financial landscape. In fact, investors see a lot of synergies between Japan and India, in terms of tech innovation in the financial landscape, and both regions together are seen as a collective strategy in APAC.

SEA and MENA is obviously of interest as well, but Thailand, Vietnam, Malaysia etc are still 5-10 years behind India in terms of fintech innovation, although favourable policies, especially around neobanks, and movement in the open banking space in this region suggests that this space is going to grow fast. An example of some financial investors driven by Japanese companies is below: SMDC, MUFG, and Mizuho are the key players, taking stakes in multiple financial entities in India.

2. Fintech banks will continue to move up the chain to become universal banks: both Slice SFB and Bharatpe - Unity SFB.

These banks probably see themselves more as “neobanks,” and not priority sector lenders, which is what a Small Finance Bank essentially is. It’s highly possible that consumer apps, and fintech with merchant distribution will go after banking licenses now.

Note: What is interesting is that this is NOT how RBI sees this. Basis RBI’s 2025 banking report (and you can check out the detailed report here), a lot of how they see banks in specific tiers as “specialized banks.” What RBI seems to be saying is that the system needs differentiated institutions, not clones of universal banks at smaller scale. But then, for that to happen, there have to be ways to make money apart from just lending, which requires pricing on DPI to come in, which isn’t the case as of today. This report also does acknowledge data fragmentation in banks, and hence the focus on ULI and AA frameworks for pulling data from different sources, and focus on risk management, and interoperable architecture, but doesn’t mandate anything internal to banks just yet, so this will take time to move. I had written in detail about this problem of data fragmentation in my article: #64 Innovation at the edges, stagnation at the core

The point being, that in absence of monetization strategy, this has started happening, EVEN in regions where infra monetization exists, so it’s only a matter of time before it happens in India: Example: Paypal in the US applied for a banking charter. I see it further breaking into two categories:

👉 Consumer apps going after banking licenses, and eventually becoming universal banks.

Priority sector lending as we’ve seen doesn’t really help with revenues. And these are fintechs, which means, they want to operate as neobanks, which means that they want to be able to do everything that they can. In fact, RBI’s 2019 SFB regulations set a path for exactly this. The minimum requirements for a SFB to become a universal bank is the following.

• 5 years of successful operations as SFB

• Listed on stock exchanges

• Net worth ≥ INR 1,000 crore

• CRAR consistently above regulatory minimum (CRAR = Capital to Risk-Weighted Assets Ratio)

• GNPA & NNPA under control (Gross NPA and Net NPA). Usually this means GNPA is < 4%, and NNPA is ~1.5%.

• Proven governance, compliance, and risk management

• No supervisory concerns from RBI

BharatPe - Unity SFB commenced operations in November 2021. Slice - SFB rebranding completed in 2025, although North East SFB (that Slice merged with) has been operating since 2016. Now, Bharatpe in 2025 announced that it was targeting an IPO in 2026. Slice in 2025 announced that it is gearing up for an IPO in 3-4 years.

Both these timelines coincide with ~5 years of operations as a SFB, and in the case of Slice, from the date it rebranded. So clearly both of these are going for the universal bank play, and will try to become the “neobank” model that India sorely lacks today. And maybe that is why there is also a lot of investment interest around your small finance banks - Shivalik SF bank for example, raised funds from investors that include Accel and Lightspeed. I assume the vision here is for it to turn into a universal bank, in light of the profit limitation on SFBs. I expect this to continue to happen for SFBs, especially those with serious investment raised - all eyes on SFBs such as Jana, Suryoday (RBI approved 1729 Capital - an FPI, to acquire upto 9.99% stake in it in December ‘25) , Equitas SFB and so on.

👉 Merchant / tech players will go after payment bank licenses, purely to support the tech stack play.

There will be interest from fintechs to acquire / merge with banks, across the board. Not just on the B2C side, but on the B2B side as well: Protean acquiring a 4.95% stake in NSDL payments bank. Now, there are two ways this can go:

1. Your B2B / tech fintechs may decide that going after a payments bank is easier to support their core business of building tech stacks rather than lending. But even if this is the short term vision, there is nothing a payments bank can do, that a SFB, or a universal bank can’t.

2. Movement here may start off from a payments bank perspective, but more up the chain. And unless there is a change in revenue making opportunities, or incentives to the lower tiered banks, there will continue to be movement to everyone become a universal bank: this is for payments + SFB, and for fintechs, which will go from payments → SFB → Universal Banks

As the market undergoes a “re-bundling” of sorts, in the next few years, we will see consolidation happening, not just at the fintech, but at a bank - fintech level, Airtel Payments Bank being a prime candidate

Airtel Payments Bank has massive scale for a payments bank. It has reportedly ~155M users, and is in the top 10 in 3 out of the 4 legs of UPI payments. It made FY25 revenues of $7M on this 155M user base. AU SFB in contrast made revenues of ~$81M in FY25, on a 12M user base.

However, it should be noted that Airtel is a telecom provider with ~35% market share in India, and a large part of its user base can be attributed to some cross sell initiatives; reportedly 400M in India have Airtel SIMs, which rationalizes this 155M number. I had written a piece some time ago on the intersection of fintech and telecom, and you can check it out here: #53 Neobanks, eSims. and Telecom: the rise of sticky financial ecosystems.

The one leg that Airtel Payments Bank isn’t in the top 10, is the remitter leg, which is the customer bank, suggesting that despite its big base, a lot of its customers are not digitally savvy, and thus doing only UPI payments or mobile banking. And of course, despite having a 10x greater user base, Airtel Payments Bank revenues are < 10% of AU SFB. Food for thought.

Payments banks like these could be prime candidates to be the focus of some consolidation efforts as fintechs scale, and want to own part of the bank.

It is possible that with Slice and BharatPe paving the way, consumer apps with scale become prime candidates to go get banking licenses of their own, such as what a PayPal in the US has done.

PayPal in the US, despite the scale and volume it has, processing ~25B transactions every day, has applied to get a bank charter expand small business lending and offer savings accounts, reducing third-party reliance and gaining FDIC insurance for deposits. While PayPal is more B2B focused, this seems to set the stage for “fintech-banks,” both B2B and B2C focused, paving the way for the new wave of banks in this sector.

Credits:

A special thanks to Atul Pande for his invaluable insights on the banking and financial landscape in India.

On one hand, these rails are transformational. Strong, interoperable public infrastructure is what separates developing economies from truly digital-first nations. India has leaped ahead by making foundational financial services cheap, real-time, and universally accessible.

But on the other hand, this raises an important question: what does the future of Indian fintech look like when more and more layers become commoditised? How do open, standardised rails impact innovation, business models, and the quality of financial products we ultimately receive? Do DPIs unlock a burst of new innovation - or do they constrain what private players can build on top?

This is how things are playing out right now

A core tension in India’s DPI story is that these rails are positioned as free public goods (UPI, BBPS, Aadhaar/eKYC, DigiLocker, AA, ONDC, ULI). This creates an expectation that core infrastructure should have zero or near-zero cost.

1. For fintechs building on top of these rails, this means a massive GMV / MTU TAM, but extremely small revenue TAM. User adoption is high, but willingness to pay is very low. And core margins come from volume, not product differentiation.

2. As a result: Companies prioritise distribution over monetisation. Players undercut on pricing just to gain scale. The overall revenue pool shrinks, even as usage explodes.

3. This leads to a structural reality: the core product on the rail is rarely profitable. Fintechs eventually recognise they need to expand beyond the rail to make money. Hence the rise of the full-stack fintech, which is something I’ve covered a lot in multiple editions of this newsletter. Essentially, firms add adjacent revenue lines (wealth, lending, cards, insurance), and profitability only appears when companies reach full-stack scale.

4. But this creates a new problem: Entry barriers rise - new players can’t survive long enough to scale. Competition reduces, and power consolidates among incumbents. Innovation slows because the market becomes structurally hostile to newcomers, AND there is no incentive to innovate on core rails because of the lack of monetization opportunity.

5. Meanwhile, RBI continues to expand the DPI footprint. New rails (like ULI) overlap with existing private solutions in identity, underwriting, data exchange, and orchestration. Public-sector rails may or may not be better, but they will set the benchmark price often zero or near-zero.

The end result?

✅ Building on DPI drives adoption, but compresses margins.

✅ The economics push players toward diversification, not focus.

✅ Innovation becomes harder in a market where the infrastructure is free, but the business is not

All this eventually leads to a narrative every fintech operator has discussed at some point:

👉 Indian customers aren’t willing to pay (or aren’t habituated to paying for digital financial services)

👉 Margins are thin → revenue potential is low → products commoditise quickly
leading to an inevitable race to the bottom

👉 Newer players find it extremely difficult to break in because CAC is high, monetisation is weak, and incumbents cross-subsidise heavily

👉 RBI is increasingly absorbing core fintech value propositions
whether through policy, rails, or direct product interventions

👉 So the real question becomes: what next?

And if you look at recent announcements and moves across the ecosystem, this direction feels more real than ever.

Theme 1: Full stack fintechs are winning and it shows in profitability

The larger fintechs, which are the ones now preparing for IPOs, or which have already IPO’d have all quietly converged on the same strategy: become full-stack. That means owning payments, credit, distribution, compliance, infrastructure, and increasingly SaaS. And that bet is finally paying off. Once you control multiple layers of the stack, unit economics start to bend in your favour: acquisition gets cheaper, cross-sell increases, and infra revenues smooth out volatility. This is why the biggest names- whether it’s the publicly listed players or Razorpay-scale fintechs are now turning operationally profitable. Not because they cut back, but because scale + full-stack = leverage. In a market where standalone fintech products struggle to survive on thin margins, the full-stack approach is becoming the only path to sustainable business.

PhonePe raised $600M from General Atlantic in Oct 2025, largely through a secondary transaction, at a $14.5B valuation. GA, already an investor, doubled its stake from ~4.4% → ~9%. This kind of pre-IPO stake consolidation usually signals strong investor confidence ahead of a public listing. PhonePe is widely expected to target a 2026 IPO, though timelines will only be confirmed once the DRHP is filed.

📊 2025 Valuation Snapshot

• 2025 Revenue: $808M (at INR 88 = $1)

• 2025 Valuation: $14.5B

• Revenue Multiple: 17.93×

📊 2024 Valuation Snapshot

• 2024 Revenue: $575M

• 2024 Valuation: $12B

• Revenue Multiple: ~20.85×

There’s a mild multiple compression from 20.85× → 17.93× YoY, which is consistent with broader fintech re-ratings globally. So then why did General Atlantic pay a premium? If you take the $808M revenue and apply PhonePe’s 2024 multiple (~14.8×), the “fair” valuation looks closer to $12B. So the $14.5B price does imply a premium of ~20%.

But there are several reasons why this premium makes sense:

1. Market leadership in UPI:

PhonePe holds ~52% UPI market share, which in India essentially means owning the consumer payments market itself. Dominance at this scale usually commands premium multiples - similar to Adyen’s historically high multiple due to sheer market strength. Here is where the scale and volume point I had made above comes in

2. Strong merchant-side distribution (PA):

PhonePe’s merchant presence and growing payment acceptance (PA) stack adds another high-moat channel. Distribution is becoming a major differentiator in Indian fintech. Scale and volume strength again here.

3. Profitability, depending on how you look at it:

PhonePe reported a $198M (INR 1727 Cr) loss in 2025. However, after stripping ESOP-related expenses, they are profitable by ~$71M. For many public-market investors, adjusted profitability (ex-ESOP) is a real signal, and it lines up with how companies like Groww have been evaluated as well (more on this later, but Groww is currently trading on the public markets at a revenue multiple of 27x!). And it’s gotten to this profitability because of its scale.

What really stood out to me was Juspay. The company turned operationally profitable in FY25, posting ~INR 62.5 Cr in profits a sharp turnaround from a ~INR 97 Cr loss in FY24. Juspay may have pioneered UPI integrations in India, but like every player building on free public rails, it eventually hit the ceiling on margins. UPI is massive in volume but thin on profitability. So Juspay did what most resilient fintechs are now doing: expanded the stack.

• From UPI → Payment Orchestrator

• From India → Europe, SEA, LATAM

• From software layers → Full-stack acquiring, including its recently announced HSBC partnership

My view is that these international pushes + deeper stack plays are what unlocked its FY25 profitability. The orchestrator and global acquiring business has far better unit economics than UPI rails and Juspay seems to have executed this shift exceptionally well. If you want a deeper dive into how this fits into the broader “license aggregation” trend in fintech, I’ve covered it in detail in: All Roads in Fintech Lead to License Aggregations: Part 6 (link below)

Theme 2: Wealth-tech is emerging as a profit pool and markets are rewarding it

Wealth-tech has quietly become one of the few fintech segments in India with clear monetization and real profitability. Public markets are rewarding both market leadership and the ability to monetize, which is why valuation multiples in wealth-tech (ex: Groww) look meaningfully stronger than in low-margin spaces like payments (ex: Pine Labs). As a result, we should expect more entrants and more capital flowing into wealth-tech. It’s one of the rare fintech categories where revenue potential isn’t capped by DPI rails.

Groww: Raised ~$200M in a pre-IPO round from GIC and Iconiq Capital in June 2025, at a valuation of ~$7B. It’s a market leader in the broking space. It’s a leader in the broking space, and is also trying to get into wealth management, with the acquisition of Fisdom. Stats:

📊 2025 Pre-IPO Valuation Snapshot

1. Revenue: $443M

2. Valuation: $7B

3. Multiple: 15.79x

📊 2024 Valuation Snapshot

1. Revenue: $296M

2. Valuation: $7B

3. Multiple: 23.61x

Here’s how it played out: Pre-IPO fundraise in FY25: Slight correction in valuation multiple here in 2025, the valuation has not moved from 2024 to 2025. Again, Groww is a market leader, reportedly has ~50M active users on its platform. It’s also profitable, and in March 25, it reported a net profit of $205M (INR 1824 Cr).

IPO premium: In November, Groww IPO’ed at a whopping $12B valuation, which is a revenue multiple of 27x. This is much higher when compared to public market equivalents

Groww has clearly outperformed expectations. While most global and public comparables trade in the 8x-15x revenue multiple range, Groww is getting priced at the upper end and my view is that this is driven by a mix of fundamentals and market psychology.

My hunch is:

1. Groww is a massive consumer brand:

With ~50M active users, Groww has become a daily-use product for a large chunk of India’s retail investor base. That consumer-level visibility matters. Even anecdotally, like during the Ashes (where England got absolutely destroyed by Australia) Groww’s branding was everywhere on screen. Consumer mindshare drives investor confidence.

2. The first consistently profitable fintech to IPO

This is a huge differentiator. Paytm IPO’d while still loss-making. MobiKwik was loss-making for years and only turned a sudden profit right before IPO (FY24: INR 14.08 Cr profit vs FY23: INR 83 Cr loss). Post-IPO, they slipped back to a INR 29 Cr loss in Sep ’25 quarter. Groww, on the other hand, has shown consistent, multi-year profitability, which the market rewards with higher multiples and higher trust. And this is probably also because this is one of the segments where DPI does not cap revenues.

3. Pent-up demand for a strong, consumer-facing wealth-tech IPO

Investors have been waiting for a clean, profitable consumer fintech story and wealth-tech fits that perfectly.

• Zerodha, the category-defining giant, is still private at a reported $7B valuation, with FY25 revenue of INR 8843 Cr ($1B) and profits of INR 4237 Cr ($481M) - more than 2× of Groww’s numbers. You can check out Growws DRHP here

• After Groww’s listing, I expect public markets to value Zerodha materially higher whenever it decides to list.

• Dhan also hit unicorn status at a $1.2B valuation in Oct ’25. According to reports, it is tracking $100M ARR and ~$17.5M profit for FY25 - an 11–12x multiple, which fits neatly into the same valuation band.

4. Wealth-tech and broking simply make money

This is the core reason for premium valuation. Unlike payments, where margins are structurally thin, broking + wealth-tech have multiple monetization layers:

• F&O brokerage (Groww charges INR 20 per order)

• Margin funding

• Distribution revenue

• AMC economics (Groww acquired Indiabulls AMC in May 2023)

• Credit income through its NBFC (gross loan book $123M as of Jun ’25)

This stack gives Groww a wide, high-margin revenue base that scales with trading activity and AUM growth, not just user growth. You can check out my deep dive on the Next Wave in Wealth Management in India below:

I’d be remiss if I didn’t mention the other big fintech IPO that happened in November. Pine Labs IPO’ed at an expected revenue multiple of 11-12x, which is in line with global multiples.

Pine Labs also IPO’ed recently, targeting a $2.9B valuation. With FY25 revenues at $258M (INR 2,274 Cr) and a net profit of ~$0.5M (INR 4.8 Cr) in Q1 FY26, it came to market with steady fundamentals. At listing, Pine Labs debuted at a ~10% premium (~$3.1B). Unlike Groww, which clearly beat expectations, Pine Labs landed exactly where my broader thesis has been: Indian fintechs generally trade in the 9x –10x revenue multiple range. And this makes sense when you look at the business.

Pine Labs is a clear market leader in merchant payments and, much like Groww, is now fully diversified across the stack:

• PA (online and offline)

• PA-CB

• Account Aggregator (via Setu)

• PPI

• Consumer payments (Fave)

But the nature of the payments ecosystem, especially in India puts a tight ceiling on monetization. Payments, particularly UPI and now AA, are increasingly seen as public goods. And when something is positioned as a public good, the default expectation becomes: free, or close to free.

This has two consequences:

1. The revenue pool itself becomes structurally small, no matter how large the volumes.

2. Monetization is constrained by policy and public expectations, not just market dynamics.

So while Pine Labs has executed well, grown sensibly, and delivered a profitable quarter, its valuation is naturally limited by the economics of the payments category, unlike wealth-tech, where monetization is both clearer and richer.

Theme 3: Funding is concentrated in lending and wealth-tech - because these are the segments that actually make money

In FY25, a lot of non-IPO funding activity clustered around lending and wealth-tech. And the pattern is obvious: Lending makes money, through spreads, fees, cross-sell, and credit adjacencies. Wealth-tech makes money, through broking, F&O, distribution, AMC economics, and margin funding. These two categories have clear, proven monetization, unlike most other fintech segments where margins are structurally thin. That’s why investor attention (and capital) has flowed disproportionately here.

✅ Lending:

1. FincFriends: NBFC, founded in 2017. Raised INR 41.5 crore in debt funding in FY25 to target borrowers in underserved markets in Tier 2 and 3 segments. Reported revenues of INR 349 Cr ($39M)

2. Snapmint: Raised $125M in Series B in October 25, is a NBFC that looks at BNPL, Credit on UPI segments

3. Flexiloans: MSME lending platform, raised INR 375 Cr ($44M) in Series C in June 2025

4. Fibe: Formerly called Early Salary, gives instant personal loans to young professionals and the working population. Raised INR 225 Cr ($25M) in July 2025 as venture debt.

5. Finnable: Founded in 2015. Raised ~$60M in November ‘25. Offers secured and unsecured loans for salaried professionals. Reported $31M (INR 278.49 Cr) revenue in FY25, and $0.75M (INR 6.74 Cr of profit) in FY25

6. Yubi: Raised 411 Cr ($46M) in November ‘25 to fund AI and global expansion. It is a debt marketplace, not an NBFC. Revenues of $74M (660 Cr) in FY25, and losses of $46M (INR 416 Cr)

7. Lendingkart: Looking to raise INR 850 Cr ($100M) from existing investors in FY25. It got a majority stake recently acquired by Fullerton Financial - a Singapore based investment firm that invests in emerging markets. It is a NBFC, and lends in the MSME and working capital segments. FY24 operating revenue of $122M (INR 1090 Cr), and PAT of INR 174 Cr ($19M).

Yubi is not a NBFC and is the only player in the above list that is loss making, everyone else is a “tech enabled” NBFC. So then, maybe one learning here is: Standalone lending TSPs plays are tough, and unless it is a very lean sort of operation may not work. You need a NBFC.

✅ Wealth tech:

1. Dezerv: HNI wealth management platform. Raised ~ INR 350 Cr ($40M) in its Series C in October ‘25, and reported revenues of $3M and losses of $8M for FY24. For a company that has ~ INR 10k Cr ($1B) in AUM, this is surprising to me. I expect FY25 numbers to be much better.

2. Stablemoney: Raised a $20M Series B in June ‘25. Super app focused on FDs, and is now also launching FD backed cards

3. Sahi: Stock trading start-up founded by Swiggy’s ex CTO. Raised $10.5M in Series A funding in June ‘25

4. Powerup Money: Building ways to make mutual fund investing easier for Indians. Raised $7.1M in seed funding in June ‘25

5. Zerodha: They conservatively valued themselves at $3.5B a few years ago (they have ~$994M in revenues, and $476M in profits in FY25). However, looking at Groww’s IPO, with its rev X of ~27x, and profit (x) of 60x, just basis math, they could be valued at much higher, closer to ~$27B.

A point worth calling out here is the recent Signzy-Powerup acquisition - a telling signal of the pressure standalone TSPs are facing

Powerup Money began as an in-house initiative at UNI Cards, then spun out as its own startup. Similarly, PowerEdge, another UNI incubated card management product, also spun out and even raised INR 8.5 Cr (~$1M) in May from White Ventures and DeVC. And yet, within months, PowerEdge has now been acquired by Signzy - a global identity verification and fraud platform. In many ways, this acquisition perfectly illustrates the broader trend: operating as a standalone TSP in India is becoming nearly impossible. Margins are thin, competition is high, differentiation is hard, and DPI rails set expectations of near-zero pricing. The only viable outcome for most TSPs is either:

• scale extremely quickly,

• show sharp differentiation, or

• get bundled into a larger fintech’s full-stack offering.

The PayU–Mindgate deal is the most prominent example, a pure infra play getting absorbed into a larger full-stack strategy. And now Signzy’s acquisition of PowerEdge points in the same direction.

Meanwhile, the one area where fintechs are still seeing meaningful revenues is cross-border. Cashfree, Juspay, and a handful of others are placing big bets here because international payments and global acquiring have significantly higher monetization potential. Unlike domestic DPI rails, cross-border isn’t free, and that opens up real economics.

The takeaway is clear: TSPs as standalone businesses are dying, especially in sehments that don’t make money. TSP capabilities as part of full-stack fintechs are thriving.

In this phase of fintech in India, the monetization opportunity is KEY to sustain - growth and “hoping” that at some point monetization will come in is not enough

In this phase of Indian fintech, monetization is the strategy. Not a “later problem,” not a “phase two,” not a “once we get enough users” milestone. If your core business doesn’t make money today, it will not survive the DPI era. We’ve already seen this play out in domestic payments and consumer apps built on UPI. The industry kept hoping that monetization would eventually show up, the same way it exists for real-time payment rails globally. Everywhere else, RTP systems have some fees built in so the ecosystem can sustain itself.

But India went the opposite way: UPI became completely free. And when a rail becomes free, every business built directly on top inherits that pricing logic. This is exactly why the idea of capping UPI market share at 30% per app is nearly impossible to execute.

So then who going to pay for growth in a zero-pricing ecosystem? Only the top 3-4 players: PhonePe, GPay, Paytm, CRED, or companies backed by massive platforms like WhatsApp, Supermoney, or now Pop (via Razorpay). When the revenue pool itself is tiny, only players with deep pockets or broad product stacks can afford to subsidize the ecosystem. The only companies that make it through are the ones with real monetizable adjacencies - lending, wealth-tech, SaaS, platforms, cross-border, infra.

Everyone else is effectively running on borrowed time.

In fact, with ULI and a host of other building blocks the RBI is pushing, it increasingly feels like regulators are setting up “shadow fintechs” - public digital utilities that directly compete with established fintech entities. On one hand, these rails drive inclusion and adoption through free or near-free offerings. But on the other hand, they compress the monetization bandwidth to a point where only 2–3 large players can survive sustainably.

These are the DPI rails, the India Stack and they now span four layers:

👉 Digital Identity:

• Aadhar - biometric identity (fingerprint + iris + face). This also includes Aadhar based OTP for verification.

• eKYC (UIDAI + CKYC + PAN-based). This is whenever you’ve done fully digital KYC, or Aadhar XML / Offline KYC. This also includes CKYC, and PAN verification APIs

• eSign: when you sign online using Aadhar authentication

• Digilocker: this is a vault where you store all your digital documents, and can be used to verify who you are, instead of having to re-upload your documents

👉 Payments layers

All your UPI, BBPS etc sits here. I’m assuming the eRupee also sits here, but where this will end up is anyone’s guess. As I have mentioned in previous articles, stablecoins are much far ahead in this use case

👉 Data layers

Account Aggregators are the most well known here, but the government is also trying to build stuff around health and credit

👉 Marketplaces

This is the newest, boldest ambition: build “UPIs” for multiple sectors. ONDC: UPI-like network for ecommerce, unbundling the marketplace model so that buyer apps and seller apps can interoperate, and ULI (United Lending Interface): the equivalent of ONDC for lending.

ULI, if implemented the way it is envisioned, could make lending look like UPI:
Merchants integrate with ULI → pass customer details → pick the best lender → fetch data → get underwriting → complete documentation → trigger disbursal → all via standardised APIs.

In theory, this eliminates the need for intermediaries. In practice, TSPs will still be needed for workflow orchestration, compliance, and tech plumbing, but if RBI insists the service must be free, what is the incentive for TSPs to participate?

And this loops back to the larger point: the more the regulator builds free public rails, the smaller the monetizable surface area for private fintechs. Only players with scale, capital, or multi-product synergies will survive; standalone TSPs or thin-stack fintechs are going to find it increasingly unviable.

Now, just to clarify - I’m not against DPI. In fact, I think DPI is one of India’s greatest strengths. It’s essential for financial inclusion, and centrally driven rails are the only way you can ensure that banks, networks, and other ecosystem stakeholders actually participate and move in one direction.

My issue is not with DPI, it’s with the assumption that giving everything away for free is sustainable. When you build massive public infrastructure but don’t design a viable monetization model around it, someone somewhere is still footing the bill. “Free” is never actually free.

To draw a parallel from another domain I follow very closely: the Indian sports league ecosystem.With the exception of cricket, almost every league has struggled to survive. Why? Because apart from the central federation, nobody else makes money. Franchise owners bleed tens of crores annually. The structure simply isn’t sustainable. And that’s exactly the risk with fintech.

When the RBI steps in and makes services free for the end customer, with the logic of “let’s drive adoption now, we’ll figure out monetization later” the burden quietly shifts to the private ecosystem. And that makes it extremely difficult to build a durable business. In the early days, around 2015–2016, the first wave of fintechs didn’t fully grasp this. DPI was still evolving, UPI was just emerging, and everyone was betting on future monetization. But now, nearly a decade later, UPI has demonstrated very clearly that margins inevitably race to the bottom when a public rail is free and the cost of participation is pushed onto private players.

We’re now in a market where founders, investors, and operators understand this. There is far more realism. You can’t just build for scale and hope monetization magically appears later. The industry has learned, and often painfully, that unless the economics are designed upfront, entire categories become unviable.

In fact, with ONDC and ULI, we’re entering a new phase where the government isn’t just building rails - it’s effectively building competing products to what already exists in the market.

And that raises a fundamental question: if everything eventually becomes something that RBI or another central entity will provide, how do fintechs build sustainably going forward?

To be clear, fintechs will always build better than a central body. The innovation velocity, UX, experimentation culture, and customer-centricity are simply unmatched. That isn’t the issue. The real issue is the economics. We’ve already seen what happens with DPI: once the government builds a service and offers it for free (or near free), two things happen:

1. You’re forced to build on top of it because these systems are more stakeholder-aligned - for example, UPI requires banks, settlement systems, and compliance infrastructure, so you can’t bypass it.

2. Even if the DPI product competes directly with market offerings, the “free” price becomes the industry benchmark. Fintechs may offer superior experiences, richer features, and better reliability but when the reference price is zero, margins collapse instantly.

This is where quality gets hit. If you’re benchmarked to a free offering, even when the market is willing to pay for something better, the pressure on margins is so intense that you can’t sustainably build the superior product you’re capable of. And this becomes a systemic problem: innovation slows down not because fintechs can’t innovate, but because they simply can’t afford to at those price points.

This is the core tension emerging with ONDC, ULI, and the next wave of DPI:
public rails are essential, but public products offered free reshape the entire pricing logic of the market.

So if we assume that many of the essential fintech services - identity, payments, data flows, verification, lending workflows will eventually be shaped, absorbed, or centrally directed by the RBI’s long-term vision of DPI, then we have to ask the obvious question:

What is the future of fintech in India?

Because if core rails and core workflows are all moving towards some version of “public infrastructure, free, and standardized,” then the scope to build a profitable business narrows dramatically unless two conditions are met:

1. You are a full-stack fintech, meaning you own multiple layers: acquiring, issuing, lending, data, identity, orchestration, consumer app, and platform layers.

2. You operate at massive volumes, so even thin margins (or cross-subsidies) work out at scale.

This is exactly why every major fintech in India is now consolidating and aggregating aggressively: Razorpay, PhonePe, Pine Labs, Groww, PayU, Cashfree, all are assembling broader stacks. They’re effectively building “mini banks” or fintech conglomerates because that’s what the economics now demand.

And because they’re expanding horizontally across licenses, infra, and products, the bar for new entrants is getting impossibly high. If your CAC is rising, margins are thin, and your core API layer is benchmarked to “free,” then the right to win as a standalone player becomes very small.

This is also why the Signzy example matters. Signzy was built on top of existing identity rails like Aadhaar, Digilocker, CKYC, PAN verification which are all DPI components. Surviving purely as a standalone “identity TSP” is getting harder because margins on these rails compress over time. So what does Signzy do? It expands into card management by acquiring PowerEdge, a space where banks actually make money, where infra is sticky, and where the revenue TAM is real.

And that leads directly to the heart of the problem:

If every essential layer: identity, payments, data, lending workflows is becoming “public infrastructure,” and if all value accretive fintech layers eventually get pushed to free, then where exactly is the monetizable surface area left?

This is the DPI conundrum.

The rails are necessary, no doubt. But when these rails also compete with the private sector, and set the price expectation at zero, it shrinks the economic space for innovation, forces consolidation, and leaves very few viable business models for new or standalone fintechs.

The DPI conundrum

So if you’re a company primarily building around DPI rails, the first requirement is a dose of realism around TAM and revenue potential. We are firmly in a post-UPI world now, the phase where optimizing for distribution and hoping that “monetization will eventually come” is no longer a viable strategy. UPI has shown us exactly what happens when you build on a rail that is intentionally kept free: margins collapse, differentiation evaporates, and only the largest distribution engines survive.

So the real question becomes: How do you actually make money on top of DPI?
To answer this, I break it into two lenses: (1) raw rails vs differentiated value and (2) willingness to pay for differentiation

❓Are you just offering raw APIs without a scrap of differentiation, or are you able to give value additions on top of it?

Most DPI infrastructure (identity, payments, document rails, data flows) looks the same at the base layer: UIDAI, CKYC, Digilocker, UPI, AA, etc. If all a company is doing is wrapping these into clean developer APIs, then that works but only for a while. Every fintech eventually converges into the same experience: same KYC flows, same payments rails, same UPI handles, same AA flows, same document fetches.

Differentiation becomes marginal and short-lived.

UPI apps are the clearest example: Rewards can change behavior temporarily, but switching costs are near-zero because the underlying rail is identical for everyone.
In global markets, there is at least a small mandated charge on instant transfers, which creates economic headroom for intermediaries. But India sits in the “free” bucket, which means pure API providers end up in a race to zero.

Other regions: LATAM (Pix), Europe, the UK, MENA, SEA, even when they are adopting DPI-like models still allow minimum pricing. That tiny pricing layer is the difference between a sustainable ecosystem and a subsidized one.

❓Can you actually charge a premium for differentiated offerings, or is the expectation still to give it for free?

This is the bigger problem. You may build a better orchestration layer. You may offer intelligent workflows. You may deliver higher reliability, fraud tooling, or analytics…

But if the market expectation is:

“The underlying rail is free, so the experience should also be free,”
your ability to charge a premium collapses.

This is exactly what India has seen:

• Fintechs spent years optimizing for growth over monetization.

• They built massive distribution at zero cost to the user.

• Now, these same players have both the scale and the capital to keep pricing at zero.

• Any new player, no matter how good gets priced out of the market before they even start.

In regions where regulators mandate a minimum pricing floor, like Brazil’s Pix (0.3% MDR) the ecosystem remains economically viable. In India, the regulator has gone the other way: mandated 0% on UPI, and likely the same for other DPIs.

This is my mind map of where countries seem to sit.

1. 🇮🇳 India, which has DPI, but going by UPI and others atleast, has positioned it as “free” offers limited potential to monetize on the core infrastructure. And even with value added services, while there is opportunity to differentiate basis offerings, experience and so on, lots of fintechs have adopted the strategy of growth over monetization now - the focus is to use this to grow distribution. How early UPI apps came in, and acquired customers through VC funded cashbacks is a classic example. What is clear is: sitting here as a pure play TSP is very tough, this has to be part of a larger bundled or fullstack play, which is why we’ve seen so many acquisitions happen.

2. 🇺🇸 US: Doesn’t really have a DPI system in place - an example is open banking. Open Banking is driven by players like Plaid, but nothing is set up at a central level. As a result, merchants pay for basic standardization, and connectivity. However, this is changing. Section 1033 of the Dodd–Frank Act empowers the Consumer Financial Protection Bureau (CFPB) to mandate that: Banks must give consumers access to their own financial data through standardised, secure, and free APIs. Implementation is being finalized in 2025 - 26, so somewhere, players will have to start differentiating to monetize.

3. 🌍 EU / UK (today), and MENA / SEA in the future have multiple players in this space. There is a mandate centrally to offer DPI services through standardized APIs, but there is opportunity to differentiate, because 3rd party players that provide this service, have to pay some fee to the banks, or other financial institutions for processing payments, fetching data, or anything else.

So then finally, what can you do? The way I see it is follows:

1. Stage 1: APIs → Utility rails. These are the foundational, cheap (or free) rails everyone uses. If the rail is provided centrally (Aadhaar, UPI, CKYC, AA, Digilocker), great, then adoption accelerates. If not, private players step in to standardize, aggregate and abstract away complexity and get paid early on.
   But eventually, this layer gets commoditized.

2. Stage 2: Differentiation via value added infrastructure: This is where players try to escape commoditization: Enriched APIs, better reliability, UX, orchestration, bundling services that create clear ROI for enterprises, investing deeper in the stack for control (settlements, issuing, fraud, infra), and competing on price only to build scalable distribution. The players who win here adopt a “full-stack + bundling” strategy, because individual rails don’t make money, but bundled experiences can.

3. Stage 3 (Endgame): Full stack distribution and customer ownership. When margins collapse at the rail level, the only durable advantage left is owning the customer. This is where the ecosystem is heading: The biggest winners become full-stack fintech platforms that acquire customers at scale, bundle multiple products, and monetize across the lifecycle. At the end of the day, four things always win: Regulation, compliance, user trust and customer experience

This is what I expect from fintech, atleast in India, in the near future as compared to the world

While India will continue to see consolidation and full stack plays coming in, because of a “survival lens” and margin pressure, players in Europe and SEA, where pricing has been left to the market, along with some price floors, the lens is more strategic.

There still may be consolidation here: Tink (open banking player based in Stockholm, Sweden was acquired by Visa in 2022), GoCardless (open banking players based in the UK) which was profitable in Q4 FY25, was acquired by Mollie, a Dutch payments player, quite recently, in December ‘25. But this is more strategic, and not survival mode. And there is breathing room, and possibilities for infra only players to exist, unlike in India.

And in India, DPI will continue to reshape the entire fintech ecosystem

1️⃣ Lending: Credit demand never dies. But lending TSPs as standalone businesses will struggle, because much of the lending journey sits on DPI rails, identity, data, CKYC, AA, eSign. To survive, they must either go full stack, find a niche, or attach to a larger financial player.

2️⃣ Wealth segment: The only fintech segment consistently rewarded by the markets.
Players like Sahi, PowerUp Money and others are still raising because unit economics work, there’s clear consumer willingness to pay, and niches still exist. This category will likely see more entrants and more consolidation.

3️⃣ Building on top of DPI rails - Payments, identity, KYC, document rails, AA — these markets are now scale-driven, with razor-thin margins. To win here, you need one of the following: 1) massive volumes, 2) full-stack ownership, or 3) strategic consolidation. This is why payments players (PhonePe, Razorpay, Pine Labs) and even identity players (Signzy → PowerUp Money) are going full-stack.
I expect this consolidation to accelerate across all DPI-linked segments

Note: Crossborder is something that will continue to grow, both through existing full stack players, and standalone XBorder players, while stablecoins in India need regulation to catch up with them. If you want to check out my deep dive on them, click here: [#65] Stablecoins: Driving innovation where CBDCs fall short, while regulation catches up

And when I say full-stack, I mean the real deal:

✅ Backend with a database
✅ Auth and sign-in flows (looking at you Google OAuth)
✅ A proper database logging real data (Supabase, MongoDB)
✅ AI recommendations plugged in via OpenAI APIs

Because I’ve seen way too many examples of how people talk about how they built a fill product through vibe coding, and when you look under the hood, it’s basically a glorified clickable prototype.

My past experience with Cursor was a fail - duct tape dev for non coders

So I decided to build a fitness tracker: one where you log your workouts and it spits out AI-powered training recommendations. Simple in theory.

My first attempt? Cursor - but that went sideways almost immediately. I didn’t “develop” anything: I duct-tape-engineered my way through prayers, vibes, and increasingly frantic copy-pasting between Cursor and ChatGPT. Cursor would generate files, I would nod intelligently, and then promptly feed them to ChatGPT.

At one point Cursor just lost the plot. And this is probably because I didn’t really have the plot to begin with. It started spinning up new HTML files like it was possessed: multiplying them in some kind of haunted debugging ritual. Endless loops, mysterious errors, and I had no clue what was happening

I was able to use Lovable + Supabase + Google Cloud Console to set up a working frontend + backend website

From there I switched to Lovable, which thankfully with its pre-integration with Supabase allowed me to set up the backend, auth, and a real database seamlessly. I still had to wrestle with Client IDs, secrets, and API keys (Google for OAuth so people can log in with email, OpenAI for the recommendation engine), but Lovable made the whole thing way less painful.

The annoying part didn’t disappear. You still have to visit Google, generate an OAuth client ID/secret, go to OpenAI, create an API key and so on. The difference is that Cursor wanted me to hop between consoles, paste keys into three different places, and perform ritualistic incantations. With Lovable, while I did have to manually add the secrets to Supabase, to configure, I just added the keys into the chat prompt, and iit mapped them into Supabase for me, and handled the backend wiring. I still created the keys, but Lovable saved me the constant context switching and manual clicking.

Long story short: Lovable got me to a working site far faster than Cursor ever did. I wrote a detailed step-by-step piece about the whole experience, and you can check it out below

Emergent is this new “vibe coding” app that raised $23M in 2025 in Series A, that claimed to solve for both front and backend - exactly the issues that I faced with Cursor + Lovable. So naturally I was excited.

This was recommended to me by , as I had complained a lot about the backend issues with Lovable and Cursor, and this is a solution that claims to solve my backend woes. So, to have a reasonable comparison of how Emergent works, I decided to build exactly the same app that I did using Lovable, with the same functionalities - that of AI powered recommendations and a Google OAuth log-in, just so I can compare. To work then.

Thursday, 9:05 pm

Dinner done, brain recharged, and somehow I’ve convinced myself I’m ready for Round 3 (Round 1 being Cursor, and Round 2 being Lovable). Despite the emotional scars from Cursor and Lovable, I’ve been itching to try Emergent - it’s been sitting on my “one day when I have time/mental stability” list.

And tonight I have both. (Or maybe it’s just delusion. TBD.)

Plus, Emergent just announced a cool $23M raise in their Series A, so the hype is real. Time to see if it’s deserved, or if I’m about to add another chapter to my therapy journal titled “AI tools that made me question life choices.”

Thursday, 9:10 pm

Some learnings I’ve had from the last time (duh) is not to add on requirements later. Better to have a vision for the app, and put all requirements down in the start. Cool. I’m a veteran (or so I think), and I put in a prompt that talks about:

1. What I want to name the app

2. Its core functionality

3. Clearly call out the backend services I want to set up

The prompt in question below:

“Build me an AI powered fitness tracker, complete with log in through Google OAuth, and using OpenAI APIs, to allow me to log-in using my email, add my target muscle groups, activity duration (in time), and type of training (ex: cardio, strength, hybrid) and get an AI powered dynamic workout generated. Call it FitTracker. It should also have a database at the backend where it is logging all the log-ins at user level, and storing what the request was. I want a complete front end and backend enabled website”

Almost immediately, I see that with Emergent, it allows me to choose the LLM I want, vs Lovable that automatically manages this in the backend

Snapshot of Emergent:

I can’t do that with Lovable - but that doesn’t really matter. As the end user, what do I care? I just want my prompt to build something

Snapshot of Lovable entry screen:

The big draw with Emergent is pretty simple: it handles the painful parts. It has a fully managed layer for LLM APIs and Google OAuth. That means two magical things:

1. Universal LLM API key: I don’t need to go beg OpenAI (or any other model provider) for API keys and billing setups. Emergent handles it. Curious to see how this will be paid for though - I’m assuming some sort of prefunding will have to be done on Emergent.

2. Managed Google OAuth: no wading through Google Cloud Console trying to decode what a “redirect URL” is while questioning my life choices.

Already a win. Also worth noting: Emergent uses MongoDB for the backend, whereas Lovable plugs into Supabase. Translation: I don’t have to touch any external backend service. No third-party dashboards. No “wait where do I paste this again?” I can just tell Emergent what I want, and it spins it up.

Thursday, 9:12 pm

Emergent spins up a shiny new website for me, and politely asks me to try it. Great. I’m optimistic. We’ve raised $23M worth of expectations here: surely, this time, it’ll Just Work.

I click: Continue with Google, and the familiar page to select my account to log-in with appears.

A point to note here, since the OAuth is Emergent managed, the project name also shows at Emergent. You can see it below, where I can choose the account to proceed to “Emergent agent”

Compare this to Lovable - since we’re utilizing my project set up, the “skonlyzh…supabase” is the name of my project that I’ve set up in Supabase & Google cloud console.

I select my account, hold my breath and wait. And then….right back to the login page like nothing ever happened.

No token saved. No “Welcome back.” I feel like I’ve been gaslit. Cursor PTSD unlocked. At this point, I’m staring at the browser with a sense of foreboding. I feel like I already know how this ends.

And just to add to the vibes, while I can see different tabs in the UI, they’re basically non-functional. I can’t click anything to generate an AI-powered workout. I assume that magic unlocks only after login which currently refuses to acknowledge my existence. *Deep sigh*.

I open the Emergent chat window, type out the problem, and then whisper the sacred incantation I’ve now recited across multiple platforms: “please fix.”

At this point it’s less a command and more a prayer.

Also, this is an observation: Lovable and Emergent seem to have different default designs. Lovable seems to favour the lighter colour palette, while Emergent spins out a black and orange type of default look and feel.

Nothing wrong with either, I generally prefer a lighter colour palette - it seems cleaner, but it was just interesting to see the “personality” of Emergent.

Thursday, 9:22 pm

It’s been six minutes since I typed “please fix.” The Emergent agent is still thinking. I also have a lot of thoughts. I keep them to myself for now.

I also can’t add any other prompts until it finishes its existential crisis. Sure, there’s a Pause Agent button, but I don’t want to interrupt whatever ritual it’s performing to appease the debugging gods. So I do what any rational person does when they’re being held hostage by AI build tools. I go get ice-cream.

Thursday, 9:26 pm

I finish my ice cream and, with some apprehension, I open the Emergent tab again. Hallelujah. It claims it has “tested” and “fixed all bugs.” Apparently, the culprit was CORS.

And yes - I actually know what that means. I feel insufferably smart for exactly three seconds.

Quick explainer (because Past Me would’ve appreciated this): CORS is a browser security rule that blocks requests coming from another origin (domain). So if your frontend lives on one URL and tries to talk to a backend sitting somewhere else, the browser says: “um, who are you?”. So, if you don’t whitelist the domains in both your backend service (Supabase, in my last project) and your OAuth settings (Google Cloud Console), the browser just blocks everything, because otherwise they could get access to sensitive data.

So essentially, (and this is something I did when I was setting up the Lovable + Supabase configuration in my previous experiment with this) - I had to add the domains from where the request would originate on both Google Cloud Console (for OAuth), and Supabase, so that the request would be allowed, and the requesting domain would be recognized.

I’m guessing it was the same situation here. The app’s domain wasn’t whitelisted somewhere in the stack. Maybe Mongo, maybe wherever Emergent keeps its magical universal Google keys. Point is: something didn’t recognise something else, and CORS did what CORS does best, slam the door shut.

You can check more on how I avoided this issue in the Lovable + Supabase combo in my previous piece on building using vibe coding tools. I’ve linked the specific sections below. But TLDR: I had to manually set this up in my previous lovable experiment to avoid this, Emergent has debugged and fixed this automatically (or so it says)

1. Google Cloud Console - Authorized javascript redirect urls and redirections

2. Supabase set up and url configuration

Side note: 15 minutes of “testing” with no visibility into what’s happening? If I wasn’t stubbornly committed to finishing this experiment (and honestly, this story arc), I’d have rage-quit and tried another tool by now.

But fine. It’s “fixed.” Emergent proudly presents a little report of what it updated, and I’ll admit, I do appreciate that touch. Makes me feel like something actually happened behind the curtain, not just vibes and prayer.

It tells me I have a fully working app, with all the features I requested. I’m euphoric. Last time it took me two days. It can’t be this easy I think, as I test it again. And I’m right. It’s not. I still can’t log-in.

It’s the same issue. Log in → redirect → dumped back on the login screen like an unwanted guest. And of course, the workout generator still refuses to wake up. Hello darkness, my old friend.

At this point, the irritation is real. With Lovable and Cursor, fine: I expected a bit of chaos because I was stitching third-party services together myself. I was the duct-tape engineer in that scenario. But Emergent’s whole value prop is “we own the stack, we handle auth, we test it internally, you just vibe.” So why am I deja-vuing into the same problem? Still, I persist. I’m committed to this bit.

Thursday, 9:34 pm

So, obviously, I open up the Emergent chat again to tell it, hello sir, I still cannot log in.
Except I’ve now run out of free credits. Which means I need to pay. Again. So here I am, signing up for yet another subscription. At this point I feel there is a real opportunity for a start-up to provide cashbacks and discounts for for AI dev tools: “Build 9 glitchy apps, get the 10th one sort of working for free.”

What was easier about the payment process is that Emergent is India based, so I can just pay using UPI. No signing up for yet another recurring card charge, and then having to unsubscribe by logging in, or going to my email to figure out how to unsubscribe from the welcome mail. Unlike Lovable and Cursor, which I had to manually unsubscribe from because apparently the future of software is just cancelling subscriptions at this point.

I set up the Autopay, and cancel it immediately from my phone. Cost: INR 1,649 per month. My issue was that the Autopay mandate is for 10 years - October 2025 to October 2035. I almost didn’t see it because I just wanted to pay, and get back to fighting with Emergent. Now, when I read UPI Autopay docs for Razorpay and Juspay, they clearly mention that if there’s no defined expiry, the default can be 10 -30 years. Meanwhile, the other tools I tried which had through recurring card setups had a 1 year mandate.

Sorry, but this feels borderline predatory. Easy to miss. And there was a recent piece in The Ken about dark patterns in UPI Autopay where users unknowingly signed up for long dated mandates and some apps were making cancellation intentionally painful. While the goal is to make money, I think there is some responsibility that needs to be taken here: payment models need to mirror the use case.

For these “vibe coding” platforms, honestly, a pay as you go refill model would just make more sense. A ton of users only pay month one to test, and real retention only becomes visible around month three. Knowing that, I’m surprised there isn’t a credit top up option, especially when the product is still scaling up. And I genuinely feel, that in this day and age, when products are getting easier and easier to build, responsibility and ethical practices are way more important in gaining customer loyalty then just building a easy to use product (ex: Zerodha / Ditto Insurance are some that overall seem to have more positive customer reviews, and this is mostly due to their no spam policy, and responsible selling).

Anyway, I’m an expert at debugging. I inspect my plethora of solves, type out “PLEASE FIX” in block capitals into the chat. I contemplate adding some expletives in the chat, but I reason that that will just eat into my credits, and I’m also a cheapskate.

Thursday, 9:37 pm

Emergent does a deeper debug and discovers there’s some date issue causing the failure. Cool. But also , why wasn’t this caught in the first place? And then, in a very Cursor core moment (again, not being generic to Cursor, this is basis my specific experience with Cursor, more details in Part 1), Emergent decides to build a debugging tool to debug the thing it just built.

So instead of fixing the bug, we’re now building the thing that will (hopefully) identify the bug so that we can then fix the bug? Little odd, but going along with this for now.

What Cursor used to do when authentication failed was spin up separate HTML files. I’d have to download them, run them locally, manually test whether each service was working, and then feed the results back into the Cursor chat.

Emergent just pulled the same trick. It generated a debugging link, told me to click it, follow steps, observe, copy outputs, paste them back into chat. And I’m sitting here thinking: If you’re spinning up the file, why can’t you just see the events directly?

Why am I relaying logs back to my own AI engineer? Am I suddenly the debugging middleware here? But fine. I copy. I paste. I sigh. I persist.

There’s also this fun UX surprise: clicking the debug link doesn’t open a new tab - it replaces the chat tab. So I have to reopen the chat every time I click. Much design. Much wow.

What would be magical is the agent testing its own flows - clicking, logging, verifying instead of outsourcing the final mile to me. We’re clearly not there yet, but you can feel we will be. Someday soon, hopefully, this won’t be a co-debugging experience. It’ll be a “you build, you test, let me know when it’s ready” one. And to be fair and not to be overly critical, it’s only a matter of time before Emergent gets there. It’s me also working through my PTSD here.

But until then, copy, paste, pray.

Thursday, 9:40 pm

The debugging tool in question is below: a separate link Emergent has politely chucked in my direction. Fine. We click. It opens a test page with two buttons: Start OAuth Flow and Process Session. Basically a “choose your own debugging adventure.”

I dutifully follow the steps: hit Start OAuth Flow, do the login dance, return, then click Process Session. At this point I feel like I’ve become the bridging API between Emergent and Google OAuth. I am the auth callback URL.

And sure, this is progress: the tool exists! But it’s very “AI throws a gadget at you and hopes you figure it out” energy. The tool’s here, but the tooling isn’t; we’re still in the “click things and report back” stage.

Again, something that I expect will get fixed as these tools evolve.

And then Step 3: check the activity log. The debugging tool dutifully spits out a 401 error. Now, I don’t fully know what crime I’ve committed here: 401 means “unauthorized,” which basically translates to “lol no.” Something somewhere still doesn’t think I exist, or refuses to acknowledge my right to sign into my own app. So yes, progress: I have moved from “nothing is working” to “nothing is working, but now with logged evidence.”

I copy the log and paste it into the Emergent chat. Emergent goes, “Excellent debugging.” I immediately feel smug. It turns out I am extremely susceptible to positive reinforcement from AI.

It thinks for three minutes and then spits out another link. Fine. I click it. Repeat the steps. Same 401 error. Again.

At this point, both my patience and my credits are draining in sync. What’s really getting my goat is the credits part: I am literally reporting the same error, on loop. Why am I paying to say, “Hi, still broken”? And I really don’t want to pay INR 1600 more to spin up this simple app.

Nevertheless, I decide to try one more time. Same thing. Open link. Follow steps. Hit 401 error. Copy. Paste. Hope. Despair. Repeat. Emergent keeps generating new debugging links.

Finally Emergent tells me: “The Issue Is In The Backend.” Thank you sir. Didn’t realize that one.

Thursday, 9:55 pm

Screw log-in, I decide. This is Cursor PTSD all over again: layer on layer on layer, praying the problem magically fixes itself, except it doesn’t. And I’m not equipped enough (yet!) to unravel this. I never solved it on Cursor either, so why am I doing this to myself?

Fine. Break time. Let me at least understand what’s happening under the hood. What does the backend look like? What data is being stored? How are events being logged? I open the chat and ask, and after some coaxing (and patience I didn’t plan to spend here), it finally coughs up what I need.

Emergent seems to be very chat-first: I can ask for database details directly in the chat, and it’ll give me the details:

Everything, and I mean everything happens through that chat box. So instead of clicking around a dashboard or inspecting tables, I just have to literally ask the AI:

• “Hey, what’s in my database?

• What fields are you storing?

• How are you logging events?”

And to its credit, it does answer. It spits out the collections, the schema, the stored field all neatly laid out in chat

✅ The upside: Emergent does set everything up for you: backend, auth, database and you can literally chat with it to inspect your data. That’s cool. It feels magical. “Talk to your infra” energy.

❓ The downside: There’s zero visual database view. And when you can’t actually see your tables or data structure, you don’t know what you don’t know. You lose context. You can’t tweak fields, reorder schema, or sanity-check what’s happening under the hood.

So instead of clicking into a dashboard like you would with Supabase or Firebase, I’m just asking the AI questions and hoping it tells me the truth. Eventually, out of pure desperation, I keep begging it to show me something visual, and it finally spits out a link

Link to FitTracker Database viewer

This doesn’t feel like the real database but I’ll take what I can get. That said, I definitely preferred the Supabase setup. Being able to open a real dashboard and poke around gave me way more confidence (and control) than just trusting whatever the AI says is happening behind the scenes.

Thursday, 10:10 pm

Anyway, I now sort of understand how the database works, and I finally have a visual to stare at so that’s progress. I do not have the emotional strength to attempt log-in again - my nervous system has limits so I tell Emergent, “Let’s just forget auth for a minute and focus only on the AI-powered workout recommendations.” Honestly, I’m pretty sure Emergent silently whispered “thank God” at that point.

The moment I ask it to ignore Google OAuth, it happily spits out yet another link, this one bypassing login entirely. Perfect. Exactly what we both needed.

When I click on quick log-in, it immediately redirects me to the workout planning part of the page.

Emergent spun out the below:

For comparison, Lovable looked like the below:

As I had mentioned, some difference in default colour schemes, clearly Emergent is going for a darker vibe here, but nothing that can’t be tweaked with a prompt. Right now I’m more interested in seeing if the AI powered workout recommendation works.

Thursday, 10:16 pm

I select the muscle groups, click “generate workout plan,” and immediately start praying loudly. At this point, after the failure with the log-in feature, I contemplate quickly running and lighting some agarbattis.

It takes a little time to think, but eventually, it spits out a workout plan. I quickly skim through it. The structure and tone feel very similar to what Lovable + my own OpenAI key produced which makes sense, because it’s ultimately OpenAI under the hood here too. The difference isn’t the model, it’s the setup and platform experience around it.

An observation: when I bought a paid Emergent plan, I assumed the cost of using Emergent’s universal LLM key for OpenAI API costs would be deducted from there, but seems like Emergent is absorbing costs here

I expected to see my credits drop with every OpenAI API call, but they didn’t budge. So clearly, Emergent is eating that cost (up to some limit) just to let users test things. Much appreciated, genuinely.

I’m guessing they do the same with other third-party integrations too. For context, when I used Lovable + Supabase, I had to create my own Google OAuth credentials and Google asked me to set up a INR 15,000 autopay mandate as part of that process. I wasn’t actually charged anything, but still, that’s a big “excuse me?” moment when you first see it.

Here, Emergent abstracts all of that away. And since an OpenAI call is approximately about a rupee (~0.5 - 1 INR I assume) per hit, this is smart marketing on their part. Most people testing aren’t spinning up backend-heavy apps anyway, so capex wise, not a real burn for them.

So far: ✅ AI workout recommendations working.
Still unresolved: ❌ log-in.

I’d love to say I’m eager to debug that again, but at this point, my willpower and patience are pretty much done. One last thing to try, then I’m calling it.

Thursday, 10:31 pm

I don’t like this FitTracker colour scheme. The orange and black is really jarring. So I ask Emergent to change the look and feel to a lighter background, and just a brighter colour palette in general.

This already looks so much better. I test it a few times. It’s okay. Not perfectly smooth. The workout generator throws errors every now and then, so I keep refreshing like a maniac hoping it magically behaves on the next attempt.

Because there’s no real-time database view, every time something breaks, I’m basically blind. So I go back to the Emergent chat and ask it to pull logs and tell me what’s happening. It eventually comes back and informs me that the errors are because of OpenAI server issues.

But hey, it does work. Mostly. Reasonably consistently. At this point, that’s a win in my books. The app generates workouts, the UI looks decent, and nothing has combusted in the last five minutes. I’m taking the win.

And with that I shut the laptop, exhale deeply, and officially call it a day.

Conclusion: Emergent is a great “vibe prototype” tool, but the backend story isn’t there yet

1. Fast to spin up but only because I already knew what I was doing: It took ~2 hours to get a working app, but I skipped login and already had context from earlier experiments. The painful learning had been done earlier so this wasn’t a start from scratch experience.

2. Backend value-prop didn’t hold up: The value add to use Emergent over Lovable was: “Emergent will handle frontend + backend for you.” In practice:

   1. Auth was broken

   2. AI API calls were inconsistent

   3. Workout generation failed intermittently. If the core backend isn’t stable yet, the value of “backend handled by AI” collapses pretty fast.

3. Debugging is a black box: You can’t see the DB or logs directly. Yes, you can ask the chat for logs, useful, but I still prefer real-time database + logs I can inspect myself. But this is a personal preference, and not an Emergent problem to solve

Right now, it’s great for prototyping, but not for scaling You can absolutely build quick usable demos. But would I ship a real product on this right now? Probably not. We’re not yet at a point where AI app builders can reliably replace structured backend infra.

And Vs Lovable: not much difference: Functionally, Emergent feels like Lovable with a slightly different UX layer. And Lovable now has Lovable Cloud (auth + storage + DB like Supabase - essentially solving for problems that I’d talked about earlier - of having to handle a 3rd party database), so differentiation will be tough unless Emergent closes the reliability gap fast. Bottom line:

✅ Faster prototyping
❌ Not dependable enough for real world deployment
❌ Too early to hand backend over entirely to AI platforms

Bigger question: what’s the long-term moat for “vibe coding” platforms?

What I’ve been trying to understand is: how valid is this statement: “that these tools will change how we actually build.” Let’s be honest: they absolutely change how we prototype. Fast idea to UI turnaround, great for internal demos, alignment, fast iteration. Massive time saved for PMs, founders, and designers.

But do they change how we build products that scale? I don’t see it. Would I trust a vibe-coded backend for real-world scale, infra control, compliance, or performance? No. Not today. Maybe never. At best, these tools are training wheels + demo engines Great for: 0 to 1 mockups, feature pitches, founders testing hypotheses, and internal alignment + fast iteration. But once something has traction, you rip everything out and build on real infra. At max, this works in early days, but my first order of priority if I want to truly build a product out, would be moving away to my own independent backend set up, capable of handling the scale that I’m envisaging. So then I’d question the value of these tools even integrating with a backend - what’s the point, if these tools will only be used for prototyping?

Which leads to the obvious question: If the long-term path is migrating off these platforms, why bother with backend here at all? If these platforms are only for prototyping:

• Backend integration feels overbuilt

• “Managed services” here are nice to have, but not must have

• What’s the point of auth flows you’ll never trust in production?

The platform’s ambition (full stack “we host your app”) doesn’t match real-world willingness to trust it. And once you accept that, they are frontend prototyping tools - not app platforms. And in that case: The focus should be UI/UX scaffolding, design-to-code pipelines, component libraries and easy export to real frameworks. Backend feels like unnecessary complexity. And because they’re fundamentally LLM dependent wrappers, there is limited moat.

And yes, the easy rebuttal here is that “everything is a wrapper.”

Perplexity wraps LLMs, LLMs wrap Nvidia chips, and so on. But there’s a difference: wrappers that sit on top of foundational technology and create new capability or distribution survive. Perplexity adds retrieval, ranking, a web-scale knowledge layer. Nvidia unlocks compute to intelligence. But these vibe-coding tools? They don’t unlock anything new, they simply consume LLM capability and put a UI around it. And the problem is that the LLMs themselves are already moving up stack into exactly this territory: English to code, which then lead to running apps, debugging, infra setup, agentic coding. These platforms aren’t like Perplexity vs OpenAI; they are a thin UX layer on something the base model is actively absorbing as a native function. The issue is not that they’re a wrapper, the issue is that they’re building in a space where the core model is rapidly integrating across the stack and absorbing the value layers

Which then brings me to the next point: if the next wave of apps is not going to be built on these platforms, then what exactly is the point of these platforms?

1. They’re fancy prototyping studios, not real build environments. Cursor and Claude Code help developers vibe-code; these no-code platforms help you prototype vibes. Tools that matter long-term will always be developer-first. Everything else is UI over GPT. And, with current valuations, it feels like we’re overestimating the TAM massively, or rather, not the TAM, but the willingness to pay massively.

2. These tools don’t replace expertise: They just remove the grunt work for people who already know what they’re doing. They make good engineers faster and sharper, not obsolete. If you lack fundamentals, these tools may actually accelerate you into bad. The real advantage isn’t in prompting, it’s in knowing what to ask, how to interpret the output, and, in my opinion, this is most important - when to push back because something feels off.

3. These tools are “English to code,” but only if you already have a clear, granular understanding of what you want to build. The skill that matters most now is clarity of thought - the ability to break down a problem, define specs precisely, and think structurally. If you can articulate the problem well, LLMs are pretty good at turning that into code. For students or early-career folks, learning how to use platforms like Lovable, Emergent, or Claude Code is useful, but only alongside developing core reasoning and problem-solving skills. The real edge is not knowing the tool, but knowing how to think. The value of critical thinking has never been higher.

4. Instead of pushing AI top-down across orgs and expecting every junior employee to suddenly “work smarter,” I’d actually argue the bigger unlock lies at senior levels, where there is already depth, context, and judgment. I’m not advocating for grunt work for the sake of it, but there is real value in repetition and time spent in the trenches. That’s how clarity is built. That’s how intuition is earned. The tension today is that junior employees are naturally more eager to adopt new tools, but often haven’t seen enough problems to guide an LLM through ambiguous situations. Meanwhile, leaders, the ones who can ask the right questions and frame the right problems, are often under using these tools. The balance we need is not “AI everywhere,” but “AI where expertise exists,” paired with structured learning time for younger talent to build that expertise, not bypass it.

5. LLMs often lack deep system context, and that’s exactly where real engineering expertise comes in. In many ways, the bar for engineers has actually gone up. Traditional engineering meant understanding the problem, translating it into requirements, building, testing, and deploying. Today, only one part - the act of writing code has become faster with LLMs. And realistically, that’s maybe 20% of the job. Everything else still requires judgment, architecture thinking, context, and rigor. In fact, because AI-generated code can introduce edge case errors or some invisible complexity, the time required for debugging and testing often increases. So yes, LLMs accelerate execution, but they also demand sharper engineering intuition, deeper problem-framing skills, and a stronger grasp of systems level thinking. For people entering the industry, it’s important to understand that LLMs only assist with one slice of the work, which is turning requirements into code. Which means the real leverage now lies in getting the requirements right.

6. This doesn’t mean programming languages are going away, or that you can afford to not understand them. When high-level languages arrived, a lot of developers stopped worrying about what was happening under the hood, and they got away with it because the systems were deterministic (aka - predictable and reliable). And even then, the people who did understand the low level stuff always got paid more.) With LLMs, you might think you can just give instructions in English and skip the technical depth, but these are non-deterministic systems - they’re random and unpredictable. The same input may give several different outputs. You still need to understand what’s being generated, why it works, and when it doesn’t.

Individually, LLMs are the engines powering this next wave. Everything else layers on top of them. Tools like MongoDB, Supabase, or even Claude Code are genuinely useful building blocks on their own.

But platforms like Emergent, Lovable, and Bolt still feel fundamentally like prototyping environments, not places where real, scalable products will be built and operated long-term.

If a company actually wants to ship something meaningful, it will still pick the primitives: Supabase, Mongo, its own backend stack, and direct LLM integration. And LLMs are only going to get better. Over time, they will absorb more adjacent capabilities, things such as UI generation, database scaffolding, backend logic, deployment flows. Which makes the valuations of these “vibe-coding” platforms feel stretched, given how exposed they are to LLM expansion risk.

Vibe coding - market snapshot

• Lovable: Raised $200M; $1.8B valuation (2025); reported 30–50% drop in usage/MAU across public forums and anecdotal reports. In July 2025, according to TechCrunch, it reported an ARR of $50M.

• Bolt: Raised ~$100M; estimated $700M valuation in 2025 (sources not fully verifiable, but directionally aligned with Lovable). Hit $40M ARR in 2025

• Emergent: Raised ~$30M (Series A, 2025); valuation unclear, but some reports say $90M. It claimed $15M ARR in 90 days, but like all stats regarding ARR, I’m a bit skeptical, when you take take stats and annualize. As I mentioned before, with vibe coding apps the true revenue and usage actually shows in M3 / M4, when the users who’re just paying to try it out (like me) churn out, and the actual base remains.

From a user standpoint, these tools are useful, but primarily for fast prototyping, experimentation, and internal alignment, not durable product development.

1. Razorpay launched Agentic payments on UPI through OpenAI - allowing users to make payments at the Global Fintech Fest in 2025

2. Google’s Agentic Payment Protocols (AP2), which allow mandates to be stored in a “trust layer” which is AP2, and in real time, compare payment requests to stored mandates for payment processing were launched in September 2025

3. The OpenAI & Stripe Agentic Commerce Protocol launch, to integrate “instant checkout” within the ChatGPT interface in September 2025

4. Visa launched the Visa Trusted Protocol for agentic commerce, which allows agents to initiate payments & reference stored credentials (like tokenized cards) on the end users behalf, without asking for consent again in October 2025

Now, the end goal of all these protocols are the same: allow the agent to initiate and process payments on behalf of the customer. But the ways that the players have chosen to implement these are slightly different.

At the crux: these are the following questions / pain points that these players have all tried to solve:

Commerce within the LLM Chat: The thought process being that if all commerce & shopping is going to happen on the LLM chat, then why should payments be any different, and the experience should be: to provide a way to initiate and complete payments within the LLM Chat, by simply “sending a request in the LLM chat.” Cool. So then, just from a first principles perspective, a few things need to happen:

1. The order request is placed through the LLM chat, which has provided catalogue level details etc through the merchant MCP (Model Context Protocol for the uninitiated - a set up standardized APIs & endpoints that the LLM can use to communicate with the merchant).

2. After the order request is placed, this order request needs to be converted into the merchant “cart,” and the merchant’s payment processor needs to create an Order ID, and make subsequent API calls to the merchant’s payment processor. So, now for this, there needs to be some sort of translation layer that enabled the order request to be converted into a cart order and a payment request

3. After the payment request is created, the payment method needs to be selected, and the payment needs to be authenticated. Now, the method selection is easy, but payment authentication is where the crux of the issue sits.

4. Now, if 2FA is not mandated, then it becomes a 1 click payment, where stored credentials saved at the merchant can be referenced. So here, some sort of permission or flow is needed, where the LLM chat hits the merchant MCP → which creates the payment request → to authenticate the payment, the stored credentials are referenced through the merchant or some sort of flow. This is a little more agentic, because it requires limited human intervention

5. If 2FA is mandated, then it becomes tricky, because there is some entry that the end customer needs to do: either through biometric credentials, or through PIN, or through OTP, or something else. And entering these credentials into the LLM chat is something that is NOT recommended. In fact, even when you’re setting up backend auth for your merchant services, it is recommended NOT to share your private key with the LLM, just the public key, that it can use to reference the private key of the service that you’re using. So then, this will require some sort of native / embedded SDK flow, or a redirection, and this is not something that the agent can add, so human intervention will be required.

Below is the flow of authentication for card payments & UPI payments. In India, 2FA is mandated, so card payments have the card itself & the OTP. While UPI payments have the device & the PIN.

Authentication in card payments → 2FA means OTP entry is needed

Authentication in UPI → PIN entry is required which is a user input at every transaction

So immediately, the thought that comes to mind is that flow works for countries like the US and EU where 2FA is not mandated. And as a refresher: 2FA means that the user needs to authenticate 2 out of the 3:

• Something you have: Tokenized card, OTP (device). Something you have is the easiest, where you can used tokenized card details and process the payment.

• Something you know: PIN / Password / CVV

• Something you are: Face ID, fingerprint

So, now, lets unpack what is actually happening in the four launches that I called out in the above flow:

1️⃣ Razorpay launched AI Payments on UPI through OpenAI & Claude at GFF 2025

Original link to Razorpay launch video here

Let’s unpack what is happening in the above video.

1. The user asks Claude to reorder their protein powder from Bigbasket. I’m assuming here, the LLM (Claude) is speaking to BigBasket directly. So I’m assuming Claude has integrated with BigBasket (either standalone or through some MCP gateway) in order to call its APIs

2. Claude finds the BigBasket order and passes the payment request

3. The payment request is sent to Razorpay where Razorpay places the order using UPI Reserve Pay. Again, this is done now using the Razorpay MCP. And the payment is successful.

Some takeaways:

1. There doesn’t seem to be any authentication happening here, just that the payment has been done through something called UPI Reserve Pay. So I assume the authentication has already happened somewhere.

2. UPI Reserve Pay is similar to UPI Autopay, in the way that it needs to be pre-authorized. But where it is different is that it sets up a payment block, versus a fund transfer instruction in Autopay. UPI Autopay is a one time mandate registration for recurring debits.

   1. UPI Reserve Pay is a way of paying where you can do the authorization one time, and the money gets blocked in the account to use whenever the merchant “captures” the money. This is different from the case of UPI Autopay, where there is a standing instruction to transfer funds, the funds aren’t blocked. So in UPI Autopay, there is risk of failure, since at the time of mandate triggering, funds have to be present in the account. UPI Reserve Pay is more like saying: “Hey - block INR 15k in my account, which I’ll use to spend on a merchant - lets say Blinkit. And authorize this at the time of set up. So when the payment is triggered on chatGPT using UPI Reserve Pay, the money is debited from the funds that were blocked earlier. the UPI Reserve Pay seems to be a combination of UPI Autopay (in the case of mandate registration, which requires authentication at the time of set up), and Single Block Multi Debit, which allows funds to be blocked at one time, and multiple debits to happen from it. So this answers the question in point 1: authorization has happened for this payment already.

✅ Takeaway: Reserve pay is pre-set up at the merchant, and at a merchant level. So for the user to use this method to transact through a LLM chat, the user first needs to go and set this up at the specific merchant, against which debits can be made. So this only makes sense for merchants you know you transact through regularly, because then its worth the effort of going and setting this up. And remember, setting this up through the LLM chat, in India atleast will be tough because of the 2FA requirement, and the constraint of UPI payments happening only through the mobile (embedded CL in the app which powers the page that does PIN entry).

❓Open question: If this is a merchant I user frequently, then why not just use the merchant app, especially if I’ve gone through the effort of setting up reserve pay for it? Why go through the LLM chat? What AI does is personalizes experiences, especially if the ask and the question is ambigious. I guess we will see how customer behaviour evolves.

Note: Think of MCP as a translator layer, it allows the LLM chat to call the 3rd party APIs seamlessly. Once a 3rd party has integrated with the MCP, it has to register with the LLM, so the LLMs know what to call, to initiate any action on the merchant. And, there will be 2 layers of MCP. If we decouple the experience into shopping and payments, shopping will require the merchant MCP for catalogue access. But payments will require the merchant x PA MCP (assume Razorpay, Cashfree). I’m assuming the MCP here will be merchant specific, but PA hosted, since the PA will be processing the payment.

Just as a side note: there are interesting things that will be built on the orchestration & API standardization side to support agentic commerce. Example:

1. A MCP x Payment orchestration layer: Today payment orchestration happens to select the best performing PA. Now, with the MCP layer in the mix, You can route at the MCP level to whichever PA has:

   • Highest success rate for that payment method

   • Best experience for a given merchant segment

   • Least latency / timeout issues

Example: Agent → MCP Orchestrator → Best performing PA MCP endpoint → Merchant

2. One integration with a gateway layer = integration with all LLMs: So if you’re a merchant or a PA, and you want your store or payment rails to work with all these platforms, you’d have to build for OpenAI’s MCP, build again for Claude’s MCP, and then again for Google’s MCP. That’s multiple builds, multiple formats, and a huge operational load. Enter the gateway layer. This is a single tech layer that sits between the LLMs and the merchant/payment ecosystem.

   • Merchants and PAs integrate once with the gateway.

   • The gateway connects to all the different LLM MCPs.

   • It handles translation, standardization, and routing automatically.

   So whether the request comes from OpenAI or Claude, the merchant only sees one standardized format. And they don’t have to rebuild every time a new LLM or MCP variant appears. But that’s a separate topic.

2️⃣ Google Agentic Payment Protocols Launched (AP2) for mandate based agentic payments payments

AP2 doesn’t move money. This is important to understand. Like it was with the AI payments launch on UPI, it is essentially a mandate, hiding behind AI. What Google has done is created another layer that allows one time mandate set up, and then payment / order instructions translation & comparison against the mandate.

1. So the agent (Claude, Gemini ChatGPT, etc.) gets the payment instruction. It then sends this to → AP2. Note, at the first time set up, there has been some sort of auth, which creates, and stores the mandate at the AP2 layer. So, when the payment instruction comes in, it is mapped against stored mandates at the AP2 level, and then executed, or not executed.

2. Then AP2 stores and manages these mandates, like a vault of agent-managed instructions. When the trigger conditions are met, it passes that instruction to the merchant and PA, which executes the actual payment, which then becomes your regular money flow, where it calls either the network, or the UPI APIs which first check the auth that had been set up, and then process the money flow, by sending instructions to the issuer and the acquirer banks.

This is how I’m assuming it’ll work in real time for a fully autonomous payment

• The user has already consented to a standing mandate (e.g., “up to INR 2,000 monthly for reorders from let us say BigBasket”), using the PIN, or OTP or something else to authenticate.

• This was pre-verified once, during setup (AP2 recorded the explicit consent + PA validated it).

• When the condition is met, i.e, I reorder from BigBasket, or from the LLM Chat, which is connected to my BigBasket Account, I don’t need to authorize the payment again, since the mandate is set up. The order goes to AP2, AP2 then checks the instructions, and makes sure that they meet the conditions of the mandate. When the mandate is triggered, then it flows to the PA, which then executed it by sending relevant instructions to the network, the PSP, and so on. And then the payment executes without real-time user intervention.

➡️ User sets Intent Mandate which is stored in AP2 (this is the mandate set up + auth layer) ➡️ At the time of shopping, the LLM/Agent receives instruction, this could be chatGPT, Claude etc. ➡️ The LLM chat sends the instruction to AP2 ➡️ AP2 validates instruction against Intent Mandate ➡️ A cart mandate is created for that specific transaction which references Intent Mandate ➡️ Payment Mandate created which references Cart Mandate ➡️ The payment instruction is sent to the payment Aggregator / PA which is then sent to the Issuer Bank (which uses the creds / some sort of token I assume from the payment mandate to verify that this is a verified mandate) ➡️ Payment executed ➡️ Confirmation sent to AP2 to LLM and to the User

So this is similar to UPI Autopay (or rather UPI Reserve Pay, if funds are blocked) or Card on File standing instructions, except here the mandate is stored by the AP2 agent.

AP2 Implications for PSPs, Card Networks, and Banks

While the flow of money remains the same, there are certain things that are fundamentally changing. There is essentially a new authentication step here, where the stakeholders in the current flow - the PSP, the PA, the network, and the issuer and acquirer banks need to recognize mandates that are set up using the AP2 protocols as valid and compliant. So essentially:

That means:

• PSPs (like GPay, Razorpay, Stripe) must update their systems to accept AP2 payloads. Card networks (Visa, Mastercard) must support this in their frameworks, so a transaction initiated via an AP² agent still passes risk and auth checks (this I assume is happening, since both Visa and Mastercard are two players that are on this protocol as per Google). Banks / issuers must understand these as “authorized mandates”. The AP2 credential must be something that banks / issuers recognize as a valid authenticated instruction.

✅ Takeaways: AP2 introduces a new “trust layer” that existing payment systems must natively recognize as equivalent to direct user authentication, and thus the requirement for existing systems to recognize this. Unlike the OpenAI x Razorpay integration, which is a payment block set up and authenticated at the merchant, AP2 is a separate layer that stores the mandate, and in real time the payment request is mapped against the AP2 stored mandate. But all stakeholders have to be integrated with AP2, and recognize it as an authority

Google launches UCP (Universal Commerce Protocol) in 2026

Google also launched UCP - the Universal Commerce Protocol, which enables checkout players to expose standardized checkout states which reduces variability in the error states, and edge cases across merchants. In a nutshell: the UCP lets an agent “ask for payment” in a standardized way, while Adyen actually moves the money, without the agent ever dealing with UI, credentials, or edge cases.

This isn’t ‘AI’ but its the plumbing that will enable AI assisted commerce, since it makes it easy for agents to communicate with the payment layers, in a standardized fashion. To make it into a simple example: imagine a customer has invokes an agent to pay.

Now, for this agent to pay across different merchants, it has to speak to different UI, and different payment providers and aggregators. And different PAs for example, will have different states.

• Razorpay uses created, authorized, and captured. Example below:

• Stripe uses requires_action, and succeeded

• Adyen uses yet another naming convention

That’s where the Google UCP comes in

• The customer invokes an agent

• The agent calls the merchant to start the payment action

• The merchant exposes a UCP endpoint across payment providers for a standardized template for the agent to interact with. Earlier, the agent would have to solve for different edge cases across payment providers (Stripe / Razorpay being two examples)

• The Payment Aggregator (Adyen / Stripe) sits under the UCP (unchanged), which takes care of the actual money movement.

The flow is as follows: Agent → merchant’s UCP → AP2 → UCP returns response to agent, since AP2 is another method of authentication

The agent → merchant → exposes UCP endpoint → agent calls AP2 as a method → AP2 checks for standing mandate, authenticates and authorizes the consent for the payment across stakeholders and returns response. So essentially, Google has been putting in place the pipes to promote agentic and autonomous (well somewhat) payment flows. The AP2 was the trust layer, and now the UCP is the distribution layer sitting on checkout.

MCP gives one integration layer for the merchant, while UCP removes complexity of interpreting multiple payment states from different providers

The MCP acts as a single, agent-facing layer that enables LLMs or AI agents to initiate payments or interact with checkouts without integrating with each merchant individually. However, the MCP still needs to talk to multiple merchants, each of which may use different payment providers (Razorpay, Stripe, AP2, Adyen, etc.) and have slightly different internal flows.

This is where UCP comes in: it standardizes checkout and payment states across merchants and providers, so the MCP only has to call each merchant’s UCP endpoint and interpret a small, consistent set of states incomplete, requires_escalation etc). In other words, MCP handles routing and agent-facing API, while UCP ensures the underlying complexity of different payment providers is hidden, making one integration per merchant sufficient for the MCP to support many agents.

3️⃣ OpenAI & Stripe ACP Launch (Agentic Commerce Protocol)

The ACP here, like the MCP is a standard protocol that allows the agent, which in this case is OpenAI, send details directly to the merchant backend, which then speaks to Stripe, which is the payment processing layer. This also standardized authentication: how the agent identifies itself etc, so merchant’s need to create one standardized endpoint, and accept 1 standard way to authenticate the request, without having to do integrations for each LLM.

So, if you recall, in the earlier section, we talked about how there needs to be a way for the “order” placed in the LLM chat, to be translated into a “payment processing request” to Stripe in this case. The ACP is the layer that does this.

I’ve chalked out the steps that I’ve pieced together basis the OpenAI developer docs & the Stripe developer docs, and added the source material for anyone, if they want to inspect for themselves.

1. The user can access the merchant catalogue through the LLM chat: OpenAI (LLM chat) calls the Merchant MCP to fetch catalogue data. User browses options and selects an item (e.g., a blue pair of pants). Source: OpenAI ACP docs, Merchant MCP / Catalog

2. The user creates an order through the LLM chat: User says: “I want to buy this pair of pants.” LLM communicates with Merchant Backend via Merchant ACP to create an order and initiate payment request. Source: OpenAI ACP docs, Order Creation via ACP

3. Merchant backend creates order: Merchant backend sends order/payment request to Stripe (PSP / Payment Processor). Stripe has stored tokenized payment credentials of the user (assuming prior checkout or saved card). Source: Stripe docs, Delegated Payments

4. User initiates payment of the order: The user then sees the final order, along with the price and tax, and says pay now, in chatGPT

5. Payment authorization happens through a “delegated payment.”: Merchant ACP instructs Stripe to create a delegated payment, the payload contains a single-use token, which is scoped to specific order, merchant, and amount (e.g., INR 500), and limits potential exposure and misuse. Delegated payment token is returned to Merchant Backend. Now, it took me some time to understand this whole delegated payment concept, but unlike a mandate, this is created on the fly, and is a way of limiting exposure, by creating a token, to authorize payments for that specific order, on that merchant, for that time. Source: OpenAI ACP docs, Delegated Payments

6. Token ensures only the defined amount, merchant, and payment method can be charged. Merchant backend passes token to Stripe for processing. Source: Stripe docs, Delegated Payments Validation

7. ChatGPT then communicates with the merchant backend via the merchant ACP, which communicates with Stripe to create a “delegated payment.” This is the flow that is new here. The delegated payment creates the max payment limit of whatever the transaction amount of the order is, lets say INR 500. Now, Stripe also holds the tokenized payment details of the customer (assuming this customer has previously used this merchant, and saved their creds). The concept of the delegated payment here is to limit the exposure to a single payment, merchant & order and misuse. It’s like giving authorization for a very specific use case that limits exposure This delegated payment token is returned to the merchant backend, which validates the token, and then sends it to Stripe for processing.

8. Now, if there is no 2FA requirement, then the tokenized card is enough, and Stripe processes the payment instantly (which is your issuer + acquirer flow). If there is a 2FA requirement, then Stripe will trigger the OTP / PIN step, which can happen through some sort of embedded / deep link, or a secure webview.

   1. No 2FA: Stripe processes the payment instantly using sthe token.

   2. 2FA required: Stripe triggers OTP/PIN step via: embedded SDK, a secure webview, or a deep link from merchant backend. This is like a native payment today, when you enter your OTP on a native PA flow. Source: Stripe docs, 2FA / Strong Customer Authentication

9. Stripe confirms payment → Merchant Backend updates order status → LLM chat notifies the user of successful payment. Source: OpenAI ACP docs, Payment Confirmation Flow

✅ Takeaways: Here, the merchant account of the user has to be connected to OpenAI, and tokenized card details need to be stored at Stripe. Now, I did go through the OpenAI and Stripe documentation, and what the documentation says is that the delegated payment payload is generated for that specific transaction, so I assume that there are no pre-set rules required that Stripe / the merchant checks against, unlike UPI Reserve Pay, where a payment block is created, or like AP2, where a mandate has been created. So it is more autonomous in that sense, but the blocker here is that in SEA regions, where 2FA is a must, unless there is a mandate or a payment block set up in advance, it will never be truly autonomous.

❓ Agentic commerce for me in this way seems far more likely. Here’s my thought process. What LLM chats have done is given that “exponential experience, or as Kunal Shah postulates - the Delta 4 experience” for shopping, by providing a personalized, chat interface across different marketplaces (eventually). If you decouple the shopping experience, from the payments experience, the payments experience itself is fairly seamless now, with all the innovations around 1 click payments, PIN / native OTP entry and so on. I don’t know the additional value add of completely autonomous payments, especially if it comes with the additional headache in some cases of setting up a mandate. All I want is a way for me to make a payment or initiate the payment through the chat → and as a user, I’m more comfortable NOT sharing my PIN / OTP / secure details with the LLM. Using secure creds saved at the payment layer seems like a secure experience + coupled with on the fly payments.

❓Another point in my mind is that: everyone has their phone with them at all times. Even if a link is generated, which, basis the order placed, sends it to your payment app of choice, or a link to your whatsapp chat, through which you can pay through a secure interface, that also seems very likely.

4️⃣ Visa Trusted Agent Protocol (VISA TAP) for Agentic Commerce

Visa launched the its trusted agent protocol (TAP) in October 2025 to enable agentic commerce using stored / tokenized creds

1. The user can access the merchant catalogue through the LLM chat: OpenAI (LLM chat) calls the Merchant MCP to fetch catalogue data. User browses options and selects an item (e.g., a blue pair of pants).

2. The user creates an order through the LLM chat: User says: “I want to buy this pair of pants.” LLM communicates with Merchant Backend via Merchant ACP to create an order and initiate payment request, and sends the intent to the merchant app, which is registered as a Visa Trusted Agent.

3. Tokenized Card Retrieval (via PA). Merchant app requests tokenized Visa card from PA layer if stored there. LLM never accesses credentials directly. And of course, the PA also needs to support Visa TAP, and support in payment processing

4. Merchant Trusted Agent references stored credential: Merchant app looks up the user’s tokenized Visa card (saved at merchant checkout). Merchant app instructs Visa TAP to validate token + agent authority. TAP ensures only this merchant/agent can use this token.

5. Payment Authorization & Execution

   1. If 2FA required: Visa TAP triggers OTP / PIN / biometric via merchant app.

   2. If no 2FA required: Payment authorization happens instantly using the stored token.

6. Visa TAP communicates with the issuer bank to authorize and charge the card, PA handles settlement and routing

❓Again, this is just basis my understanding of the developer documentation, but this I assume will happen through some sort of delegated tokens, like Stripe ACP. Some open questions I have, which I couldn’t really figure out is how will the LLM know that the user has a stored Visa card? This protocol makes more sense to me at a PA layer, so that the customer can also choose which method to pay with, assuming all methods have been tokenized and stored at the checkout layer. Link to Visa developer docs here

Adoption of agentic payments really depends on how user behaviour evolves: I could argue both sides of this.

There are pros and cons of all approaches. My own perspective is: agent initiated payment is a must, and hence the need for protocols such as ACP & Visa Trusted Protocols, for secure payment initiation via the agent. But does it need to be autonomous? I’m leaning towards a no.

✅ The pros: if the hypothesis is that the shopping experience moves to LLMs, then it makes sense that you want the payment to happen there as well.

→ So payment initiation, sharing the context of shopping from the LLM to the merchant, and then creating an order via the LLM using merchant MCP & ACP. Yes, that makes a lot of sense. But I’m not sure if it’ll ever be truly autonomous, and I’m not sure if end users will even want it to be 100% autonomous. I do disagree with the concept of “invisible payments,” and my view is that friction is a feature here.

❓I’m still on the fence if the pre-set up payment block or the mandate style of agentic commerce will actually take off, in the case of AP2, or UPI Reserve Pay + OpenAI

1. This UPI reserve pay, or fund block will always have to be set up at a merchant level. Now, in the future, one may be able to set this up through the LLM Chat, through some sort of native experience, but even if you’re setting this up, this still requires one time auth, where you’re entering your PIN, or verifying using card details / OTP. And we may be still some ways away from the native use case

2. Mandates / SBMD can right now be set up at only a merchant level. So basically, these rules will have to be set up for each merchant. And then, it only makes sense if you transact from the same merchant multiple times in a fixed period: such as big basket, zomato etc

Also, while I’ve seen a lot of folks talk about agentic payments = invisible payments, but in financial services, friction isn’t always a flaw. Sometimes it is a feature

I remember speaking to a certain TSP that specialized in phone number authentication. And one of the tools that it provides are APIs for silent mobile verification. Which essentially allow user verification through APIs at the backend, instead of OTP verification. What I understand was, that the process is so seamless, that it had a negative experience on the users, where the user felt that the TSP was not doing rigorous enough checks. Finally the TSP actually had to add a few seconds of buffer at the time of log-in, so that the user was not taken aback at how seamless it is. And that is just for log-in.

And this is not a new idea. This is something that has been validated through multiple surveys. In fact, the Journal of Financial Services - The future of payments (2025) talks about “intelligent friction” where sometimes friction is not a flaw but a feature. And sometimes, taking that extra time to validate and authenticate reassures the customer, that all steps are being taken to ensure the transaction is not fraudulent.

Excerpt below from the Journal of Financial Services - The future of payments (2025)

Assuming AI / Agentic payments do take off, and they take off in this mandate based way, there are other additional pieces in play. There are multiple stakeholders in the current payment flow. And for this to take off at scale, changes need to happen at each step, which is what Google’s Agentic Payment Protocols are attempting to do.

While these AI payments have been piloted, if it was only a fintech problem, I’d be a lot more bullish. But this also requires system level changes to recognize the authority of new agents in the payment flow

I’ll give some examples:

👉 In the UPI Reserve Pay flow, this sort of payment works for cards - travel bookings etc. But this sits in the card management system. The debits & the credits from the savings account of the bank, sits in the core banking system. And currently, the bank CBS is not set up for this sort of payment at scale, along with other things such as reconciliation, fund flow etc. A simple example is the whole BNPL wave that hit India about 5-6 years ago. Bank systems, and the software providers they used were never set up to handle scenarios such as “grace period,” or “partial cancellation,” which were very obvious needs for consumer loans. Which resulted in a lot of manual handling.

👉 In the AP2 Mandates flow, the mandate is being set up and stored at the AP2 layer. So banks, and payment processors have to essentially recognize the validity and the authority of the AP2 mandate to actually process with processing the payment. So, again, changes required here

Until the system level changes are done, this may always stay just at a pilot stage, and never scale. I’ve talked about the resistance and the speed at which banks make changes more in this piece: #64: Innovation at the edges, stagnation at the core: why India needs neobanks

There are other issues here. Let us assume that somehow, this mandate flow works out in agentic commerce. To be able to truly make this mandate stuff work in an agentic way, you need to be able to set up it for a use case, or at some category. Setting it up at a per merchant basis, is going to be super time consuming. Example: I want to spend INR 10k on groceries every month. To enforce this, you basically need:

1. Merchants mapped to a category, i.e. MCC code

2. This mapping needs to exist somewhere centrally - example, at a network level, or at the agent / App level, so that in real time, the mandate can be checked to see if it fits the bill. And this mapping needs to be exposed as a database or through some APIs for real time checks.

3. The merchant to MCC mapping is constantly updated, and enforced, there are a lot of issues where merchant to MCC code is not mapped correctly, which can lead to all sorts of issues. This is still an issue at big PAs.

So regarding agentic payments, I have 4 questions:

1. How will customer behaviour evolve - this is a wait and watch: Is this experience truly head and shoulders above the current e-commerce experience. My view is: if we decouple → shopping is a yes, and payments is still a maybe. Using deep links, payment links, or even a redirection to enter the final payment, as long as the context of the order is shared should be enough, but that is my personal view. At the stage that this is, it is still subjective

2. Ease of use - mandates may bring additional set-up friction, is that off-set by the “autonomous” experience once mandate set up is done? Again, this remains to be seen. Setting up mandates at a merchant level seems cumbersome, and I’ve already explained some gaps in the “mandate set up by category” concept

3. Are “invisible payments” truly a need, or is friction a feature in payments? Again, while it is important to make payments as seamless as possible; no one wants to wait 10 minutes to pay, I still feel that that extra layer of authentication adds to the “trust” factor by a customer. The feeling being - hey there are additional steps so is is more secure.

4. Are current systems set up for agentic payments? I’m not talking about a flow such as UPI Reserve Pay here, which is happening via NPCI, an existing stakeholder. I’m talking about AP2, or even the OpenAI x Stripe ACP, and the Visa Trusted Protocols. There is a new authority at play here, be it AP2, with the mandate instruction, or Visa, with an authorized agent initiating payment. At the end of the day, it is the issuer that is approving, networks & PAs just play a role in facilitating. And, its not fintechs I’m talking about It is banks. Bank systems may be okay for a pilot, but are they okay to enable this at scale. I’m not certain.

From a banking systems perspective, for truly autonomous payments, alternative rails like stablecoins could offer a more efficient foundation for the next-generation AI-driven money movement layer.

We’ll dive deeper into this in the next edition. Stay tuned!

You can check out the earlier editions in this series here:

1. Part 1: [#27] Is it a race to get licensed?

2. Part 2: [#37] Having multiple licenses as an Indian fintech seems to be key

3. Part 3: [#54] There are very few “1 license players anymore” - PA seems to be the most popular

4. Part 4: [#63] It’s not just about license aggregation, it’s about stack specialization

5. Part 5: [#69] Payments is just the first step in going full stack

If you’ll notice, what I’ve tried to do is constantly track the ever evolving fintech landscape in India, and see if there are trends that can be spotted, which can provide some insight into the future of this space, not just through current data, but through data trends over months. I wrote the first edition of this back in August 2024, and a year later there is a lot that has evolved.

But first: let’s look at the updates from July 2025

A quick snapshot of what’s happened since the July update - which was the Part 5 edition:

• Blackbuck picked up a PPI license in July 2025.

• ABFL, DMI Finance (Appnit) and Policybazaar (PB Pay) - all moved from “PA application in process” to “in-principle authorisation” this year.

• PayPal upgraded from “application in process” to in-principle approval for a PA-CB.

• Easebuzz is trying to get to scale in cross-border, now partnering with Xflow while its own PA-CB application is still in process.

No notable new players getting into this space. It seems like fintech in India, atleast when you look at it from “players in the market” perspective is saturated, and it is now existing players which are getting their license status updated - this is in terms of PA licensing, and possibly UPI App certification. Where I do expect new players to come in is on the PA-CB side, for cross border money flow, and on the NBFC side, as more consumer & merchant facing fintechs want to get into the lucrative business of lending on their own books.

What has come out quite clearly as I’ve tracked this space, that becoming a full stack fintech is where the table stakes lie now. This is what enables players to 1) give themselves optionality and also 2) have the most control over the stack to boost success / approval rates, or whatever the core metric of that offering is.

The way I’ve tried to define it is that there are two kinds of full stack: Going deeper into the method is one AND going wider into different offerings is the other

✅ Owning the method stack - with the bank infra, switches and so on

1. In UPI: not just integrating with banks, but running your own switch, building a UPI app, and owning the payee/payor side.

2. In cards: not just routing transactions, but going deeper into authentication — tokenisation, MPI, DS, 3DS rails, basically owning the OTP verification & authentication step. And obviously other methods as well, I’ve just used cards & UPI as an example as the most popular types of payment methods (not counting affordability)

3. In both cases, it’s about performance. The less you rely on third parties, the tighter your control on latency, debugging, uptime, the better your chance to win merchant volumes. And since many merchants are using payment orchestrators, that route basis performance, even a few bps in success and latency matters.

✅ Owning the license stack

This is the more strategic play. PA-CB, NBFC, broking, UPI app certification - each unlocks a new adjacency.

1. Slice with its SF bank. BharatPe with Unity. Paytm with broking, PA, UPI.

2. And newer plays like Cashfree going deep into cross-border with import/export PA-CB licenses.

The logic is simple: payments margins in India are a few basis points at best. Profitability lives in cross-border flows and credit. Banks are still doing the heavy lifting, but fintechs are layering on distribution, UX, and speed. The optionality of licenses is what gives them room to build adjacencies that actually move the needle.

One truth has become clearer over the last 12 months: just doing domestic payments in India will not make you a sustainable business. The future belongs to players that build full-stack infra + licenses, and then branch into lending, wealth, and cross-border.

Let’s take a quick look at some of the payment players currently in the market, and what they’re doing

1. Easebuzz: going international

Easebuzz is one of the few standalone PAs still pushing hard. They applied for a PA-CB license earlier this year, and raised a $30M round in April ’25 led by Bessemer, largely to fund their move offline (QR, POS, etc.).

On paper, they look solid: FY25 revenue of ~INR 650 Cr, net profit of INR 25 Cr, and $30B in GTV. But here’s the interesting bit: INR 650 Cr on $30B in GTV works out to ~25 bps. That feels too high for net revenue in payments.

Here’s why:

• In cards, the issuing bank keeps ~1.5%, networks ~0.2%, acquiring banks ~0.2%. That 0.2% is split between the PA, orchestrators, switches, etc.

• In UPI (60%+ of PA volumes), there’s effectively no MDR.

• Which means a PA’s net revenue usually sits at just a fraction of that 0.2%. It’s actually even less due to the UPI weightage

So for Easebuzz to show a ~25 bps take rate, two possibilities:

1. This is gross revenue (i.e. counting the full MDR before payouts). In gross revenue, the entire 2% is counted as revenue. In net revenue, this is the actual amount that the PA keeps AFTER paying everyone, and handling kickbacks etc, which is a fraction of a fraction: some x% of 0.2%. By this logic, this ~25 bps take rate seems pretty high. So there are probably two things that could happen here:

2. They’ve found a niche or product play that lets them charge above-market (unlikely in such a commoditized space) OR this is the gross revenue. (I’m assuming net revenue would be ~50% of gross, but either way Easebuzz is profitable).

Either way, credit to them for reporting profitability. But expanding into offline infra is going to pressure margins further. And their tie-up with Xflow for international settlements shows the direction of travel: standalone domestic payments isn’t enough, so you expand into new licenses and adjacencies.

That’s the recurring theme we keep seeing: the pie in domestic payments is just too small - so players move into cross-border, credit, or adjacencies that need a license.

PhonePe started out as a UPI app, but quickly realized that being just a UPI app wasn’t enough. Over time, it layered payments, broking, PPI, and is now a market leader in UPI with ~46% share. Unlike some peers, it hasn’t aggressively chased a PA-CB license for international flows - the domestic “super-app” story is what works for it.

On the IPO front, PhonePe is one of the big fintechs (alongside Groww) expected to list in 2026. Originally, it was planning a $10 - 12B valuation, roughly in line with its last funding round ($12B). But recent Inc42 reports suggest the IPO may come in lower, at $7-8B.

In FY24, PhonePe reported revenues of INR 5,064 Cr (~$600M), a 74% jump over FY23. If you assume a 50% increase into FY25, revenues land around $900M. At a $15B valuation, that’s ~16x revenue multiple.

For context:

• Adyen trades closer to 20x revenues.

• Block (Square + Cash App) trades at ~5–6x.

So if PhonePe’s numbers are net revenues, the math checks out - it sits somewhere between Razorpay and Adyen on multiples. But if they’re gross, then the effective multiple is much higher, and the IPO looks stretched.

Adyen’s net revenue multiple is ~20x currently (~$51.5B valuation in June ‘25, and FY25 H1 NET revenues $1.28B, and annualized at $2.56B.

Stripe’s FY25 valuation is $91.5B, but its FY25 revenue isn’t publicly disclosed, so I’ve estimated it based on past metrics.In FY22, Stripe processed $817B in TPV and earned $14.4B in gross revenue (~1.7% of TPV), with net revenue of $3.2B (~22% of gross). Assuming FY24 TPV was ~$1.4T, applying the same 1.7% gives ~$23.8B in gross revenue. At a 22% net take rate, that implies ~$5.24B in net revenue. This puts Stripe’s valuation at:

• 17.5x net revenue multiple ($91.5B / $5.24B)

• 3.8x gross revenue multiple ($91.5B / $23.8B)

This net vs. gross revenue multiple is key when comparing Stripe to Indian fintechs and assessing relative valuation. From a benchmark perspective, this is where I’d ideally benchmark other major fintech players in India, especially since we’ve now established that cross border is where the revenue are, and eventually everyone will go international. Which they have already done.

Paytm: International ambitions, domestic rebuild

Paytm has been back in the news for the right reasons. Headlines celebrated its consolidated net profit of INR 122 Cr in Q1 FY26 – its first since September ’24, when the one-off sale of Paytm Insider to Zomato (~$243M) briefly pushed it into the black.

On the surface, this looks like a comeback story: revenue is up 28% YoY and contribution profit is up 52% YoY compared to Q1 FY25, reflecting tighter cost control and stronger lending flows. But there’s nuance in the numbers. Paytm’s EBITDA in Q1 FY26 was INR 72 Cr, and after finance, depreciation and amortization costs of ~INR 170 Cr, the company actually ran a net loss. What flipped the bottom line into a “net profit” was INR 241 Cr in other income, mainly interest from tax refunds – a one-time, non-operational gain.

So while operations are improving, Paytm isn’t yet sustainably profitable.

On the regulatory side, Paytm has restarted merchant onboarding with an in-principle PA (online) license approval, but it has notably not gone after a PA-CB (cross-border) yet. That’s interesting, given its international ambitions. In FY25, Paytm picked up a 25% stake in Brazilian fintech Dinie for $1M – a small ticket, but a clear signal it wants to understand the LATAM ecosystem. I’d read this as a strategic learning exercise before any large-scale move.

Once Paytm stabilizes its domestic stack (including the eventual re-compliance of Paytm Payments Bank), I’d expect them to chase the PA-CB license. Even if they don’t plan to run a fully-fledged cross-border money movement business, the RBI’s posture has been consistent: if you touch cross-border flows in any way, you need to be licensed.

Pine Labs: IPO on the horizon

Pine Labs is another payments market leader now gearing up for its IPO. The company reported a profit of INR 45 Cr in FY25, with revenues growing ~25% to reach ~INR 1,735 Cr. Its IPO push suggests that it is consolidating its scale in India, while showcasing its international presence (Southeast Asia being the key geography). The profitability milestone in FY25 signals that its playbook of diversified merchant services is working

Groww: stockbroking + UPI + licenses

Groww isn’t a payments player in the traditional sense. It’s first and foremost a stockbroker, and a dominant one at that. It recently filed its updated DRHP, with an IPO expected soon. Originally, Groww was targeting a $7–8B valuation, but its FY25 numbers may justify a higher figure: revenues of INR 4,056 Cr ($460+M) and net profits of ~INR 1,824 ($207M) Cr.

On the consumer side, Groww has built a base of 13-15M active users. While its core is stockbroking and investments, it has also quietly become a UPI app, clocking ~INR 9,000 Cr in monthly transaction value as of August 2025 (which is ~$1B). This is not insignificant - for context, challenger UPI apps like Navi and Super.money are in the same ballpark.

From a licensing perspective, Groww now has:

• NBFC - likely tied to its LAS (loans against securities) product. It has built a respectable loan book here, and this also ties into its long-term lending play.

• PA license - while Groww may never want to operate as a “classic PA,” the fact that its UPI flows are growing means it makes sense to be regulated here. If you’re doing INR 9,000 Cr/month in UPI volumes through an entity, RBI would prefer you to hold a PA license rather than just piggybacking off someone else

Deep dive on some of the past valuation pieces I’ve written are below:

1. [#24]: Decoding Fintech IPO’s: Part 1

2. [#51] Decoding Fintech IPO’s - the India focus: Part 2

3. [#67] When IPO’s loom, multiples shrink

But the point is: the natural path for fintech expansion is to first go deep (owning more of the method stack), then go wide (adding adjacent licenses and services), and eventually international.

That’s exactly what we’re seeing: Paytm, Razorpay, Pine Labs - all of them have either invested abroad or set up international offices. And of course with Easebuzz, while it is waiting for its PA-CB, has tied up with Xflow for powering cross border money flow. And Cashfree of course - with it’s import and export PA-CB, PA, and PPI. There are two takeaways I have from the above section:

1. But the bigger takeaway is this: standalone domestic payments will not work. The margins are too thin, the pie too small. You can’t survive on just UPI or card acquiring. You need breadth, lending, broking, cross-border, banking licenses to make the model sustainable. So atleast for those payment aggregators which are just on PA, especially with the gaming & rent payments ban, they will need to open up other streams of revenue

2. Second, and equally important: profitability is back in focus. Unlike Paytm, which IPO’ed while still loss-making, there’s now a clear shift. Investors are rewarding profitability over just scale.

   1. Easebuzz is profitable, reportedly $2M in FY25 (INR 22 Cr)

   2. PhonePe is profitable (excluding ESOPs cost) at $22M in FY24 (INR 194 Cr)

   3. Pine Labs reported FY25 profits of $5M (INR 45 Cr)

   4. BharatPe reported its first ever PAT of $68k (~INR 6 Cr) is lining up a pre-IPO round of ~INR 1,000 Cr, valuing the company at 11-12x revenue multiples

   5. Groww is profitable and consistently so with FY25 profits of ~$207M, AND with a massive user base and diversified revenue streams.

The world makes sense again - it’s not just about chasing GTV anymore, it’s about proving that the model works and can stand on its own. AND, all the above players are diversifying: Easebuzz is PA & PA-CB, PhonePe is UPI App, PA, PPI and broking, BharatPe is UPI App, PA, NBFC, and Unity Small Finance Bank after the centrum merger.

Now also, look at the set of players that now hold a PA license → it is a crazy number: 55!

They come in all shapes and sizes - and interestingly, many of them aren’t traditional payment aggregators at all. A good chunk are UPI apps. And there seem to be WAY more than makes sense: if 4-5 players in the market are profitable (and barely so), it seems to say that there is no more room for sustainable businesses to exist - and no one here is dumb, folks understand the market mechanics and the saturation levels.

The numbers show how crowded it already is: 55 players are fully certified PAs, 12 more in principle approval and 21 cannot operate, but have a license in stage of approval

👉 55 players with full licenses below

👉 12 players which can operate as a PA, and have a license in some stage of approval

👉 21 players which cannot operate as a PA, but have a license in some stage of approval

Makes no sense. But here’s my view: majority probably don’t even plan to operate as PA’s → they’ve got this license for regulatory cover since they are in the payment space, and in India atleast there isn’t any other license that gives regulatory cover to payment players apart from the Payment Aggregator license

Here’s the catch: most of these players who’s gotten a PA license probably don’t intend to build full-fledged aggregation businesses. Instead, they’ve picked up the PA license as a regulatory hedge.

The point is: even if you’re “just” a UPI app, or an infra player who doesn’t want to be a full-fledged aggregator, you’re still touching money flows. UPI apps process volumes, they route payments, they sit in the middle. At some point, the RBI is going to look at that and ask: how are unregulated players playing such a central role in money flows? After all, being a UPI app is technically just a certification, not a license.

That’s where the idea of a “willingness to comply” license comes in. Something fintechs can hold to show they’re regulated, even if their core business isn’t merchant acquiring. It’s less about strategic economics, more about legitimacy and regulatory cover.

This is probably what’s driving NBFCs like DMI and ABFL, or even players like Policybazaar with PB Pay, to pick up PA licenses. NBFCs don’t make their margin in payments, they make it in credit. But holding a PA license is a way of being inside RBI’s perimeter, if they have payment / payment adjacent ambitions in UPI / affordability or something else. Same with Policybazaar: they already run a consumer-facing app, and may want to be closer to fintech or payment flows.

It’s also Gokwik, Juspay, and pretty much any UPI app that touches a transaction. So don’t be surprised if everyone ends up applying for one.

With UPI being the backbone of Indian payments, and RBI keeping a close eye on the ecosystem, holding a PA license gives them optionality. If tomorrow regulation tightens around who can operate or monetize on UPI, these players already have a seat at the table.

In other words, the PA license isn’t just about running merchant acquiring - it’s increasingly about future proofing.

But here’s another problem with that: while in 2020 India’s PA regulations were to establish a framework, the updated guidelines of September 2025 have instituted tighter controls, which may make it tough for smaller / newer players in the payment / payment adjacent space

Ideally, there should be some difference in reporting, net worth, or KYC needs basis scale OR type of service offered. Payment aggregation ideally should only refer to those players that are touching / handling money flows. You’ve got a whole lot of other players doing payment initiation, or orchestration, and are involved in making the payment flow more smooth, without actually being involved in the fund flow. But in the absence of that, the PA license is all we’ve got. (And this is also where things blew up I feel, like in the case of Juspay, where after Juspay got the license, PA’s banded together and said that they would remove support for Juspay’s payment orchestration solution since they felt Juspay would steal their customers away. If there was another payment infra license, maybe this would have helped assuage fears)

Side note: Some points to note in the updated PA license requirements of September 2025

1. Tighter governance checks

2. Stricter controls on escrow accounts

3. More security / audit requirements on IT and systems

4. Stronger grievance redressal systems

5. Enhanced KYC / KYB checks

6. From annual reporting to monthly / quarterly reports & audits

7. And finally: while the 2020 PA guidelines only talked about online / ecomm players, the 2025 guidelines also brings in offline, POS, soundbox under these guidelines. Also - and this is interesting, the guidelines mandate that there has to be a single escrow used for funds for those players that operate as PA-O (online) and PA-P (offline). I guess RBI’s goal was to reduce arbitrage, and increase transparency, for unified settlement and monitoring. I’m assuming what happened in the past is that players operating in both online and offline, by maintaining two separate escrows were able to get around some net worth, KYC and reporting requirements, and maybe even cover up gaps in one account due to excess funds in another.

TLDR: Suddenly this makes getting a PA license as a hedge a lot of additional overhead, and cost of compliance that a smaller fintech may just not have the capability to manage

Regulators elsewhere have created light-touch, perimeter-expansion licenses keeping this exact problem in mind:

✅ Singapore:

In Singapore, MAS offers a Major Payment Institution license and a Standard Payment Institution license, so even small players can operate under regulation without the full compliance burden. And SPI & MPI is differentiated basis the scale they have: volumes: SPI ≤ S$3M/month (single service) or ≤ S$6M (aggregate); above this = MPI. SPI’s & MPIs can conduct the same activities.

1. Account issuance (wallets)

2. Domestic acquiring (paynow, P2P, bill payments)

3. Xborder remittances

4. Merchant acquisition (PA, POS, checkout players)

5. E-money

6. Digital payment token (crypto exchange, custody, brokerage)

7. Money exchange (forex)

Capital requirement:

1. SPI: $100k

2. MPI: $250k

Point to note here is that players have to apply for SPI / MPI + the specific service (ex: Wise has MPI + Xborder). It’s not that one just applies for a SPI / MPI and then can operate all the above activities

👉 TLDR: SPI has less capital requirement, lighter touch, fewer disclosures required → which best for early stage players.

✅ EU

4 licenses:

1. PI: money transfer, merchant acquiring. Closest to India’s PA license

2. EMI: wallets/e-money

3. AISP: Account initiation Service provider - kind of like access to customer data (like India’s Account Aggregators)

4. PISP: Payment initiation only, not touching the fund flow

👉 Allows for separate licenses for infra players (AISP / PISP). PI is equivalent to India’s PA license, but it has further broken down acquiring into AISP (which is like India’s AA for data access) and PISP, which is payment initiation (like Juspay). Unlike in India where everyone in payments needs to get a PA license, EU has broken down where payment players actually move money, and where they are just involved in the transaction without actually holding any funds

✅ UK

Similar to EU with scale based licensing, and the fund flow vs just payment infra distinction. SPI (Small Payment Institution), API (Authorized Payment Institution), AISP (for aggregating account information) and PISP (for payment initiation). And then of course the EMI (Electronic Money Institution) for prepaid accounts / wallets issuance.

Min capital requirement:

1. SPI: Initial capital not required (source)

2. MPI: ~$25k

So the key themes coming out here from these global examples are:

1. Licenses are modular: you can choose what you do (initiation, info, acquiring, issuing), it’s not 1 blanket license that you have to get regardless of fund flow involvement or not, like India

2. Scale differentiation exists in some regions (UK, Singapore): SPI vs MPI (or API in the case of UK), enabling ease of licensing for smaller players, which helps to drive innovation by smaller players

3. Infrastructure players can operate without touching full payments (ex: EU PISP).

India has an all in one approach for payments

India doesn’t yet have this middle layer. The PA license has effectively become that “catch all” option for payment fintechs to show willingness to comply. Which is why you’ll continue to see not just aggregators, but NBFCs, brokers, and even consumer apps quietly filing for one.

1. Payment Aggregator (PA) license seems to be required for almost all players in payments, regardless of them touching fund flow. Even if it is not stated explicitly, this does seem to be the way it is being interpreted. Even if you just want to initiate payments or provide “payment infra,” you still need a PA license.

2. There is no modular distinction for PISP-like functionality vs actual acquiring, or at a scale level, to enable smaller players to innovate. No scale-based SPI/API separation; regulatory burden is uniform.

3. This makes it harder for new/small players to enter, compared to modular systems in EU/UK/SG.

As fintech evolves and use cases diversify, a one-size-fits-all licensing model stifles innovation. A tiered framework, such as PISP, SPI, MPI would allow regulators to categorize fintechs by scale and risk, enabling tailored oversight while fostering experimentation and growth

Out of the 73 fintechs I’ve profiled as a part of this piece, 54 of them have PA licenses. Apart from maybe 5 -10, the rest probably won’t ever use them. I rest my case.

👉 Appendix: List of fintechs in India, and their license status

The finished product: A website built using purely AI tools (and an AI prompter, courtesy of chatGPT). Tools used:

• Lovable for front-end designs

• Cursor for the code

• Google OAuth (through Google Cloud console) for authentication (using your email sign-in)

• Supabase: for serverless backend, to actually execute the OAuth, and host the databases

• OpenAI: for AI powered workout recommendations based on configurable inputs

Link to those who want to try out the live app here: link (note - if I’m out of credits, this may not work, but I’ve attached screenshots below to show how it worked. Note, the sign in for whatever reason is easier to do on the laptop, if you do it on the phone it still works, but requires multiple redirections)

But I’m getting ahead of myself. Let me start at the beginning:

Something that’s been sitting on my “one day, maybe” list was to actually use all these fancy tools that everyone in product and tech keeps raving about: Supabase, Cursor, Lovable, OAuth this, AI that and try building a website from scratch. Preferably AI powered, because let’s be honest, if you’re not sprinkling AI on it in 2025, does it even count?

Now, I don’t come from a traditional tech background. I didn’t study software engineering, I played sports and dabbled in finance (my undergrad), then went off to do an MBA where I’m still not entirely sure what I actually learned in an academic sense. Most of what I do know has been stitched together from reading docs, figuring out stuff on the go in my product & strategy roles, bugging tech friends, staring blankly at error messages until something clicks, and using tools - big fan of the “move fast & break things approach.”

But my philosophy has always been pretty simple: the best way to learn is to throw yourself in headfirst. One of my favourite quotes is by the main character Kvothe in the high fantasy novel: “The Name of the Wind” by Patrick Rothfuss.

“It's the questions we can't answer that teach us the most. They teach us how to think. If you give a man an answer, all he gains is a little fact. But give him a question and he'll look for his own answers.” -

For those of you folks who read high fantasy, I couldn’t recommend this book enough, with a caveat: if you’re okay with the series never being completed. There were supposed to be 3 books in this series - “The Kingkiller Chronicles,” but for all of us who are fans, we’ve given up on this, there are some excellent reddit threads where people keep putting up their own theories).

But back to the point. Armed with the same “jump in headfirst” logic, I decided to pick this up as a pet project: use the shiny tools everyone’s talking about - Cursor, Lovable, ChatGPT and see if I could stumble out the other side with a half-decent working website. What exactly to build? That part was still fuzzy. But regardless, I was a woman on a mission.

To work then. Note: The above image was generated by chatGPT

Phase 1: the enthu cutlet

Saturday: 11:01 am

My first bright idea was to build a book recommendation engine. But I scrapped that almost immediately. It felt boring, too basic, and honestly not enough moving parts to really flex. As a “pRoDUCT maNAGer” (yes, that’s how I imagine myself saying it), I figured I should at least attempt something with a little more complexity.

So naturally, the next big brainwave was…a fitness tracker. Groundbreaking, I know. And for those of you who know me, completely unexpected, obviously. I called it FitTracker. Clearly, the creative juices were in full flow.

Saturday: 11:35 am

Now that I had my world-changing idea in place, the next question was: which weapon of choice? Up until now, I’d mostly used Lovable for clickable prototypes - basically, mockups you can show off, or validate an idea to drive stakeholder validation, but not really do much with. I’d never actually gone full stack with it. No authentication, no databases, none of that scary backend stuff.

And since I’m firmly a believer in the “sink or swim” school of learning, I figure: why not just dive headfirst into something that could actually break? Enter Cursor.

I’d tinkered with Cursor before, but only to spin up simple HTML files. Fun, but those are locally hosted - meaning you can click around all you want, but it’s not live-live. You can’t send the link to a friend and have them check it out. Still, I gave myself a warm up lap by playing around with it again: some basic HTML, a couple of tabs to click through, nothing fancy. Just frontend stuff. No database, no data storage, nothing resembling a “real” app, and nothing made live yet.

Saturday: 12:22 pm

In the process of messing around with prompts on Cursor, I hit the free limit. And of course, the little pop up message told me I’d need to upgrade to keep going.

Sigh.

But by then, I was committed. So I do the unthinkable: I spent $20 (~ INR 1760) on a Pro subscription. Naturally, being the cheapskate I am, I immediately cancelled auto-renew so I wouldn’t accidentally pay for month two. Still, the moment I paid up, I decided this automatically made me a “pro.” Enough with the toy HTML files and it was time to actually deploy something and take it live.

Total spends: $20 or INR 1760 on Cursor

Saturday: 1:15 pm

I’ve never really taken anything live before, so naturally I go and pray to ChatGPT to figure out how to deploy these HTML files. The easiest way (or at least that’s what ChatGPT told me) was through GitHub Pages. Cool. No idea how to do this, but let’s roll with it.

I log into GitHub and, side by side with ChatGPT, tried to piece together the steps. It actually seemed fairly straightforward: I took the files Cursor had generated, created a new repository (very creatively named fitness-tracker), uploaded the files, and then “committed the changes,” which is basically github / tech jargon for saving the uploaded files as the latest version of the project. From there, it was a matter of navigating to Settings → Pages, selecting the branch (main) and root folder (basically telling GitHub where the code lives), and hitting save.

A minute later, GitHub spits out a live site link. When I click on it, the site shows up, except my navigation between pages wasn’t working. I’m guessing I messed up my prompts earlier.

After some fumbling around, I finally ask Cursor to just give me a proper, deployment ready package for GitHub with all the logic baked in. I upload that folder, and this time everything seems to work. For the first time, I actually had a “live” site. Looked like FitTracker was on its way.

👇 Screenshot of Github where, after uploading & committing changes, I got the live link

Saturday: 2:00 - 4:30 pm

I’m fairly upbeat. I feel like I’m on track to figure this out. My flatmate and I decide to go out to celebrate. I have a premature celebratory lunch at Pizza Bakery and then take a nap.

Saturday: 5:30 pm

I wake up, pour myself a cup of chai, and convince myself I’m ready to take on the world.

✅ Step one: turn this idea into a live site. Done & dusted. This is what the first iteration through cursor looked like.👇

❓Step two: make it slightly less unsafe (but no less cooler obviously) by adding an authentication layer, using Google OAuth

Health data is private, I reason. Google authentication should be “simple enough.” Famous last words.

Turns out “simple enough” is a massive understatement. Because now I have to call in another service to authenticate, which apparently needs…a backend. Great. Cue frantic chat with ChatGPT. ChatGPT tells me that the easiest way to do this is using a tool called Supabase. Supabase sounds familiar. But also, what the hell is that now?

Ten seconds later, I’m a “backend as a service” expert. For the uninitiated: Supabase is an open-source Backend as a Service (BaaS - not to be confused with Banking As a Service) platform that provides a complete backend stack, including a PostgreSQL database, user authentication, file storage, and serverless edge functions. Also, apparently, it’s a $2B start-up, which was founded in 2020. Fancy.

To make it easier to understand: a fully live website needs a backend for secure storage. Your front-end is can be inspected by anyone, and if you’re using any key pair, or Client ID + Secret (think of this as a username + password) to access secure services, it can be stolen. So the front end website - in this case HTML, cannot directly call other services. The backend, such as Supabase in this case is secure & private, and for things such as authentication, you have to keep your “secret” secure, which only a backend can do.

That’s why Supabase comes in: your GitHub Pages front-end talks to Supabase, Supabase holds your secret, talks to Google, and then passes the user info back. I remember then, I’ve met Supabase before. That’s why it sounded so familiar. It was hanging out in my Lovable experiments, silently hosting my backend while I twiddled my frontend thumbs.

And that is the next step, and the curveball that Cursor throws. I need to generate a Client ID and secret for my project, from Google Cloud console and add that to Supabase so that end users can actually use their emails to sign in: and so that Google can also authenticate this against the project set up in Cloud Console, and ensure that it knows which app is asking for data, and there isn’t anything fraudulent happening. For context, when you’re asked in to sign into a new website using your gmail, that app / website has utilized GoogleOAuth for the same.

Example of Google OAuth happening below: 👇

Lovely. Everything makes perfect English sense, yet in actual practice, I have no clue what the hell I’m doing. But I keep going

Saturday: 7:02 pm

I stumble into Google Cloud Console, squint at all the menus, and somehow set up my project - and keeping it consistent, I call it fitness-tracker. I also have zero clue what URLs to put where, or even how to find the sacred Client ID and Secret. So, naturally, I call in ChatGPT for a rescue mission.

After some trial, error, and copious amounts of frantic scrolling, I finally manage to unearth a couple of complicated looking alphanumeric strings that feel like the keys to the internet itself. Yep, that must be right, I think

Annoying side note: Google makes you set up a “mandate” of up to INR 15k to use this. They pinky promise they won’t touch your wallet for normal OAuth stuff, it’s only for extra spending. Sure, I guess we’ll know soon enough. For now, I have my precious Client ID and Secret, and that’s enough to feel like a developer.

👇 Me setting up my project in Google’s cloud console so I can get the Client ID & Secret to configure into Supabase:

Google Cloud Console set up to use Google OAuth as a sign in mechanism into FitTracker

Mind you, the links you’re seeing now are the ones I eventually put in, when I built the site using Lovable. But more on that later. Earlier, they were just GitHub URLs, because my original genius plan was: “Take this live with Cursor and GitHub, and figure everything else out later.” This is how Google Cloud console also makes authentication requests more secure - if these urls do not match what happens in the live mode, then authentication fails. If you see the above snapshot, it asks for 2 types of urls.

1️⃣ Authorized Javascript Origins: These are the websites allowed to start a login request from a browser.”
2️⃣ Authorized Redirect urls: Once Google authenticates the user, here’s where you are allowed to send them back.

Setting up Supabase for authentication

Supabase wants two things:

1️⃣ Where requests will come from (that’s me telling it my GitHub front end exists). That’s where I add the site url, from where the log-in request will come from.

2️⃣ How it will talk to Google for OAuth (aka: here’s the ultra important Client ID and Secret, please don’t burn my app), which I add below:

I’m a bit pop eyed at this point, but from first principles: it’s basically me logging in and making sure the right URLs & passwords are in the right boxes, so that the different services here are able to talk to each other and authenticate.

The flow, for anyone keeping score, is: GitHub front-end (holds the Client ID) → Supabase backend (holds the Client Secret, and uses ID + Secret to talk to Google) → Google APIs for OAuth → Redirected back to supabase which confirms authentication → redirects back to Front-end. The above is what I have to help map by adding the respecting urls.

Oh, and Supabase hands me a project ID too, which I assume I’ll need to stick somewhere important later. For now, it’s just another mysterious alphanumeric string I can stare at bemusedly.

👇 Thats the skomlyzh….xhx below in the Project ID

Saturday: 9:31 pm

I need a break after all this. I decide to take a break by dissociating on my couch.

I decide to rewatch some episodes of How I Met Your Mother while eating dinner. It’s been years since I watched this show, and after watching a few episodes, I’m pretty sure that if a show like this was pitched in 2025, there would be no way it gets the green signal.

Saturday: 11:05 pm

Now that I’ve heroically gathered all my Client IDs & project IDs from Supabase and Google, I dump them into Cursor and say, “Build me something I can deploy on GitHub, ASAP.” Cursor salutes obediently and 20 files appear in the Cursor chat, in a flurry of green check marks and dramatic exclamation points.

With hands that are somehow both trembling and sweating, I storm into my GitHub fitness tracker repository, upload the files, and commit the changes. I can hear my heartbeat in my ears.

I click the live link. Latency issues? Sure, a little. Design? Seems a little different from the original html file that cursor had created. But the Google auth page actually shows up. My app is alive. I am a developer. Or maybe just someone who finally tricked a bunch of services into working together. Either way, I feel victorious.

👇 Snapshot of what the website looked like after configuring Google OAuth - or so I thought

I then also go through the deployment guide that Cursor has generated helpfully as a part of the files to be deployed. There’s an “extra” step: apparently it also made a database schema for Supabase, and now I have to copy-paste the code into Supabase’s SQL editor and run it so the backend can store all the logs, info, and secret workout data of my users. Sounds simple.

Fifteen minutes later, I emerge slightly more stressed. Supabase’s SQL editor keeps throwing errors. ChatGPT becomes my lifeline, helping me fix one error at a time. I paste, I run, I pray, I repeat, until Supabase finally says, “No errors detected. Go forth and conquer.”

Feeling victorious, I click “Sign in with Google.” Aaaaaand…..nothing.

I get some cryptic error on the log-in page - something along of the lines of “Supabase hates you.” Fine, I think. I have Cursor. My digital sidekick. I open it up, explain the issue, and then type the magic words: “pls fix.”

Cursor ponders, checks, and declares: “Aha! Issue found! Fix deployed.” I can hear triumphant music in my ears. This is it. The moment of glory. I test it locally by opening the HTML file in my browser… and nope. Same problem.

And then begins the cat & mouse game. Cursor fixes one error, and another pops up. Forget deploying to GitHub, the test HTML files don’t even work on my laptop. And as an aside - this is also probably why Cursor is not a great tool for non-engineers. I don’t even know what I don’t know, so unlike other tools / chats where I can give direction, apart from saying please fix, or copying and pasting code from different LLM chats into Cursor, there isn’t too much input I can give here.

Saturday: 12:30 am

I’ve been wrestling this digital monster for eight hours. Cursor has generated multiple test files, troubleshooting guides, and existential dread. Nothing works.By 1:00 am, I realize: it’s Saturday. I need sleep. Tomorrow is another day. I close my laptop and decide to crash.

Phase 2: the slightly less enthu cutlet

Sunday: 10:15 am

My flatmate has woken up at a sane hour. She’s already started her day: gone for a run, chugged a protein shake, stared thoughtfully at some neighborhood cats, and now she’s Ready to Go. Where exactly she’s going, I have no idea.

Meanwhile, I crawl out of my room, eyes half-glued shut, still haunted by visions of Cursor and and the error it keeps throwing out. My battle isn’t done, and my flatmate’s productivity is a cruel reminder that I might never reach that level of morning readiness.

Sunday: 11:15 am

I’ve had breakfast and coffee. I’m feeling a little more upbeat. I have some hope.

Sunday: 11:35 am

I’ve put in a couple of prompts into Cursor, but I literally have no clue what to do. At this point I’m just copying and pasting prompts from cursor to chatgpt and vice versa. I’ve almost given up at this point. We’re going in a circle. I open up chatGPT and ask it why cursor sucks.

Sunday: 12:14 am

I collapse onto the couch and watch a few episodes of With Love, Meghan. Everyone on that show looks like they’re there against their will. Kind of like how Cursor has been “helping” me with my brilliant fitness tracker idea. Deliberate sabotage, I think.

Sunday 3:05 pm

I’ve done absolutely nothing all morning except brood over my failed project, and demolish a hearty lunch. I crack my knuckles. There’s only one solution left: a coffee shop. A cappuccino, bad WiFi, and strangers loudly detailing the horrors of their week is clearly what I need to fix this.

At the coffee shop, I open ChatGPT and pour my soul out: “Look, I’m not an enginer and this project is killing me.” ChatGPT, ever the considerate therapist, responds with a comparison table of tools for tech vs. non-tech-first people, the most prominent being Lovable as a possible alternative to make this dream of mine come true.

And that’s when Lovable steps in. Cue a hero’s entry with loud drum beats, and some inspirational music.

I’m anyway familiar with Lovable for prototyping, but I’ve never used its backend capabilities. It has a direct integration with Supabase for backend hosting, databases, authentication and so on on. And to connect Lovable to Supabase, since it’s already sort of pre-integrated, if I already have an account (which I do because of my Cursor & Github saga), it takes me just 1 click to connect my fitness tracker project in Supabase to Lovable. And another advantage of the pre-integration - Lovable does all the heavy lifting to set up Supabase that Cursor made me bleed for.

I open Lovable and boldly command it to build me a fitness tracker that can rival Whoop & Garmin.

This time, I’m smarter. Instead of springing Supabase & Google OAuth on it at later stages like I did with Cursor, I start from the top, asking for all the integrations in the very first prompt. Lovable even asks me for the Client ID in the chat, so it can map it to Supabase, way easier than the Cursor circus.

In hindsight, I should have probably taken more time to think it through before I even started working on Cursor. This is AI 101 - and I’m smacking myself thinking about it now. In my defence, when I started out, I didn’t even think about the authentication & the backend parts of the site, I was still thinking about it from a very front end perspective.

Of course, it still takes multiple prompts, and I go through my free credits in about 15 minutes. But I’m too far gone to stop, so I bite the bullet and buy a monthly subscription: $25 or INR 2199. Money well spent, I tell myself, as my cappuccino goes cold.

Total Spent: $45 or INR 3959

1. Cursor: 1 month subscription: $20 or INR 1760
2. Lovable: 1 month subscription: $25 or INR 2199
3. Google cloud console: Unbilled but mandate set up in case of further spends: INR 15,000

👉 Insight: Working with Lovable was WAY easier than with Cursor.

Honestly, working with Lovable felt like someone finally gave me the cheat codes. The direct Supabase integration was a game changer, I didn’t have to keep jumping between Supabase and Lovable. Lovable would surface the exact Supabase links I needed in the chat: where to update URLs, where to add client IDs and even allowed me to set up databases, or make edits to the database schema by typing directly in the chat. With Cursor & Github it wasn’t connected, so it was almost like me doing this blindfolded with no prior experience, and required a lot of trial and error to get it right.

That said, spending an entire day wrestling with Cursor, Supabase, and Google Cloud Console definitely paid off. By the time I got to Lovable, a lot of the groundwork was already done. Supabase was set up, the Client IDs & Secrets I had got from cloud console, and Cursor had even created the database schema that I just had to copy and paste into the Supabase SQL editor and run, instead of getting Lovable to set it up again. My job was mostly: update site URLs, callback URLs, and endpoint, because now, instead of GitHub, this was running on Lovable servers.

Once I configure the urls, I test the OAuth flow again, but without too much hope. I’m ready for it to crash again. But this time, it works!

The callback URL you see below: skomlyx…supabase.co is the Project ID of supabase, and what I configured in the Google Cloud redirect URL. After all the chaos, it finally felt like a real app, and I felt a sense of accomplishment.

👇 Live and working GoogleOAuth from the app built on Lovable

Sunday 4:30 pm

On that note, I head out to play padel with some friends. This is only my second time playing, and while it’s obviously not on par with tennis, it’s way more satisfying than pickleball.

Sunday 8:30 pm

I’ve come back from playing padel, had a protein shake, and settled in for dinner. Now, with the day winding down, I sit back to explore the app I’ve created. Everything seems to be working, so I start testing if the events are being logged into Supabase.

This is another win: thanks to Cursor, I had already set up the database and Supabase project for FitTracker. But what Lovable added on top was amazing, it let me create and edit the database schema directly through the chat. I could make changes on the fly without jumping between consoles.

I publish the site, start interacting with it, and lo and behold I can see the database logging events perfectly. The data is flowing, everything is syncing, and I feel a rush of excitement. For the first time, it hits me: I’ve actually built something from scratch, something tangible and functional.

👇 Supabase data tables recording live data logged in from the app

Phase 3: Adding the AI recommendation layer using OpenAI APIs:

Sunday: 10:00 pm

I’m feeling pumped - FitTracker is officially working! I send the link to a few friends to try it out. They’re able to sign in without a hitch and add their fitness details. Watching the data appear in the Supabase database in real time is thrilling. It’s one thing to build something, but seeing others interact with it and knowing it’s actually logging data? I feel pretty accomplished.

I decide it’s time to add a recommendation engine to FitTrack. Following my usual routine, I open Lovable and command it to create an AI-powered workout recommendation engine. It pauses thoughtfully, then tells me I need to share my OpenAI secret. Essentially, the flow will now be: Lovable (front end) → Supabase (backend) → OpenAI intelligence → output back to Lovable (this is after auth is done).

At this point, I feel like an expert, I have client IDs and Secrets coming out of my ears. Lovable provides a link to the OpenAI developer login, and I flex my fingers like a pro, opening ChatGPT on the side for guidance. Compared to the chaos of juggling Google, Supabase, and Cursor, this seems laughably easy.

👇 Getting OpenAI keys to access OpenAI intelligence for AI powered recommendations

I go to the OpenAI API keys, generate a key, and share it with Lovable. Lovable thanks me profusely and confirms the recommendation engine is ready. Forget an AI powered PM, I’m ready to call myself an AI engineer at this point. I enter the configuration details, which I’ve set as muscle groups, intensity, duration of workout, and training type (cardio, strength, HIIT) and wait breathlessly.

The workout starts generating. And then gets stuck. It never generates, but remains in that loading state, like the google log-in errors I had when I was building the website using Cursor. I’m having traumatic flashbacks at this point.

I’m at my wit’s end, so I ask Lovable to fix it. The problem seems to be billing (of course, OpenAI APIs aren’t free). I smack myself on the forehead, but also feel slightly relieved. I head back to OpenAI, and prepay $10 (+18% GST, so $11.80 or INR 1038) to get this working. I then reload the FitTracker on Lovable, and ask it to generate another workout. It fails again. I’m close to tears.

Total Spent: $56.80 or INR 4996

1. Cursor: 1 month subscription: $20 or INR 1760
2. Lovable: 1 month subscription: $25 or INR 2199
3. Google cloud console: Unbilled but mandate set up in case of further spends: INR 15,000
4. OpenAI APIs: $11.80 or INT 1038 ($10 + 18% GST prepaid)

Sunday: 10:46 pm

The finish line is so close I can almost taste it. Lovable tells me to check the logs on Supabase. I peer at them, completely clueless. Meanwhile, Lovable explains that there’s a mismatch between frontend and backend, the backend is sending one event, but the frontend is expecting another. It applies a fix and then fails again.

I’m relentless. I prod Lovable to fix it, again. This time, as we inspect the logs together, we discover that OpenAI is returning empty responses. Lovable explains that GPT-5 is using different model parameters.

It switches back to GPT-4o……and it WORKS!

⏳ I select my workout preference…

🎉 And FitTracker generates an AI powered workout! On inspecting the Supabase logs, I also see that there is a successful OpenAI response!

I can’t believe it! I’ve created an AI-powered app and taken it live, well, live by my definition. The only thing that still bothers me is the domain name:

Domain name on Lovable: https://ddffc4fd-031d-4e01-8a50 9713ab82e93b.sandbox.lovable.dev/dashboard

Clearly, this won’t do. Luckily, it’s easy enough to fix. You can go to a domain registrar like GoDaddy and search for a domain. Once you buy it, you need to:

1. Connect your domain in Supabase.

2. Follow Supabase’s instructions to configure the same DNS settings in your registrar (Ex: GoDaddy, if you have used a vendor that is not connected to Supabase for domain set-up).

3. Wait for DNS propagation, which is fancy tech-speak for “record updates.”

Once that’s done, anyone who visits fitttrack.in for example, will be redirected to my app on Lovable’s servers. I can set up / buy my domain straight from Lovable, you can follow the steps in the chat. Lovable (like everything else clearly) has also built a way to seamlessly add your custom domain to your app build, and allows you to also buy domains through integrated third party vendors.

👇 Setting up your custom domain for your project on Lovable

👇 IONOS - 3rd party integrated with Lovable through which you can buy your custom domain.

I decided not to take this step. I felt that spending INR 5k on this project was a good enough amount, and I have done this domain set up / DNS set up in the past, so I didn’t feel I needed to spend money on this experience.

Conclusion: It took me about 2 whole days to figure this out and build something from scratch, with zero experience.

It took me about two full days to figure this out and build something from scratch, with zero prior experience. But it was also me being relentless, sticking with it until I got it right. And there were times when I was close to just shutting this down.

Some key takeaways:

1. This was a pretty good learning experience. I now have a much better understanding of how to use these tools, not just Cursor and Lovable, but also how to integrate third-party services to build a full-stack website, such as Authentication and backend services. Next time I tackle a project, I expect the process to be much faster. The “move fast and break things” philosophy really worked here, and I came away with practical knowledge of what to do, which tools to use, and what to set up.

2. I definitely recommend this approach for anyone who wants a solid, hands-on understanding of these tools, assuming, of course, you have time to spend, you’re willing to invest a bit, because AI isn’t cheap. I ended up spending around $25 on Cursor, $20 on Lovable, and $11.80 on OpenAI, for a total of $57 or ~INR 5k Thankfully, Supabase and Google OAuth didn’t cost me anything, but that was because I built this as a personal project with zero traffic, and I didn’t buy a custom domain.

3. If you’re building something full-stack, you need a clear vision of the services, backend, and auth setup you’ll use before diving in. Hacking together a quick prototype is fine, but once you start layering frontend, backend, and integrations, a little planning goes a long way. These AI tools don’t optimize your codebase, they just keep taping on whatever you ask for. The result? A kind of duct tape engineering: lots of layers, not much stability. Inevitably, things start to break, and I’m assuming that’s why my project on Cursor broke. I even heard a horror story where someone used Cursor to churn out code for a client project, only to have it collapse at deployment because all that duct tape couldn’t hold.

4. Lovable was way easier to work with than Cursor for me as a non-engineer, especially because of the visual interface. With Cursor, I often got stuck in loops where I didn’t know enough to give meaningful suggestions. Expertise and domain experience clearly matter, and there’s huge value in diving deep into a specific tool or domain.

5. AI is expensive, even just to experiment. Free prompts only take you so far. Even basic Supabase and Lovable subscriptions cost money. To scale this into a real app with traffic, I’d need to buy a domain and upgrade my backend to handle constant use. But for learning and experimentation, this level of investment was more than worth it.

And also - SaaS might be dead (atleast what some folks on the internet are claiming) but AI SaaS seems to be only starting out

For those saying SaaS is dead, this project reminded me it isn’t, at least not AI SaaS. Subscription models are alive and well when it comes to tools that actually let you build something meaningful. Another example: Golpo AI - a tool I’ve been experimenting with to create article videos, costs $20/month just to make 8 minutes of AI generated video. A tad expensive in my opinion, but it works, and it delivers value.

Runway, another cool tool for image and media generation - I tried to get it to create multiple images for this article, but after 1 image I ran out of credits, and was I told I would either have to wait for a bit, or buy a paid plan (ugh).

And for those of you folks who are building in this space, and using these tools, would love to hear what tools you’re using, and how you’re optimizing your AI toolkit.

👇 How I felt after completing the FitTracker. Image generated by Runway

There’s also another important leg here, which is the UPI App itself, which is a part of the Payer Stack

Now, in the case of UPI Apps, especially for newer ones, there are multiple issues that they have to deal with:

1. The market is saturated, and incumbents have ~95% share. Take a look at current market share, the top 4 control 90%. PhonePe has ~46%, Gpay has ~35%, Paytm has 7%, and Paytm has ~2% (this is in terms of number of transactions, if you look at value processed, then it’s even more skewed). So how do newer apps stand apart, aside from doing crazy cashbacks?

2. Limited monetization: UPI Apps don’t make money because UPI is “supposed to be free.” PA’s may still be able to make some money by offering value added services, and experience layers on top of this, but for a UPI App, they cannot charge the end customer. UPI Apps can make some money from the issuing bank on P2P transactions, but this also depends on the leverage these apps have, and newer ones have 0 leverage. A PhonePe / Gpay / Paytm may still be able to pull something off here. So how does a new UPI App scale sustainably?

For a new UPI App to get that scale, either they offer cashbacks - which isn’t sustainable. Or they offer some sort of financial incentives to the customer. (like credit, and maybe thats the CC on UPI play). Or they have to be present at the point of sale, which requires them to partner with existing fintech / checkout players. But in all of these cases, I don’t see a standalone UPI App working, especially for newer players. There’s also a reason why the OG UPI Apps expanded into PAs, lending, offline POS, and a whole bunch of adjacent services. With payments in India being commoditized, you need to own the experience, and that requires you to own as many pieces of the puzzle as possible

I’ve written in the past about what I see the strategy being for newer UPI Apps - either start with a niche use case and get acquired, or go for a full stack play

I’ve written in detail about this, and you can check out the below article, but TLDR → I don’t see the full stack play being viable for newer apps, the market is just too competitive. Which brings us to point 1) Start with a niche use case and get acquired

Both these plays seem be happening. Some things that happened in the last few months are:

1. Razorpay invested $30M for a majority stake in Pop in June 2025

2. Zaggle, a spend management app, bought Rio Money, a CC on UPI focused app in July 2025 for INR 22 Cr ($3.5M). Note: from what I could see, there aren’t any transactions on Rio’s UPI App as per the NPCI website, but I could see Payer PSP details, so I assume its tech stack, NPCI sign offs, and bank partnership for credit card issuance was done, it just wasn’t like at scale. I’m assuming some CUG testing was done.

3. Kiwi, a CC on UPI App founded in November 22 raised its Series B of $24M from Vertex Ventures South East Asia & India, with participation from Nexus Venture Partners, Stellaris Venture Partners, and Omidyar Network in August 2025

Kiwi: a CC on UPI App, valued post money at $100M after its FY25 funding round of $24M, with a revenue multiple of ~100x!

Kiwi is a CC on UPI focused app that was founded in 2022. It raised $24M in its Series B fundraise, which follows its Series A round in November 2023, when it secured $13M. It’s July 2025 metrics were ~2.85M txns & ~INR 323 Cr in value processed in July 2025. And it was #35 in terms of UPI App ranking (for volumes).

If we had to look at its annual data: Its revenues in FY23 - 24 were ~INR 5.38 Cr, and in November ‘23 it was valued at ~$65M. (which is a 100x revenue multiple, and seems really high if I compare it with other fintechs, where valuation multiples are capping out around ~15- 20x. You can check out more details here: [#67] The great fintech valuation correction: When IPO’s loom, valuations shrink.

It’s FY23 - 24 (calculated as April ‘23 to March ‘24) revenues as a % of GMV through the UPI App (It did INR ~691 Cr in UPI App volumes, and I’m assuming that it had no other revenue streams), was ~0.78%. Assuming the same %, at a FY24 - 25 GMV of ~INR 1091 Cr, this comes to ~8.51 Cr revenue (these are my own calculations, this could be more), and multiple stays around 100x.

I’m assuming Kiwi makes money through being the TPAP leg + some negotiation it’s done on the MDR cut with the issuing bank(s) as a distribution partner.

Credit Card MDR on Rupay is around ~2%, so there is an opportunity to monetize on these volumes, as compared to regular UPI transactions. And this could be one “niche” that I talked about earlier: the opportunity for a UPI App to carve a niche out for itself and get acquired. Although from Kiwi’s fundraise and reported valuation, it looks like its going after scale right now.

Moving to Pop: A scaling UPI App which was founded in FY24, and got $30M investment by Razorpay in FY25 for a majority stake (estimated valuation ~upto $60M)

In FY25, Razorpay announced that it picked up a majority stake in Pop, for a $30M investment. Now, I’m doing some back of the envelope calculations here. Assuming that a majority stake here means anything above 50% ownership, and also assuming at its most conservative that this stake is around ~51%, this brings Pop valuation to $60M. And in terms of metrics, Pop was at #15 in terms of number of transactions in July 2025. It did 63M in txns, and INR 1539 Cr in value processed.

Some interesting points here. I couldn’t find anything on Pop revenue. But just in terms of metric comparison to Kiwi:

July 2025 for Kiwi:

• 2.81M transactions

• INR 323 CR value processed

• Kiwi did FY24 - 25 GMV of ~INR 1091 Cr

July 2025 for Pop

• 63M transactions

• INR 1539 Cr in value processed

Pop doing as much GMV in a month that Kiwi is doing in a year!

And just comparing monthly metrics here, it’s doing ~22x per month more in transactions, and 4.7x more in value processed. Where Kiwi does have Pop beat on metrics is on AoV (average order value) - Kiwi has an AoV of ~INR 1607 (I’m assuming on account of it being a CC on UPI App), while Pop has an AoV of INR 244.

..but maybe doesn’t have a clear or sustainable path to monetization, and hence has reportedly lower valuation than Kiwi

Kiwi post its Series B fundraise, and despite having lower scale as compared to Pop, will be reportedly valued at $100M. Compare that to Pop, at ~22x scale in terms of number of transactions, and is valued at a maximum of $60M. My hunch here is that Pop probably isn’t making much money (since UPI is supposed to be free, and despite having a Rupay Card - PopCard, launched in partnership with Yes Bank in November 2024, I’m assuming majority of its volumes still come through regular UPI transactions, just by looking at its AoV). From the promotions and the Pop branding as a UPI rewards app, I assume it is burning a ton on cashbacks. Kiwi has probably got a premium valuation on account of some path to profitability

So, it looks like the valuation of UPI Apps with some scale will be around $60 - $100M. With everything set up, but no live transactions this seems to be ~$2.5M

The going rate for a pure-play UPI app (excluding full-stack players like PhonePe and Paytm, these aren’t just UPI Apps anymore) seems capped at ~$100M today.

• Entry valuations start around $2.5M if you’ve got the tech, compliance, and partnerships in place (but no transactions yet), which seems to be the case with Rio. It has it’s tech stack ready: Payer PSP as RBL Bank (it’s most probably using the Juspay stack, since this is a bank that Juspay uses to offer its TPAP as a service product). I also assume it has got the compliance sign offs from NPCI. And from Rio’s website, I can also see that it has tied up with Yes Bank for credit card issuance.

• It can go up to $60M+ if you have scale (like we see in the case of Pop), but it may cap out here if monetization is unclear, despite the scale.

• With a clear monetization path, like in the case of credit card on UPI, where MDR is earned on the transaction, and there is opportunity to make money as the distribution partner, this seems to go up to $100M (as we can see with Kiwi)

The CC on UPI play also seems to be how Axis & Yes are going after remitter volumes in the 4 party UPI model

Currently, while Axis & Yes Bank are top 3 in Payer PSP, Payee PSP and Beneficiary volumes (although this is probably not P2P, it’s more due to the Payee + Beneficiary leg in P2M tramsactions), they don’t have that much volume on the remitter side of things. What this means is, they don’t have as many customers, and customer accounts. Take a look at the below table. Axis is #8 in terms of remitter volumes processed, and Yes Bank doesn’t even feature in the Top 10.

But if we take a look at the 3 new age UPI Apps that we’ve talked about, they have Axis & Yes not just as the Payer PSP, but also as the banks which will issue credit cards

1. Kiwi’s Payer PSP is Axis, and its tied up with Yes, Axis & AU SFB for issuing cards

2. Rio Money’s Payer PSP is RBL (probably the Juspay stack), and it’s tied up with Yes for issuing cards

3. Pop’s Payer PSP is Yes Bank, and from what I can see, it offers a PopCard in partnership with Yes Bank, which is a Rupay CC on UPI card.

Maybe this is the strategy for them: become the bank of choice for these newer apps which are scaling, not just as the PSP partner, but as the issuing partner, which will increase # bank accounts and strengthen their dominance in UPI

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)