Account Aggregator Framework Explained: Consent, FIPs, FIUs and What Lenders Actually Get

The Account Aggregator framework lets a borrower authorise a regulated data pipe between the institutions that hold their financial data (FIPs) and the lender that wants it (FIU), brokered by an RBI-licensed NBFC-AA that moves the data but never reads or stores it. For a credit team, it replaces the emailed PDF statement with a signed, machine-readable feed.

Key facts

• YuSight has processed 1 Mn documents — bank statements, ITRs, GST filings, financial statements and bureau reports — which is why the platform treats AA JSON as one more input format to normalise, not as a replacement for the document pipeline.
• The AA is a blind courier, not a data source. Under the NBFC-Account Aggregator (Reserve Bank) Directions, 2016, an AA "shall not support transactions by customers" and no financial information "shall reside with the Account Aggregator" after it is delivered (RBI, Master Direction DNBR.PD.009/03.10.119/2016-17, 2 September 2016, updated 6 September 2024). An AA cannot enrich, score or re-share the data.
• The ecosystem is large but uneven. Sahamati's public dashboard reported 538.32 million cumulative consents fulfilled and 326.30 million cumulative accounts linked as at July 2026 (Sahamati, AA Ecosystem Dashboard). At the time RBI recognised Sahamati as the ecosystem's SRO on 5 June 2026, there were 17 operational AAs, 176 live FIPs and 1,020 live FIUs (Sahamati).
• GST returns arrive through the same pipe. RBI added GSTN as a Financial Information Provider on 23 November 2022, with Form GSTR-1 and Form GSTR-3B as the financial information, expressly "to facilitate cash flow-based lending to MSMEs" (RBI/2022-23/140).
• The ecosystem SLA is public and unforgiving. Sahamati's AA Ecosystem SLA sets FIP module availability at >99.5%, FIP API success rate at >95%, and a p95 of under 5 seconds for POST /Accounts/discover (Sahamati, AA Ecosystem SLAs v0.9.1).

Who are the four parties in the AA framework?

Four roles, and a credit team needs to be precise about which one it occupies.

Two consequences follow immediately. First, your lender entity must itself be registered as an FIU with one or more AAs before a single fetch can happen; you cannot piggyback on a technology partner's registration. Second, the AA is not accountable for data quality. If an FIP returns a truncated statement, the AA delivers the truncation faithfully. Chasing an AA over missing transactions is a category error.

An NBFC-AA needs a net owned fund of not less than ₹2 crore and an RBI Certificate of Registration. That capital floor, plus the ban on doing anything else with the data, is the whole regulatory design: the intermediary has no business model that depends on the contents of what it carries.

What does the consent artefact actually contain?

This is the part credit teams most often delegate to engineering and most often regret delegating. The consent artefact is a digitally signed JSON object, and every field in it constrains what your underwriters can legally do afterwards.

Here is Sahamati's own worked example of a one-time consent for a loan application: Source: Sahamati, Consent Artefact — one-time consent for a loan application.

The two failure modes are symmetrical. Ask for too little and you re-approach the borrower, which costs conversion. Ask for too much and you fail your own purpose-limitation test — and under the RBI Digital Lending Directions the burden of justifying data collection sits with the regulated entity, not the vendor. The working checklist for RBI digital lending compliance sets that obligation out clause by clause.

Which purpose code should a lender use?

ReBIT maintains a fixed purpose-code taxonomy. Lenders live in two of the five (Sahamati, purpose codes):

Sahamati's monitoring example pairs code 104 with fetchType: PERIODIC, a two-year consentExpiry and a DataLife of one month — the shape of a covenant-monitoring or early-warning feed rather than an underwriting pull (Sahamati, periodic consent for monitoring a loan account).

The practical rule: a 103 consent taken at application does not license monitoring after disbursement. If your early-warning system is reading from an underwriting consent, that is a finding waiting to be written up.

What data actually comes back?

The FIU calls POST /Consents, then POST /FI/request with the consent ID, then GET /FI/fetch/{sessionId} once the FIP notifies readiness (ReBIT, NBFC-AA API Specification). What arrives is encrypted XML or JSON structured per FI type.

For a DEPOSIT account — the workhorse of MSME underwriting — a fetch returns a profile block (holder name, PAN or masked PAN, mobile, address, account type), a summary block (current balance, drawing limit, opening date, status, IFSC, branch, micro/currency details) and a transactions block. Each transaction carries a type (CREDIT/DEBIT), mode (CASH, ATM, UPI, FT, CARD, OTHERS), amount, current balance, transaction timestamp, value date, narration and a reference number.

