What Account Aggregator Actually Solves for Lenders, and What It Leaves Untouched

The Account Aggregator framework is the most consequential piece of lending infrastructure India has built since UPI, and the sales pitch around it has drifted well ahead of what it does.

AA removes an entire class of problem from origination. It does not remove the problem that determines whether your credit decision is any good. This post is about the boundary between the two, because teams that misjudge it build roadmaps on the wrong assumption.

Where the framework stands

As of 31 March 2026, more than 2.88 billion financial accounts were enabled for consent-based sharing. On the framework's fourth anniversary the Finance Ministry reported 112 institutions live as both FIP and FIU, 56 as FIP only and 410 as FIU, with over 112 million users having linked accounts.

The lending volume is now material rather than promising. Sahamati estimates AA-enabled lending at ₹3.82 lakh crore in FY26, with banks accounting for 47.3% of that value in the second half — roughly matching NBFCs, which is the clearest sign the framework has moved past early-adopter fintechs. Notably, new-to-credit borrowers made up 18.2% of AA-enabled originations by volume.

This is no longer a pilot. It is also not universal, and the gaps are specific.

What AA genuinely solves

Extraction. Data arrives as structured JSON. No parsing, no OCR, no scanned-page handling, no bank-specific template maintenance. For anyone who has maintained a PDF parser across a thousand bank formats, this is not a small thing.

Document authenticity. The data comes from the FIP over an encrypted channel. There is no artefact to forge. Every tampering vector described in our post on bank statement fraud — edited amounts, broken balance trails, metadata anomalies, template regeneration — disappears entirely on the AA path.

Speed and drop-off. Fetches from major FIPs complete in seconds rather than the days a document collection cycle takes, and removing a six-month statement upload from an application flow measurably reduces abandonment.

Consent as a legal artefact. Purpose, data range, frequency and retention are all recorded in a machine-readable consent the borrower can inspect and revoke. This is a stronger position than holding PDFs a borrower emailed you.

What AA does not solve

Categorisation is completely untouched

This is the misconception that matters most, and it hides inside the word "structured."

Structured JSON tells you a transaction occurred on a date, for an amount, in a direction, with a narration string. It does not tell you what the transaction was. Whether that debit was an EMI or a supplier payment, whether that credit was a sale or a loan disbursal or the borrower moving money between their own accounts — none of that is in the feed. It has to be inferred from the same narration string a PDF would have given you.

And the narration is the weak link. It is whatever the FIP chose to populate the field with, and richness varies substantially across institutions. Some FIPs deliver narration comparable to the statement; others truncate.

So AA eliminates the extraction error rate and leaves the categorisation error rate exactly where it was. Since categorisation is where tools actually diverge — we measured a 92.8% versus 80.3% spread on 200,001 identical transactions — moving to AA changes nothing about the accuracy of the analysis sitting on top of it. A loan disbursal misread as a trade receipt is misread identically whether it arrived as JSON or as a scanned PDF.

Put plainly: AA solved the easy problem. The hard problem is unchanged, and now arrives faster.

The borrower still chooses what you see

Consent is account-level and the borrower selects which accounts to link. A borrower with five accounts can share three.

This is the same problem as document collection, with a worse failure mode. A stack of PDFs looks incomplete — you can see that you were handed three statements. A structured API response with clean JSON and no gaps feels authoritative and complete. The absence of the other two accounts is invisible.

Cross-verification against GST filings and bureau data remains as necessary as it ever was. The variance between declared turnover and banked credits is often the only thing that reveals an account you were never shown.

Coverage is thinnest where you need it most

Headline account numbers obscure product-level gaps that hit specific lending segments hard.

Current accounts for sole proprietors were supported by roughly 65 of 72 banks as of early 2026 — good, but not complete, and the missing institutions skew toward exactly the cooperative and regional banks that serve micro-enterprise borrowers. Fixed and recurring deposits were supported by only around 40% of banks, which matters whenever you are assessing liquid assets rather than flow.

There is also no universal interconnection. Not every FIP is connected to every AA, so a borrower's bank may be reachable through one aggregator while their insurer is reachable only through another. Several licensed AAs have no live FIP integrations at all. Your AA choice constrains your coverage, and that constraint is not visible from licence status.

The practical consequence is that AA is an additional channel, not a replacement one. Any lender serving MSME or semi-urban segments needs both paths — AA where available, document collection where not — which means maintaining statement analysis capability regardless.

Consent scope decides whether you can monitor, and it is decided at origination

This is the operational trap, and it is expensive.

