A small business owner walks into a bank to apply for a working capital loan. The loan officer asks for six months of bank statements, the last two years of GST returns, insurance policies, and mutual fund statements. The business owner spends the next week collecting physical documents from four different institutions, getting them notarised, and delivering them in person. The bank takes another three weeks to verify the documents, discovers discrepancies in the self-reported income, and asks for more documentation. The entire process takes two months. For a loan of Rs 5 lakh.
The Account Aggregator framework was built to make this process take five minutes.
What exactly is an Account Aggregator?
An Account Aggregator is a new type of NBFC — registered with the RBI — that does not hold your money, does not hold your data, and does not make lending decisions. It does exactly one thing: with your explicit consent, it fetches your financial data from the institutions that hold it and delivers that data to the institution that needs it.
The RBI issued the Master Direction – Non-Banking Financial Company - Account Aggregator (Reserve Bank) Directions, 2016 to establish this new regulatory category. The press release announcing the formal notification captured the scope:
"No entity other than a company shall undertake the business of an Account Aggregator. Further, no company shall commence or carry on the business of an Account Aggregator without obtaining a certificate of registration from the Bank."
The key design principle is that the AA is a data-blind pipeline. It transmits encrypted financial data from the institution that holds it to the institution that needs it, but cannot read, store, or monetise that data itself. This is fundamentally different from the data aggregation models in other countries, where third-party aggregators often retain and commercialise customer data.
Why does India need a consent pipeline when banks already share data?
Because the existing data-sharing infrastructure is fragmented, opaque, and not controlled by the customer. When a bank checks your CIBIL score, you have limited visibility into what data was pulled and no control over how long the inquiry stays on your record. When a lending app asks you to upload bank statements as PDFs, those documents sit on the app's servers indefinitely. When a government subsidy scheme requires income verification, the applicant bears the burden of collecting and submitting proof.
The AA framework inverts this model. The customer — not the institution — controls the flow of data. Every data request requires affirmative consent, specifying what data is being shared, with whom, for what purpose, and for how long. The consent is digitally signed, time-limited, and revocable. The institution receiving the data cannot retain it beyond the specified period.
The November 2019 Technical Specifications for all participants of the Account Aggregator (AA) ecosystem RBI/2019-20/96 operationalised this architecture:
"The NBFC-AA consolidates financial information of a customer held with different financial entities, spread across financial sector regulators adopting different IT systems and interfaces. In order to ensure that such movement of data is secured, duly authorised, smooth and seamless, it has been decided to put in place a set of core technical specifications for the participants of the AA ecosystem."
Reserve Bank Information Technology Private Limited (ReBIT) designed the API specifications, ensuring that every participant — whether a public sector bank, a private NBFC, or a fintech lender — uses the same data format and consent protocol.
Who are the four parties in an AA transaction?
Every AA transaction involves four roles:
The Financial Information Provider (FIP) is the institution that holds your data — your bank, your insurance company, your mutual fund house, your tax filing service. FIPs connect to the AA ecosystem through standardised APIs and release data only upon receiving a digitally signed consent artefact from the AA.
The Financial Information User (FIU) is the institution requesting your data — typically a lender evaluating a loan application, but it could also be a wealth manager, an insurer, or a government agency. The FIU sends a data request through the AA, specifying exactly which data points it needs.
The Account Aggregator (NBFC-AA) sits between the FIP and the FIU. It authenticates the customer's consent, routes the request to the correct FIP, receives the encrypted data, and delivers it to the FIU. At no point does the AA decrypt or store the data.
The Customer — the person whose data is being shared — is the only party that can authorise the flow. Without their consent, the AA cannot initiate any data transfer. The consent artefact specifies the scope (which accounts), the purpose (loan evaluation, insurance underwriting, etc.), the frequency (one-time or recurring), and the duration (how long the FIU may retain the data).
Why did the RBI require entities to join as both FIP and FIU?
A problem emerged as the ecosystem grew: some institutions were joining the AA framework only as Financial Information Users — consuming data from others without contributing their own data to the system. Banks were pulling insurance data and mutual fund statements through AAs but not making their own customer data available through the framework.
The October 2023 circular on Joining the Account Aggregator Ecosystem as Financial Information User RBI/2023-24/77 (since withdrawn) closed this gap:
"It has been observed that certain entities, which are eligible to join Account Aggregator (AA) ecosystem as Financial Information Provider (FIP), have onboarded as Financial Information User (FI-U) only. Consequently, such entities are accessing financial information from other FIPs but are not providing the financial information held by them. As such, with a view to ensure efficient and optimum utilisation of the AA ecosystem, it has been decided that regulated entities of the Bank joining the AA ecosystem as FI-U shall necessarily join as FIP also, if they hold the specified financial information and fall under the definition of FIP."
This was a critical intervention — and it effectively amended the original AA framework by making FIP participation mandatory rather than optional. The circular superseded the earlier voluntary approach where entities could cherry-pick which role to play. A data-sharing ecosystem only works if the sharing is reciprocal. If banks can pull mutual fund data but refuse to share bank statements, the ecosystem becomes lopsided and the customer does not benefit from the full potential of the framework.
How does the AA framework change lending?
The transformation is most visible in MSME lending — precisely the segment where the credit gap is largest. Traditional lending requires collateral and audited financials. Small businesses often have neither. What they do have is a trail of transactions: GST payments, bank account cash flows, supplier invoices, insurance premiums. This data, taken together, paints a picture of creditworthiness that is more accurate than a balance sheet prepared once a year.
The Standing Advisory Committee on MSME Credit (Meeting of the Standing Advisory Committee to Revi) recognised this potential, discussing how AAs could enable cash-flow-based lending for the MSME sector. The March 2025 meeting (Meeting of the Standing Advisory Committee to Revi) continued this theme, reviewing the flow of credit to MSMEs and the role of digital infrastructure in closing the lending gap.
The AA framework also enables what traditional lending cannot: real-time data. Instead of evaluating a borrower based on six-month-old bank statements, a lender can — with the borrower's recurring consent — receive updated transaction data monthly or quarterly. This enables dynamic credit monitoring, where the lender can adjust credit limits or flag early warning signs without waiting for the borrower to submit updated documents.
What does the consent architecture actually require?
The consent framework is the most technically detailed component of the AA Directions — and the feature that distinguishes India's model from every other data-sharing regime globally. The original Master Direction established the foundational rule: "No financial information of the customer shall be retrieved, shared or transferred by the Account Aggregator without the explicit consent of the customer."
The consent is not a generic "I agree" checkbox. The Direction requires a standardised consent artefact containing seven mandatory fields: identity of the customer, the nature of the financial information requested, the purpose of collection, the identity of recipients, a notification URL for every access event, consent creation and expiry dates with the AA's digital signature, and any additional attributes the RBI may prescribe. The November 2025 AA Directions carried these requirements forward verbatim.
Consent is also revocable at any time — and the revocation can be partial. A customer can revoke consent to share data from one account while maintaining consent for another. Upon revocation, a fresh consent artefact must be issued to the Financial Information Provider. This granularity means a customer who authorised a lender to pull six months of bank statements for a loan evaluation can revoke that access the day after the loan is disbursed, and the lender must delete the data.
The Direction also embeds a fundamental property right:
"The financial information pertaining to the customer shall not be the property of the Account Aggregator, and not be used in any other manner."
This single sentence prevents AAs from ever becoming data brokers. The information passes through them but never belongs to them. Combined with the data security requirement that an "NBFC-AA shall not request or store customer credentials (like passwords, PINs, private keys) which may be used for authenticating customers to the Financial Information providers," the architecture ensures that AAs cannot accumulate either data or access credentials. They are, by regulatory design, data-blind intermediaries.
Which entities have been brought into the ecosystem?
The AA framework launched with banks and NBFCs as the primary participants. Since then, the RBI has progressively expanded the ecosystem by including new categories of Financial Information Providers.
In November 2022, the RBI issued a circular including GSTN as a Financial Information Provider (since withdrawn) under the AA framework. The stated purpose was direct: "With a view to facilitate cash flow-based lending to MSMEs, it has been decided to include Goods and Services Tax Network (GSTN) as a Financial Information Provider (FIP) under the Account Aggregator (AA) framework." GST Returns — specifically Form GSTR-1 and Form GSTR-3B — became shareable financial information. The Department of Revenue was designated as GSTN's regulator for this specific purpose. This was a significant expansion because GST data provides the most accurate real-time picture of a small business's revenue — far more reliable than self-reported financials.
How does this connect to the Clearing Corporation of India?
In February 2024, the RBI expanded the AA ecosystem by including CCIL as a Financial Information Provider:
The Inclusion of Clearing Corporation of India Limited as a Financial Information Provider under Account Aggregator Framework RBI/2023-24/125 (since withdrawn) brought government securities holdings and money market transaction data into the AA ecosystem.
This is significant because it means institutional investors — banks, primary dealers, NBFCs — can now share their investment portfolio data through the AA framework. For regulatory supervision, this creates the possibility of real-time portfolio aggregation across institutions, which is far more powerful than the periodic reporting that currently underpins the RBI's supervisory architecture.
What guardrails protect customer data?
The AA framework was designed with data protection as a structural feature, not an afterthought. Three constraints are embedded in the architecture:
First, AAs cannot store data. The technical specifications require that data flows through the AA in encrypted form and is deleted from the AA's systems after transmission. The AA has no ability to build a database of customer financial information.
Second, consent is granular and revocable. A customer does not give blanket permission for an institution to access "all financial data." Each consent artefact specifies exactly which accounts, which data points, which time period, and which purpose. The customer can revoke consent at any time, and the FIU must delete the data upon revocation.
Third, the NBFC Registration, Exemptions and SBR Framework Directions (Reserve Bank of India (Non-Banking Financial Compa) classify AAs within the Scale Based Regulation framework, ensuring they are subject to the same governance, audit, and compliance requirements as other regulated NBFCs — despite holding no customer funds.
The AA ecosystem, by April 2026, has moved from regulatory concept to operational infrastructure. It represents India's answer to a global question: in a world where financial data is the most valuable asset, who should control it? India's answer is unambiguous — the customer.
Also in this series:
- Who Controls Your Lending App? How the RBI Cracked Down on Digital Lending
- NBFC Regulation: The Complete Timeline
Last updated: April 2026