That last field list is why AA changes the analyst's job rather than removing it. The narration is still free text. "NEFT-AXISP00123456-SUPPLIER PVT LTD" arrives exactly as scrambled as it did in the PDF. Classifying that into salary, EMI outflow, GST payment, inter-company transfer or bounced cheque is the same analytical problem it always was — the framework for it is set out in the complete guide to bank statement analysis. What AA removes is parsing risk and tamper risk, not interpretation.

For GSTR1_3B, what returns is the return-level data — turnover, taxable value, tax paid, filing dates — not the invoice register. Reconciling declared GST turnover against bank credits remains a separate exercise, covered in the GST return analysis framework for Indian credit teams.

Where does AA coverage break down?

Coverage is the single biggest gap between the AA pitch and the AA experience. Three distinct failure surfaces:

1. FIP-to-AA coverage is a matrix, not a list. Not every FIP is integrated with every AA. Industry tracking in March 2026 put the ecosystem at 17 AAs of which 13 had live FIP integrations, with the leading AAs connected to 65–80+ FIPs and four AAs at zero live integrations (CASParser, State of Account Aggregator 2026). If your chosen AA is not integrated with the borrower's bank, the account is invisible — and the borrower experiences that as your product being broken.

2. FI-type coverage lags account coverage. The same tracking reported current accounts live at roughly 65 of 72 banks but fixed deposits at only about 40% of banks, and bonds, debentures, government securities, commercial paper, EPF and PPF still at "proposed" (CASParser). These are third-party observations, not Sahamati-published figures, and move month to month; re-check against your AA's live FIP list before you write a coverage assumption into policy.

3. Account types that are simply excluded. Joint accounts, NRE/NRO accounts and non-sole-proprietor entity accounts are the recurring gaps. For a partnership firm or a private limited company, AA coverage is materially thinner than for a proprietor. That matters, because the MSME files where cash-flow lending is most attractive are frequently exactly those entity types. Entity-account coverage varies by FIP and is improving; confirm current position with your AA.

What are the latency and failure modes?

Sahamati publishes a formal ecosystem SLA. These are the numbers to put in your vendor contract and your ops dashboard.

Source: Sahamati, AA Ecosystem SLAs v0.9.1.

Read the discovery line carefully: five seconds at p95 is the sanctioned target, not an aberration. A borrower journey that shows a spinner for eight seconds during discovery is inside spec. Design the front end for it.

The failure modes are mostly boring infrastructure, and Sahamati's own published case study on a single FIP is instructive: discovery success rates across four AAs sat at 33.3%, 65.5%, 76.9% and 0% on 12 August 2023, and reached 100% for all four by 12 September 2023. The causes were an API gateway bandwidth constraint, a firewall policy blocking AA discovery requests, and a specification-handling error where one mobile number mapped to multiple customer IDs and the FIP failed to return the correct 404 (Sahamati, FIP-X discovery performance case study).

Two operational lessons. A 0% success rate against one FIP is a normal Tuesday, not an outage you will be told about. And you need a fallback path, because a file that cannot complete AA discovery still has to be underwritten today.

AA vs PDF upload vs net-banking scraping

The honest summary: AA is strictly better than scraping and strictly better than PDF where it works — and it does not work often enough yet to be the only path. Every Indian lender running AA in production is also running a document pipeline behind it. Detecting the doctored PDF in that fallback lane is covered in how to detect a fake or tampered bank statement.

Worked example: a ₹40 lakh MSME working capital file

Illustrative figures for a proprietorship trading firm applying for a cash credit limit. Numbers are shaped to be realistic, not drawn from any actual borrower.

The consent requested

• Purpose code 103, fetchType: ONETIME, consentMode: STORE
• fiTypes: DEPOSIT, GSTR1_3B
• FIDataRange: 1 September 2025 to 31 August 2026 (12 months)
• DataLife: 90 days. consentExpiry: 30 days.

What discovery returned

Coverage: 2 of 4 banking relationships, plus GST. That is a good outcome, not a poor one.

Turnover assessment from the AA feed (Bank A + Bank B, 12 months)

The variance calculation: (5,94,80,000 − 5,71,40,000) ÷ 5,71,40,000 = 0.0410, so 4.1%. A single-digit positive variance is normal — exempt supplies, non-GST receipts and timing differences all sit in there. A 40% variance would be the finding.

Working capital limit, turnover method

Under the Nayak Committee approach RBI describes for limits up to ₹5 crore, working capital is assessed at a minimum 20% of projected annual turnover (RBI, MSME FAQs, updated 29 July 2025):

• Projected turnover, FY27: ₹6,60,00,000
• 25% of projected turnover: ₹1,65,00,000
• Less borrower's margin at 5% of turnover: ₹33,00,000
• Indicated MPBF: ₹1,32,00,000
• Requested limit: ₹40,00,000 — comfortably inside the indicated ceiling

