The account aggregator framework is a Reserve Bank of India (RBI) regulated system that lets a person share their financial data between regulated institutions through a licensed consent manager. It replaces paper statements, screen scraping, and shared passwords with a single, revocable digital consent. If you have ever emailed a PDF bank statement to get a loan, this is the system designed to end that step.
India’s account aggregator framework went live commercially in September 2021. It is one of the first national-scale data sharing systems built on a consent-first, data-blind design, and it now underpins a growing share of lending, wealth, and personal finance flows. Before we get into how it works, it helps to understand where it fits within broader KYC compliance and why regulated data sharing matters for every modern fintech.
If you are a fintech or lender looking to connect to this pipe, you can start an integration with HyperVerge alongside your AA rollout.
This guide covers what the framework is, why it was built, the roles inside it, how a single data-sharing request moves end to end, the consent artefact that makes it work, the licensed operators, real use cases, and how to participate as either a user or a fintech.
What Is the Account Aggregator Framework?
At its simplest, the account aggregator framework is a consent-based financial data sharing system regulated by the RBI. An account aggregator, formally an NBFC-AA, is a licensed non-banking financial company whose only job is to move financial data from an institution that holds it to an institution that needs it, with the user’s explicit consent and nothing more.
Definition and Regulatory Basis
The framework was introduced through the RBI’s 2016 Master Direction on NBFC-Account Aggregators. It defines a new class of non-banking financial company whose sole activity is consent-managed data transfer. AAs cannot lend, cannot advise, and cannot store or read the user’s financial data. They act only as a neutral pipe. The framework went into commercial operation in September 2021 after several years of pilot work across banks and technology providers. You can read the underlying regulations on the RBI’s official site.
The Ecosystem Today
The ecosystem now spans banks, NBFCs, insurers, asset management companies, depositories, and government data sources. A growing list of licensed NBFC-AAs operates consumer-facing apps and enterprise APIs, and an even larger set of lenders, wealth platforms, and personal finance apps consume data as users. As of December 31, 2025, the framework counted 2.61 billion financial accounts enabled for data sharing and 252.9 million users with linked accounts, with 126 institutions operating as both FIP and FIU and another 50 as FIP-only. For the latest public numbers on accounts enabled, consents fulfilled, and live participants, refer to the ecosystem dashboard published by Sahamati, the industry alliance that coordinates the framework.
With that settled, the next question is why this architecture was worth building in the first place.
Why the AA Framework Exists
Before the AA framework, sharing financial data in India was slow, fragile, and often unsafe. The framework was designed to fix a very specific set of problems that held back digital lending, advisory, and inclusion.
The Fragmented Data Problem
Most pre-AA data sharing happened through 3 channels: users uploading scanned PDF statements, institutions screen-scraping net banking portals, or users handing over login credentials. Each one had obvious issues. PDFs can be doctored or outdated. Screen scraping breaks every time a bank updates its UI and depends on storing credentials. Credential sharing violates almost every security guideline a bank publishes. None of these scale, and none of them respect the user’s control of their own data.
The Consent Gap
The deeper issue was consent. When a user emailed a statement, they had no record of what was shared, no way to limit how long the data stayed with the receiver, and no way to pull it back. Consent was an email, not an artefact. The AA framework was designed to close that gap by making consent structured, machine-readable, revocable, and auditable. India was one of the first countries to build a national framework around this idea, and it has become a reference point for other regulators studying consent-based data systems.
FIP, FIU, and NBFC-AA Roles
The account aggregator framework splits the world into 3 roles. Understanding them is the fastest way to understand how the system behaves.
Financial Information Providers (FIPs)
FIPs are the institutions that hold a user’s financial data. The official list of FIP categories published by the Department of Financial Services includes banks and banking companies, non-banking financial companies, asset management companies, depositories and depository participants, insurance companies, insurance repositories, the Central Recordkeeping Agency, the Goods and Services Tax Network (GSTN), and the Clearing Corporation of India Limited, with scope to add other entities as identified by the RBI.
For the official position on in-scope FIP categories, see the Department of Financial Services framework page.
Financial Information Users (FIUs)
FIUs are the institutions that consume data. Lenders use AA data for underwriting. Wealth managers use it to build a consolidated view of a client’s holdings. Personal finance apps use it for budgeting and cash-flow analytics. Insurance distributors use it for income-based risk assessment. An FIU must itself be regulated by a financial sector regulator such as RBI, SEBI, IRDAI, or PFRDA, which means the framework never allows raw financial data to flow to an unregulated party.
NBFC-AA: The Consent Manager
The NBFC-AA sits between the FIP and the FIU. It holds the user’s handle, shows the user every data request, captures consent, moves encrypted data from FIP to FIU, and keeps an audit log. It never decrypts the data. This is the data-blind principle, and it is what makes AAs different from traditional data aggregators. An NBFC-AA must hold an RBI licence, and it cannot conduct any other business, which removes the conflict of interest that exists when a lender or wealth platform also aggregates data.
With the roles in place, it is easier to see how a single data-sharing request actually moves through the system.
The 6-Step Data Sharing Process
Every AA data request follows the same 6-step flow, regardless of the FIU or the data type. This is the process AI overviews tend to cite, and it is the part most worth committing to memory.
Step 1: User Registers with an AA
The user creates an AA handle by installing an AA app such as Finvu, OneMoney, or CAMSFinServ and completing a basic identity check using mobile number and, in most cases, Aadhaar. The handle is portable across FIUs and looks like a username paired with the AA’s domain.
Step 2: Link Financial Accounts
The user links their bank accounts, demat accounts, mutual funds, or other sources to the AA. The AA app discovers accounts at each FIP using the mobile number on file, and the user confirms ownership through an OTP from the FIP. Linking is a 1-time action per account.
Step 3: FIU Raises a Consent Request
When a user applies for a loan, opens a wealth account, or requests an income-based insurance quote, the FIU sends a consent request to the user through the AA. The request specifies the data types requested, the purpose, the duration, the frequency of access, and the expiry date.
Step 4: User Approves Consent
The user sees the request inside their AA app and either approves, modifies, or rejects it. Approval creates a consent artefact, a digitally signed record that binds the FIU to the terms it requested. Rejection ends the flow. The user can also approve a narrower scope than requested.
Step 5: FIP Fetches and Transfers Data
Once consent is captured, the AA forwards the consent artefact to the FIP. The FIP validates the artefact, fetches the requested data, encrypts it end to end using the FIU’s public key, and passes the encrypted payload back through the AA.
Step 6: Data Reaches FIU
The FIU receives the encrypted payload and decrypts it locally using its private key. The AA never sees the clear-text data at any point. The FIU can then use the data within the approved purpose and duration, after which it must either delete the data or re-consent as per the AA Master Direction.
The Consent Artefact Explained
The consent artefact is the defining innovation of the AA framework. It is what makes consent structured, revocable, and auditable, instead of an email with a signature at the bottom.
Structure of a Consent Artefact
Each artefact is a digitally signed JSON-based object. It includes the purpose of data use, the data types covered, the start and end dates, the fetch frequency, the data life after fetch, and the unique IDs of the FIP, FIU, and AA involved. Every field is machine-readable, which means systems on all 3 sides can validate the terms before any data moves.
Data-Blind Architecture
The AA sees the metadata of the consent, but never the financial data itself. Payloads pass through the AA in encrypted form, and only the FIU can decrypt them. This is why the framework is often described as “data-blind.” It is also why an AA cannot monetize user data, cross-sell against it, or build a second product line on top of it, which is a deliberate regulatory choice.
Revocation and Audit Trail
A user can revoke consent inside their AA app at any time. Once revoked, the FIU cannot request further data against that consent, and it must handle existing data according to the original terms. Every action in the flow is logged: issuance, fetches, modifications, revocations. This audit trail is available to the user and, when required, to regulators.
The artefact is what makes AA data meaningfully different from a shared PDF, which is exactly the comparison every lender wants to understand.
AA vs Traditional Bank Statement Sharing
Lenders and wealth platforms still ask the same question: is AA data actually better than a PDF or a screen scrape? The short answer is yes, and here is the specific comparison.
Comparison Table: Friction, Security, Data Freshness
| Dimension | Traditional PDF or Screen Scrape | Account Aggregator |
|---|---|---|
| Time to share | 5 to 15 minutes, manual | Under 60 seconds, digital |
| Consent granularity | All or nothing | Purpose, scope, duration, frequency |
| Revocability | None | Any time, user-initiated |
| Audit trail | None | Full log at AA, FIP, and FIU |
| Data format | Unstructured PDF or scraped HTML | Structured JSON, bank-signed |
| Security | Credentials or email | End-to-end encrypted |
| Freshness | Static snapshot | Can be refreshed per consent terms |
Why AA Wins for Lenders
For lenders, the advantage is not just security, it is decisioning quality. Structured JSON statements can be parsed instantly for income, EMI obligations, and cash-flow patterns, which cuts turnaround time on credit underwriting from hours to minutes. Because data is signed by the FIP, the risk of tampered statements disappears. For borrowers with no credit history but strong cash flow, AA data unlocks cash-flow-based lending that static PDFs made impractical. Cash-flow analysis for income verification becomes materially easier.
Knowing the why is useful, but at some point you have to pick which AA to work with.
Licensed Account Aggregators in India
Choosing an AA is a real decision, both for users who want a consumer app and for fintechs evaluating which AA to integrate with.
Current Licensed NBFC-AAs
India has 17 RBI-licensed NBFC-AAs operating in production today, with additional players holding in-principle approval. The list changes as new licences are granted, so the most reliable public reference is the licensed-entity list published by Sahamati. Well-known names in the market include Finvu, OneMoney, CAMSFinServ, Setu AA, Anumati, NADL, and SurakshAA, and our own guide to the best account aggregators goes deeper into how they differ.
How to Choose an AA
For fintechs, the deciding factors are usually 4. First, FIP coverage, since a lender only benefits when the AA can reach the banks its customers actually use. Second, uptime and success rate on fetches, which directly affects funnel conversion. Third, developer experience, including SDK quality, sandbox access, and documentation. Fourth, pricing model and commercial terms, which vary widely. For end users, the primary question is usually how many of their accounts the AA can see and how intuitive the consent UI feels.
Once you have an AA, the more interesting question is what you can actually do with it.
Use Cases for the AA Framework
The framework was built with lending in mind, but it now supports a much wider set of flows. Each use case uses the same consent architecture, only the data types and frequency change.
Lending and Credit Decisioning
The biggest consumer of AA data is lending. Lenders pull bank statements, income data, and obligation history to build a live picture of repayment capacity. Because data is structured and signed, decisioning engines can score applications in seconds and reduce fraud from doctored statements to near zero.
MSME Lending Impact
The framework’s biggest structural impact is in micro, small, and medium enterprise (MSME) lending. Traditional MSME lending relied on balance sheets, GST returns, and branch visits, which priced out millions of small businesses. With AA-connected GSTN data, current-account data, and bureau data flowing under a single consent, lenders can underwrite businesses that never had a packaged credit profile. For a lender, this turns a 2-week file-based process into a same-day digital one, and for a borrower, it opens a credit line that did not previously exist. In H1 FY26 alone, the AA ecosystem facilitated 1.47 lakh crore rupees in loan disbursals across 1.5 crore loans, with monthly disbursements reaching 24,000 crore rupees, up from about 14,000 crore rupees per month in H2 FY25. That activity now accounts for roughly 7.7% of lending by value and 10.8% by volume across retail and MSME loans.
Wealth Management and Advisory
Wealth platforms use AA data to build a consolidated portfolio view across banks, mutual funds, and demat accounts, including held-away assets the advisor does not directly manage. This removes the need for statement uploads at every review cycle and lets advisors run genuine goal-based planning.
Personal Finance Management
Personal finance apps use AA data for budgeting, net-worth tracking, and cash-flow analytics. A user can see every account in one place without handing credentials to an app, which is both safer and more useful than traditional PFM tools.
Insurance Distribution
Insurers and insurance distributors use AA data for income-based underwriting, protection gap analysis, and faster claim processing. Because income evidence comes directly from the source bank, the need for salary slips and manual verification drops significantly.
With the use cases clear, here is what the framework looks like from the 2 sides people actually sit on: as an end user and as a fintech.
How to Use an Account Aggregator (End-User Walkthrough)
If you have never used an AA, the first time can feel unfamiliar. It takes under 5 minutes.
Register on an AA App
Install an AA app such as Finvu, OneMoney, or CAMSFinServ. Enter your mobile number, verify the OTP, and pick an AA handle. The handle looks like yourname@aaprovider and is what FIUs will use to find you.
Linking Accounts
Inside the app, select your banks and other financial institutions. The AA sends a discovery request to each FIP using your mobile number. When accounts appear, confirm ownership through an OTP from the FIP. You only do this once per account.
Approving a Data Request from an FIU
When an FIU such as a lender or wealth platform requests data, the request shows up in your AA app. You see the data types, the purpose, the duration, and the access frequency before you approve. If anything looks off, you can reject or request a narrower scope.
Revoking Consent
If you no longer want an FIU to access your data, open the consent in your AA app and tap revoke. The FIU stops receiving fetches immediately. You can revoke any active consent at any time, without contacting the FIU directly.
That covers the user side. Now the builder side.
How to Integrate as an FIU (Fintech or NBFC Onboarding)
If you run a lender, wealth platform, insurance distributor, or PFM app, joining the framework as an FIU is a structured process.
FIU Onboarding Prerequisites
To onboard, you must be regulated by RBI, SEBI, IRDAI, or PFRDA, and you must have a clear use case tied to your regulated activity. The practical first step is engaging with Sahamati, which manages the market-wide onboarding process and ecosystem participation rules.
Technical Integration Overview
Technical integration typically goes through a chosen AA’s APIs and SDKs. You implement endpoints to raise a consent request, handle consent status callbacks, accept the encrypted data payload, and manage key rotation for decryption. Most FIUs pair AA integration with their existing identity stack so that verification, KYC, and AA-based data pull sit in 1 onboarding journey. If that is your plan, the HyperVerge’s solution is built specifically for this pattern.
Compliance and Data Governance
FIUs are bound by the consent terms. That means enforcing purpose limitation, respecting the data life defined in the artefact, deleting or re-consenting data when the window closes, and maintaining audit logs. These obligations overlap with broader AML compliance expectations, so most serious fintechs build a single data governance layer that handles both.
Having built or connected to an AA, the natural next question is how this compares to what other countries have done.
AA Framework vs Global Open Banking (PSD2, Plaid)
The AA framework often gets compared to Europe’s PSD2 and to US-style aggregators like Plaid. The comparison is useful, but the design differences are real.
Regulatory Licensing Model
In India, NBFC-AAs are directly licensed by the RBI and cannot operate any business other than consent management. In the US, data aggregators operate largely under market-driven rules rather than a single regulator. Under PSD2 in Europe, access is a right banks must grant to regulated Third Party Providers, but the consent manager role is not carved out as a separate licensed entity the way it is in India.
Consent Architecture Differences
PSD2 and most open banking systems rely on OAuth-style consent flows. India’s AA uses a structured, signed consent artefact with explicit duration, frequency, and purpose fields, plus native revocation. The practical result is that revocation, audit, and granular scope are first-class concepts in AA, instead of features bolted on.
Data Residency and Data-Blind Principle
Most global aggregators store user data at some point. AAs cannot, by design. Combined with India’s data residency rules, this means the entire data path stays in-country and stays encrypted end to end, with the consent manager unable to read it. This is what regulators in other markets have started studying as a model.
Get Started with HyperVerge
If you are a fintech, lender, or insurance distributor preparing to onboard users through the AA framework, you still need the layers that sit around it: identity verification, KYC, risk scoring, and fraud prevention. HyperVerge’s identity and KYC stack is built to work alongside AA-based data pulls in a single onboarding flow, so you do not stitch 5 vendors together. Sign up to get started, and a specialist will walk you through an AA-compatible onboarding design
FAQs
What is the RBI account aggregator framework?
The RBI account aggregator framework is a consent-based financial data sharing system regulated by the Reserve Bank of India. It lets users share their financial data between regulated institutions through a licensed NBFC-AA that acts as a data-blind consent manager, with end-to-end encryption and revocable consent.
How does the account aggregator work step by step?
In 6 steps: a user registers with an AA and links accounts, an FIU raises a consent request, the user approves it, the FIP fetches and encrypts the data, the AA forwards the encrypted payload, and the FIU decrypts and uses it within the approved purpose and duration. The AA never sees the data itself.
Who are the licensed account aggregators in India?
A set of RBI-licensed NBFC-AAs operate in India today, including well-known consumer and enterprise players. Because the list updates as new licences are granted, the most reliable source is the licensed-entity list maintained by Sahamati, the ecosystem alliance.
What is the difference between FIP and FIU in the AA framework?
An FIP is a Financial Information Provider that holds user data, such as banks, NBFCs, and insurers. An FIU is a Financial Information User that consumes data for a regulated purpose, such as lending, wealth, or insurance. The AA moves data from FIP to FIU with the user’s consent.
Is the account aggregator safe to use?
Yes. Data is end-to-end encrypted between the FIP and the FIU, the AA itself is data-blind and cannot read the data, consent is revocable at any time, and every step is logged. Users also control scope, duration, and frequency.
What is a consent artefact?
A consent artefact is a digitally signed, machine-readable record of the user’s permission. It defines the data types, purpose, duration, frequency of access, and data life. It is what turns consent from an email into an auditable, revocable contract.
How many account aggregators are there in India?
17 NBFC-AAs currently hold an RBI operating licence, with additional players holding in-principle approval. The number changes as the RBI grants new licences, so Sahamati’s public licensed-entity list remains the most reliable reference.
What types of financial data can be shared via the AA framework?
Bank account statements, deposit balances, mutual fund and demat holdings, insurance policies, and pension data are all in scope, along with GST data through GSTN participation. The exact data types depend on which FIPs have gone live and the scope the user consents to.
