Account Aggregator Framework in India: Consent-Based Data Sharing

The account aggregator framework in India has become one of the most tested topics in IIBF Digital Banking papers, and for good reason — it is the regulatory backbone of consent-based financial data sharing across banks, NBFCs, insurers and mutual funds. Built on the RBI's NBFC-AA licence and running on the India Stack's Data Empowerment and Protection Architecture (DEPA), the framework lets a customer share verified financial data with a lender or wealth manager without ever emailing a bank statement or a scanned passbook. For your exam, you must know the FIP, FIU and AA roles cold, along with how the consent artefact actually moves data between them.

🏦 What Is the Account Aggregator Framework?

An Account Aggregator (AA) is a special category of Non-Banking Financial Company licensed by the Reserve Bank of India under the Master Direction — Non-Banking Financial Company — Account Aggregator (Reserve Bank) Directions. Its sole business is to collect financial information about a customer, held across different regulated entities, and pass it to another regulated entity — but only with the customer's explicit, digital, revocable consent.

This is the core design idea candidates often miss: an AA is a consent manager and data pipe, not a data warehouse. It never opens an account for the customer, never advises on any transaction, and is barred by regulation from storing, parsing, or using the financial information it moves. This "data-blind" architecture is what separates the account aggregator framework in India from a typical fintech data-sharing API and is a favourite MCQ distinction.

The framework covers financial information across banking, non-banking finance, mutual fund, insurance, pension, tax and securities data — meaning a single consent can pull together a customer's full financial footprint for lending or advisory use. Revise the ecosystem basics through Overview of Digital Banking before going deeper into the role-based structure below.

🔗 FIP, FIU and AA: The Three Roles Explained

Three distinct entities operate within the account aggregator framework in India, and IIBF questions frequently test whether you can correctly assign a real-world institution to its role.

The Financial Information Provider (FIP) is the entity that already holds the customer's data — a bank, an NBFC, a mutual fund house, an insurer, a pension fund, or a depository. The FIP does not initiate anything; it only responds to a validated consent request by releasing the specific data slice the customer authorised.

The Financial Information User (FIU) is the entity that wants the data to make a decision — typically a lender assessing a loan application or a wealth manager building a consolidated portfolio view. An FIU can only be a regulated entity and must route every request through a licensed AA; it cannot approach an FIP directly for consented data.

The Account Aggregator (AA) sits in the middle as the consent broker. It authenticates the customer, presents the consent request in plain language, records the customer's approval or denial, and routes the encrypted data from FIP to FIU. The AA itself never decrypts or reads the payload it carries.

One institution can hold more than one role for different transactions — a bank is commonly an FIP for its own deposit data and an FIU when it uses AA rails to underwrite a loan.

📝 The Consent Artefact: How Data Sharing Actually Works

The consent artefact is the single most exam-relevant technical object in the account aggregator framework in India. It is a structured, machine-readable digital record — not a signature on paper — that captures exactly what the customer has agreed to share.

A valid consent artefact specifies the purpose of the request (for example, "loan underwriting"), the FI data types being sought (bank transactions, GST returns, mutual fund holdings), the specific FIPs involved, the data life (a one-time pull versus a recurring feed), the consent validity period, and the customer's explicit approval captured through the AA's own authentication flow, typically OTP-based.

Critically, consent is purpose-limited and revocable at any time from the AA's dashboard — the customer can view every active consent and withdraw it, after which no further data can flow under that artefact. This granular, revocable design is what makes the model compliant with data-minimisation principles and is very different from a blanket net-banking password shared with a third-party app, a mistake candidates often confuse in exam scenarios.

⚠️ Common Mistake: Do not assume the AA stores a copy of the shared data for future reuse. Every FIU request must trigger a fresh consent artefact; the AA architecture is deliberately "data-blind" and non-repository by regulatory design.

📜 NBFC-AA Licence: The RBI Regulatory Layer

Operating as an Account Aggregator requires a specific Certificate of Registration from the RBI as an NBFC-AA. This is a restrictive licence: an NBFC-AA cannot lend, cannot raise deposits, cannot sell any other financial product, and cannot use the customer data it transmits for its own commercial purposes.

The Master Direction lays down a minimum net owned fund requirement for an entity to be registered as an NBFC-AA, along with technical and data-security standards that AAs must build to, developed collaboratively through the AA ecosystem's industry body (widely referred to as Sahamati) and ReBIT's technical specifications. Consult the RBI's official notifications for the current Master Direction text and any amendments before an exam attempt, since regulatory thresholds are periodically revised.

For institutional context on how such licensed digital rails plug into a bank's own systems, revisit Retail Banking - Digital Banking Class 12 and Financial Inclusion, both of which touch on how consent-based architectures extend formal credit access to thin-file customers.

💡 Exam Tip: If a question asks whether an AA can "view" or "sell" customer financial data, the answer is always no — its licence conditions expressly prohibit both, regardless of how the FIU intends to use the data.

💰 Use Cases in Lending and Wealth Management

The account aggregator framework in India was designed with two flagship use cases in mind: credit underwriting and wealth aggregation, both of which show up regularly in Digital Banking case-study questions.

In lending, an FIU such as a bank or NBFC can pull a prospective borrower's bank statements, GST filings and existing loan repayment history through the AA rail instead of relying on physical statements or bureau data alone. This supports faster, more accurate underwriting for MSMEs and gig-economy borrowers who may not have a deep formal credit history, complementing digital lending workflows and cash-flow-based assessment models.

In wealth management, an FIU such as a registered investment adviser or a wealth-tech platform can consolidate a customer's bank deposits, mutual fund folios, and pension holdings into a single consented view, without asking the customer to manually upload statements from five different providers. Because each pull is scoped by a fresh consent artefact, the customer retains full control over which slice of their portfolio is visible to which adviser.

Both use cases depend on the same three-role architecture and the same consent-artefact discipline covered above — this is why IIBF tends to test the mechanics once and then apply them across different application scenarios. Reinforce the fundamentals with Mobile Banking, since most AA consent journeys are completed on a mobile app.

📌 Remember: The same AA rail serves both use cases — only the FIU and its stated purpose change between a lending decision and a wealth-management view.

The AA rails do not operate in isolation — they sit alongside other consent and payment infrastructure tested in Digital Banking papers. Compare this consent-based pull model with how recurring debits are authorised under e-mandate and NACH in digital banking, and see how physical access points evolved in parallel through Digital Banking Units. Candidates preparing CAIIB ITDB alongside Digital Banking should also revise core banking solution architecture, since every AA data pull ultimately resolves against records held in a bank's core banking solution. For the underlying currency and payments context, CBDC e-Rupee digital currency is another closely related exam topic worth revising in the same sitting.

🎯 Conclusion: Exam-Ready on the AA Framework

For IIBF Digital Banking, lock in three things about the account aggregator framework in India: the FIP-AA-FIU role separation, the consent artefact as the sole legal basis for every data pull, and the NBFC-AA licence conditions that keep the AA data-blind. Case-study questions almost always test whether you can correctly slot an institution into its role and identify what the consent artefact must specify before data can move.

Cross-check the regulatory framing against the RBI's official directions at rbi.org.in before your exam, and browse more topics on the Digital Banking tag hub to round out your Module B preparation. Ready to test yourself? Attempt a free chapter-wise mock test and see how you score on consent-based data sharing questions.

🧠 Practice MCQs: Account Aggregator Framework

Want chapter-wise mock tests with 100+ MCQs? Start practising free →

❓ Frequently Asked Questions