What the AA feed did not settle. The co-op bank OD (₹18 lakh sanctioned) never appeared in discovery. It surfaced only in the commercial bureau report. That single gap is the argument for never treating AA as a complete liability picture — the reconciliation discipline is set out in bureau vs bank statement reconciliation.

What AA does not solve for a credit team

Be blunt with your own management about this list.

1. It does not give you financial statements. No balance sheet, no P&L, no audit report, no schedules. Spreading still runs off the ITR, the audited financials and the CMA data.
2. It does not give you the liability picture. Only the accounts the borrower links, at FIPs that are live. The bureau remains the source of truth for borrowings.
3. It does not classify transactions. Narrations arrive raw.
4. It does not verify identity beyond the account. KYC, entity constitution and borrowing authority are unchanged.
5. It does not remove the document pipeline. Property papers, GST registration certificates, Udyam certificates, board resolutions, valuation reports and ITRs still arrive as files — and every one of them has a home in the note, as set out in the credit appraisal note format used by Indian lenders.
6. It does not survive a revoked consent. A borrower can pause or revoke at any time; a monitoring feed can stop mid-tenor.

Which is the practical reason a credit stack needs both lanes. YuSight's Document Intelligence layer classifies and validates whatever arrives — tax returns, bank statements, financial statements, bureau reports — maps each document to the right entity in a multi-entity group, and normalises it into the same spread whether it came from an AA feed or a scanned PDF. Across 1 Mn documents processed, the recurring pattern is that no single Indian MSME file is ever fully covered by one channel.

FAQ

What is the Account Aggregator framework?

It is an RBI-regulated consent architecture for sharing financial data. A borrower uses an RBI-licensed NBFC-AA to authorise their banks, insurers, depositories or GSTN to send specified data to a specified lender for a specified purpose and period. The AA carries the data but is barred from reading or storing it.

What data can a lender pull through an AA?

Deposit and term deposit accounts, recurring deposits, mutual funds, equities, insurance policies, NPS and GST returns (GSTR-1 and GSTR-3B), among other FI types — but only the types your AA and that FIP actually support, and only within the date range and consent types the borrower approved.

Is Account Aggregator data legally admissible for credit decisions?

Yes. It arrives with a digitally signed consent artefact from an RBI-licensed intermediary, which is a far stronger provenance record than a borrower-emailed PDF. What matters for defensibility is that you used the data inside the purpose, FI types, date range and data life the consent specified.

Do I need to be registered as an FIU?

Yes. Only an entity registered with and regulated by a financial sector regulator can be an FIU, and it must be onboarded with each AA it wants to use. You cannot consume AA data through someone else's FIU registration.

Can I use one consent for both underwriting and monitoring?

No, not sensibly. Underwriting normally runs on purpose code 103 with a one-time fetch; monitoring runs on code 104 with a periodic fetch and a longer expiry. Reading a monitoring feed off an application-stage consent is a purpose-limitation breach waiting to be found.

Why did the borrower's account not show up in discovery?

Usually one of three things: the FIP is not integrated with the AA you are using, the account type is unsupported (joint accounts and many non-proprietor entity accounts are), or the mobile number the borrower used at your AA does not match the one registered at that bank.

Does AA remove the need for bank statement analysis?

No. AA delivers structured transactions with raw narrations. Classifying credits and debits, spotting circular transfers, identifying undisclosed EMIs and computing sustainable turnover is the same analytical work — you are simply doing it on clean input.

How long can we keep AA data?

For as long as the DataLife in the consent artefact allows, and no longer. If your credit committee cycle is three weeks, a 15-day data life is a design error, not a compliance nicety.

What happens if the borrower revokes consent mid-tenor?

The feed stops. Data you already lawfully retained under the consent's data life stays retained; further fetches fail. Any early-warning or covenant process that assumes a continuous feed needs an explicit fallback for revocation.

Key takeaways

• The AA is a data-blind courier. Coverage, quality and interpretation are your problems, not the AA's.
• Every constraint on your underwriters is written into the consent artefact: purpose code, consent mode, fetch type, FI types, data range, data life, frequency. Design it with credit policy in the room, not just engineering.
• Discovery at five seconds p95 and FIP success at 95% are the targets. Build the borrower journey and the ops dashboard around those numbers.
• AA is strictly better than PDF upload where it works. It does not yet work often enough to be the only lane, particularly for partnerships, companies, joint accounts and co-operative banks.
• AA gives you transactions and GST returns. It does not give you financials, the liability picture, or transaction classification.

Upload a messy document set and see it classified — [book a live demo](https://yuverse.ai/yusight).