A consent artefact specifies purpose, data range, fetch frequency and duration. A one-time consent taken to underwrite a loan authorises exactly that. It does not authorise fetching the borrower's data again in month seven to see how they are doing.

Ongoing monitoring requires a recurring consent with a duration covering the loan tenure, and it has to be requested at origination — when the borrower is motivated to cooperate because they want the money.

Teams routinely discover this after disbursal. Going back to a performing borrower for fresh consent is awkward and lowers your conversion on the ask. Going back to a stressed borrower is close to impossible, and a borrower who declines has told you something you now cannot act on with data.

If monitoring is anywhere on your roadmap, the consent design has to reflect it before your first origination, not after.

The FIP obligation roughly doubles the integration

Under a change to the RBI Master Direction, a regulated entity joining as an FIU must also join as an FIP if it holds financial information falling within the FIP definition. The RBI made this change because eligible institutions were consuming data from the ecosystem without contributing their own.

The engineering consequence is that a project scoped as "pull bank statements for underwriting" is actually two builds: the FIU module that requests and decrypts, and an FIP module that receives consent artefacts, validates them, and serves your own loan data to any FIU that asks with valid consent — including competitors. Budgets built on the FIU side alone are wrong by roughly half.

Consent revocation is a credit signal

Borrowers can revoke consent at any time. Most lenders treat a revocation on a live loan as an administrative event.

It is closer to a mandate cancellation. A borrower who withdraws your visibility into their banking has made a decision, and the decision is rarely arbitrary — it typically precedes something they would prefer you not see. Our NACH return code reference makes the parallel argument about codes 06 and 61: a deliberate withdrawal of a payment authority deserves more weight than a funds shortfall, not less.

Revocation events should be routed into the monitoring queue with the same urgency as a bounce, and the loss of visibility should itself trigger a review rather than simply ending data collection quietly.

Designing the consent for a lending lifecycle

Four parameters, each with a decision attached.

Purpose. Must genuinely match the use. A consent taken for onboarding is not a consent for monitoring.

Data range. How far back you fetch. Twelve months supports seasonality and trend analysis; six is often the minimum that supports meaningful month-on-month reading. Shorter ranges reduce friction and destroy the trend.

Frequency. One-time for pure origination. Recurring for anything that continues after disbursal.

Duration and data life. Duration governs how long you may keep fetching; data life governs how long you may retain what you fetched. These are separate parameters and are routinely confused. Set duration against loan tenure, not against the application window.

The governing structure sits under the RBI Master Direction for NBFC-Account Aggregators, with Sahamati now formally recognised by the RBI as the framework's self-regulatory organisation as of June 2026 — which gives the existing ecosystem coordinator statutory standing rather than introducing a new rulebook.

The summary a credit team needs

AA gives you faster, cleaner, unforgeable data from the accounts a borrower chooses to show you, at institutions that happen to be connected to the aggregator you picked.

It does not tell you what any of it means, it does not close the accounts you were not shown, and it will not let you look again after disbursal unless you asked for that permission at the start.

The analysis layer above AA is doing exactly the work it was doing before. Choosing it on the assumption that AA solved the problem is how lenders end up with a fast pipeline feeding a weak decision.

Frequently asked questions

Does Account Aggregator replace bank statement analysis? No. AA replaces the collection and extraction of statements. Categorisation, obligation identification, income derivation, fraud pattern detection and conduct analysis all still have to be performed on the data once it arrives, and none of them get easier because the format is JSON.

Can lenders use AA data for ongoing loan monitoring? Only if the consent was obtained with a recurring fetch frequency and a duration covering the monitoring period. A one-time consent taken at underwriting does not permit later fetches, and obtaining fresh consent from an existing borrower is materially harder than obtaining it at origination.

What percentage of borrowers can be served through AA alone? Coverage varies by segment and product, and is weakest for current accounts at smaller banks and for term deposits. Lenders serving MSME and semi-urban segments generally need both AA and document-based paths, since going AA-only excludes borrowers whose institutions are not connected.

Can an Account Aggregator read my financial data? No. AAs operate as encrypted conduits between the data provider and the data user. They cannot read, store or use the data passing through them, and their role is limited to managing the consent.

Is the data in an AA feed richer than a PDF bank statement? Not necessarily. It is cleaner and machine-readable, but transaction narration — the field categorisation depends on — is whatever the FIP populates, and richness varies by institution. In some cases a bank's PDF statement carries more descriptive narration than its AA feed.

---

Fiscus ingests AA-delivered JSON natively and analyses it through the same categorisation, fraud and conduct logic applied to document-based cases, so both channels produce identical output. Book a parallel evaluation on cases your team has already assessed.