Open Banking 2.0: When APIs Stop Sharing Data and Start Taking Action

India has always built financial infrastructure in layers. Aadhaar gave every citizen a verifiable digital identity. UPI turned real-time payments into a…

India has always built financial infrastructure in layers. Aadhaar gave every citizen a verifiable digital identity. UPI turned real-time payments into a public utility. The Account Aggregator (AA) framework brought consented data sharing into the same stack. Each layer made the next one possible.

The fourth layer is now taking shape: action. Not just "here is your financial data" but "do this with my financial assets, on my behalf, with my consent." India's open banking is moving from read to write, from pipes to rails.

How India's Open Banking Was Different From Day One

Most countries secured open banking onto existing payment regulation. India built it from scratch as Digital Public Infrastructure (DPI), open-source and interoperable from the start.

The Account Aggregator framework was launched in 2021. And, it was the RBI's response to a specific structural problem i.e. financial data in India was scattered across banks, mutual funds, insurance companies, pension funds, and tax authorities. An MSME owner applying for a loan had to physically collect statements from multiple institutions, a process that often took weeks. Lenders, unable to verify the data efficiently, either rejected applications or priced risk conservatively.

The AA framework addressed this by creating a new type of regulated entity, the Account Aggregator, that sits between data sources (Financial Information Providers, or FIPs) and data consumers (Financial Information Users, or FIUs). It routes encrypted financial data with explicit user consent but never stores it. The AA only manages consent tokens. That design choice made it workable for regulators, banks, and privacy advocates at the same time.

The Scale India Built

By the end of 2025, over 2.61 billion financial accounts had been enabled for data sharing through the AA network. More than 252 million users had linked accounts. There were 410 registered FIUs consuming that data, with 126 institutions operating as both FIPs and FIUs.

The ecosystem crossed 100 million consents in 2024, confirming that the framework had moved from pilot to live infrastructure. UPI took about three years to reach comparable adoption velocity after launch. AA is on a similar curve, with the difference that many of the use cases are still being worked out.

The change has been most visible in MSME lending. A lender on the AA network can now receive 12 months of bank statements, GST filing history, and investment data in under two minutes, with verified consent, via API. Loan underwriting that previously required physical document collection now happens programmatically. The fraud risk is also lower since the data comes directly from source institutions rather than from borrowers.

OCEN: Where Data Becomes Action

The Open Credit Enablement Network (OCEN) is where the action API story gets concrete. Built on top of the AA data layer, OCEN provides a standardised protocol for credit APIs that lets lenders offer, disburse, and service loans through any digital platform that integrates it. A marketplace, an accounting tool, an agri platform, a logistics aggregator can all become credit distribution channels without taking on a lending licence themselves.

The numbers reflect real traction. In 2025, OCEN facilitated around 70,000 loans totalling over Rs 1,600 crore in disbursements. In Q1 2026 alone, it facilitated 35,485 loans worth Rs 1,124 crore, a 468% jump in disbursement value year-on-year. GeM Sahay, an OCEN-based lending platform built for government marketplace sellers, now has six lenders live with more integrating.

What sets OCEN apart from older lending APIs is that the entire credit lifecycle runs through standardised API calls. The loan offer, acceptance, agreement, disbursement instruction, and repayment mandate all happen via API. The borrower's consent is embedded at each step. No human touches the transaction. That is what makes it an action API rather than just a data-sharing arrangement.

Credit on UPI: Payments and Credit on the Same Rail

The NPCI expanded UPI's scope in 2023 to allow pre-sanctioned credit lines at banks to be accessed directly through UPI. In February 2025, this was extended to small finance banks, and from August 2025, users could make UPI payments from pre-approved credit lines from banks and NBFCs as well.

The practical change is significant. A customer no longer has to receive a loan disbursement into their bank account and then initiate a separate UPI payment. The credit line sits inside the UPI payment flow itself. The lender extends credit at the point of transaction and collects repayment against the same instrument.

For borrowers with limited credit bureau history but years of UPI transaction data, this opens up an underwriting signal that traditional scoring models miss entirely. For product teams building in India, it changes how embedded credit works. Rather than building a separate lending product inside an app, you are surfacing a UPI payment option that already includes a credit facility the customer holds. The experience is much cleaner for the end user.

The Problems That Remain

Bank API quality is uneven. The AA framework requires banks to participate, but implementation quality varies a lot across FIPs. API uptime, response times, and data completeness are inconsistent enough that lenders building real-time underwriting products have to write significant error handling and fallback logic just to make the basic flow reliable.

Consent drop-off is a real product problem. The AA consent journey is technically well-designed, but it is unfamiliar to most users and many abandon it partway through. FIUs are spending considerable product resources on consent UX, and the infrastructure layer has not made this easier for them.

The action layer also does not yet have a clear liability framework. When a data API returns incorrect information, the harm is informational. When an action API sends money to the wrong account or initiates an unauthorised payment, the harm is financial and often cannot be reversed. As OCEN scales and Credit on UPI expands, the question of who is responsible for a failed or fraudulent instruction needs clearer answers than currently exist.

Non-bank FIPs are lagging as well. Insurance companies, pension funds, and mutual fund platforms are nominally registered as FIPs but slow to build reliable API access. The AA framework's value across the broader financial system depends on these institutions improving, and the timeline for that is uncertain.

Where This Goes

For fintechs, the opportunity is no longer just accessing customer data. That problem is gradually getting solved.

The harder challenge is becoming the application that customers trust enough to act on their behalf.

A customer might be willing to share a bank statement once. Giving an app permission to move money, repay a loan, switch investments, or manage a credit line automatically is a very different level of trust.

That's where the next wave of competition is likely to happen.

The winners may not be the companies with the most APIs. They may be the companies that build the best consent experiences, the most reliable execution layers, and the strongest customer confidence.

Because in Open Banking 2.0, technology enables the action.

Trust enables the adoption.

Reference :