India's Account Aggregator network: what builders need to know in 2026

India has built a national infrastructure for sharing financial data with user consent. As of March 2026, 2.88 billion financial accounts are enabled on the framework. And yet, if you built a lending product in India using only this infrastructure, roughly 62% of your applicants would fail at the data-collection stage.

That gap is the most important thing to understand about the Account Aggregator (AA) network before you build on it.

What an Account Aggregator actually does

An Account Aggregator is a licensed NBFC regulated by the Reserve Bank of India under its 2016 Master Directions. Its sole function is to relay financial data between regulated institutions, on the user's explicit, time-bound, purpose-specific consent.

The critical design principle: the AA never reads, stores, or processes the data it carries. Data flows encrypted from the source institution to the destination institution, with the AA as a blind pipe in the middle. This is what separates the AA model from the older screen-scraping approach: in that model, third parties held your credentials and pulled bank statements on your behalf. With AA, the data never touches the intermediary in readable form.

The framework went live commercially in September 2021, built on DEPA, the consent-layer architecture designed by NITI Aayog, and operationalised through ReBIT, RBI's technology standards body, which defines the API specifications all participants must implement.

The four parties in every AA transaction

The consent flow, end to end

Every AA data-sharing transaction follows the same sequence regardless of the data type or the institutions involved:

1. You (the user) initiate a data request in an FIU's product — typically by clicking 'Get my bank statement' in a lending or financial planning app.
2. The FIU sends a consent request to its AA partner, specifying: data type, source FIP, date range, purpose, consent validity period, and fetch frequency (one-time or recurring).
3. The AA sends you a notification via the AA app (Finvu, OneMoney, INK, Anumati, etc.), showing exactly what data is being requested, for what declared purpose, and by which entity.
4. You approve or reject. If approved, the consent is recorded as a cryptographically signed artefact, timestamped and tied to the specified parameters.
5. The AA sends a data fetch request to the relevant FIP, attaching the consent artefact. The FIP verifies the consent.
6. The FIP returns the financial data encrypted with the FIU's public key. The AA cannot decrypt this payload.
7. The AA routes the encrypted payload to the FIU.
8. The FIU decrypts and processes. Typical time from user approval to FIU data receipt: 2–5 seconds on a well-connected FIP.

Revocation is symmetric. You can revoke consent at any point through any AA app, including one embedded in a different product than the one you used originally. Revocation is immediate: future data fetches stop. Data already retrieved under valid consent remains in the FIU's possession.

Data types available today — and the notable gaps

The licensing picture: who needs what

Most builders evaluating AA ask the wrong question first. Before asking 'how do I integrate?', the question is 'which role am I in this ecosystem?'. The licensing requirement depends entirely on that.

If your product consumes financial data (lending, wealth management, personal finance), you are a Financial Information User. Register with Sahamati, the industry alliance managing network interoperability; no RBI licence is required. What you need: Sahamati FIU registration, a signed agreement with your chosen AA partner, compliance with the purpose and data-minimisation constraints in the consent specification, and technical integration via the ReBIT API spec.

If your product holds financial data as a bank, NBFC, insurer, or regulated depository, you are required to implement FIP APIs. This is infrastructure work mandated by your regulator, not a product decision you opt into.

Where adoption actually stands in 2026

The numbers tell a story of strong infrastructure and uneven penetration:

• 2.88 billion financial accounts enabled on the framework as of March 2026
• 252.9 million users with linked AA accounts as of December 2025
• 410 entities registered as Financial Information Users
• 17 RBI-licensed Account Aggregators, of which 11 are in active production operation

The penetration gap is where it gets operationally important. Approximately 38% of borrowers have accounts on the AA framework — meaning 62% still require PDF-based bank statement analysis. Metro cities run at 45–50% AA adoption; Tier 2 and 3 cities are at 20–30%.

An NBFC that launched a lending product in India using AA as the only data source reported a 62% application failure rate at the data-collection stage. The customers existed, their banks existed, but the AA API path failed or was not available for their accounts.

The picture is improving. GSTN joining as an FIP opened income-verification for business borrowers without requiring IT returns or bank statements. Income tax return data is rolling out through Protean. The 60% month-on-month growth in volume that Sahamati has reported suggests the gap is closing. It is not closing fast enough to drop the fallback path yet.

Three integration paths, and how to choose

Your path depends on which role you occupy in the ecosystem.

Building as an FIU (the common case)

Register with Sahamati, select an AA partner (Finvu and Anumati have the broadest FIP coverage; NESL NADL has strong institutional presence; OneMoney was first to market and has deep bank relationships), sign the FIU-AA agreement, and integrate against the ReBIT API spec. The AA partner exposes REST APIs; the underlying protocol is standardised, so the logical flow is identical across AA partners. Differences appear in reliability, support, pricing, and which specific FIPs each AA has live agreements with.

Realistic timeline: 3–6 months from initial API access to production traffic. The technical integration is not the long pole; Sahamati registration and the inter-party agreements take time.

Building as an FIP (regulated entities)

If you hold financial data as a regulated entity, you implement the FIP-side ReBIT APIs. This involves certificate management, conformance testing against the Sahamati sandbox, and interoperability verification. The spec is well-defined; the work is engineering and compliance, not architecture decisions.

Pushing the edges of AA scope

Some products are using the consent infrastructure for verification use cases adjacent to, but not squarely within, the original financial data-sharing mandate: employee financial wellness tools, credit decisioning for non-banking products, income smoothing applications. These use cases are possible within the framework but require careful attention to the consent purpose fields, which are strictly defined. Using a consent purpose of 'loan underwriting' for a payroll advance product is the kind of edge case that generates regulatory attention. Define purpose accurately before you build.

What breaks in production — the parts most guides omit

• FIP API reliability is uneven. Not all banks have equally consistent AA-side APIs. Some public sector banks can hit 10–15% failure rates during peak hours. Build retry logic with exponential back-off, and surface a 'we are retrying, please wait' state rather than a hard error. Do not treat a first-attempt failure as a terminal event.
• The 62% gap hits hardest in specific geographies. If you are building for urban professionals at established banks, AA coverage is high. If you are building for Tier 2/3 borrowers at co-operative banks or regional rural banks, the gap is real and persistent. Know your user profile before you set your architecture.
• Consent revocation is immediate and comes from any AA app. A user who granted consent in your app can revoke it in Finvu's standalone app. Your product needs to handle 'consent revoked' gracefully: build a clear re-consent flow, not an opaque failure screen.
• Recurring consent expiry is a silent failure mode. If you set up a 12-month recurring consent for loan monitoring, the consent expires on its set date. Build a re-consent notification flow that triggers before expiry, not after the next fetch fails.
• The data format is genuinely standardised. ReBIT's JSON/XML schema means one parser handles data from SBI, HDFC, Axis, and a regional co-operative bank. This is the part of the AA experience that is better than most engineers expect, given how inconsistent bank data has been historically. Edge cases exist in very old historical ranges, but the schema consistency is solid.

EPFO joining the network as an FIP through mid-2026 will be the largest data-type expansion since GSTN was added. Provident fund data gives lenders a workforce-history signal that has never been accessible programmatically. Watch this space: when PF data flows through AA, the income-verification picture for salaried borrowers in India changes materially. Whether that change translates into a safe AA-only architecture depends on when EPFO's API reliability matches its paper coverage, which is a separate question from when the licence is issued.