2.8 Account Aggregator rules
Rule summary
Section titled “Rule summary”The Account Aggregator (AA) framework is RBI’s data-sharing infrastructure that lets a customer consent to share financial data held with one institution (bank, mutual fund, insurance company, GST, etc.) with another institution (typically a lender), via a regulated intermediary called an NBFC-AA.
The AA itself never stores or sees the data — it only brokers consent and routes encrypted data from the Financial Information Provider (FIP) to the Financial Information User (FIU).
For a lending platform, the AA framework replaces the old “borrower uploads PDF bank statement” pattern with a consent-driven, authenticated, real-time data pull. For the SME WC wedge, AA is operationally transformative — quality of bank-statement data jumps from “manual PDF upload, often forged” to “live API pull from the bank with cryptographic provenance”.
Source citation
Section titled “Source citation”- RBI Master Direction – Non-Banking Financial Company – Account Aggregator (Reserve Bank) Directions, 2016,
DNBR (PD) CC.No.075/03.10.001/2016-17, dated 2 September 2016, as amended. - Sahamati — industry alliance for the AA ecosystem (
sahamati.org.in). - DPDP Act, 2023 — overlay for personal data.
| Role | What it does | Examples |
|---|---|---|
| FIP — Financial Information Provider | Holds the customer’s financial data; releases it on consent | Banks, mutual funds, insurance companies, GST, tax authorities |
| AA — Account Aggregator | NBFC-AA licensed entity; manages consent and routing | Finvu, OneMoney, Saafe, CAMS Finserv, Anumati, NeSL Asset Data |
| FIU — Financial Information User | Receives data with consent; uses it for the stated purpose | NBFCs, banks, advisors, wealth managers, lenders (this is you) |
| TSP — Technology Service Provider | Integration layer between FIU and AAs; not regulated, but a practical necessity | Setu, FinBox, OneMoney for FIU SDK, IndiaStack-aligned |
For a lending platform: become an FIU, integrate via a TSP, work with multiple AAs to maximise coverage.
Data types available
Section titled “Data types available”| Category | Examples | FI Type code |
|---|---|---|
| Bank accounts | Savings, current, salary, NRE, NRO, FD, RD | DEPOSIT, TERM_DEPOSIT etc. |
| Bank statements | Transaction history (typically last 12 – 36 months) | Part of deposit FI type |
| Mutual funds | Holdings, transaction history | MUTUAL_FUNDS |
| Equity / demat | Holdings | EQUITIES |
| Insurance | Policies | INSURANCE_POLICIES |
| EPF | EPF balance, contribution history | EPF |
| GST | GST returns | GSTR1_3B (where FIP exposes) |
| ITR | Income tax returns | (limited support, growing) |
Practical reality: bank-account FI type is the dominant useful one for SME WC underwriting. GST coverage on AA is patchy and most lenders still go via direct GST APIs through a GSP.
Consent flow
Section titled “Consent flow”- FIU initiates an AA consent request through the AA (via TSP).
- AA presents a consent screen to the customer (web or in-app) — describing what data, from which FIPs, for what purpose, how long.
- Customer authenticates with the AA (mobile + OTP, or other auth).
- Customer selects accounts to link (if not already linked) — typically OTP-verified against the bank.
- Customer approves the consent.
- Consent artefact is generated and signed by the AA.
- FIU fetches data from FIP via AA (data encrypted with FIU’s public key).
- FIU receives and decrypts data.
The consent artefact is the audit unit — every data fetch must reference a valid consent.
Consent parameters
Section titled “Consent parameters”A consent specifies:
- Purpose — e.g., loan underwriting, ongoing monitoring.
- Data range — date range of data (e.g., last
12 months). - Frequency —
ONETIME,MONTHLY,DAILY, etc. - Validity period — how long the consent is valid (e.g.,
1 year). - FIP list — which FIPs the data may come from.
- FI Types — categories of data.
- Use period — how long the FIU may retain / use the data.
- Revocation — customer can revoke any time, AA notifies FIU.
DPDP overlay
Section titled “DPDP overlay”Under the DPDP Act, 2023, AA data is personal data. The FIU’s processing must:
- Have a lawful basis (here: customer consent, mediated by AA).
- Be purpose-limited (cannot use for purposes other than the consent’s purpose).
- Honour deletion / withdrawal requests.
- Notify data principal of breaches within the prescribed period.
Applicability
Section titled “Applicability”Any lender wanting to pull customer financial data digitally — recommended for every SME WC application going forward.
Product implications
Section titled “Product implications”- AA consent screen integrated into the borrower journey, vendor-branded or co-branded.
- Borrower can choose AA — different borrowers prefer different AA brands.
- Fallback to PDF upload when AA coverage is missing for a borrower’s bank or when AA flow fails. Both data sources must be supported.
- Re-consent flow for ongoing monitoring after consent expiry.
System implications
Section titled “System implications”- AA integration layer via a TSP (Setu, FinBox, OneMoney for FIU SDK, etc.).
- Consent storage — every consent artefact stored immutably with hash for verification.
- Data fetch service — async fetch with retry; data persisted alongside consent reference.
- Data normalisation — banks return statements in slightly different schemas; normalise into a unified internal model before underwriting.
- Consent expiry / revocation handler — automated handling of expiry / revocation events from AA; downstream cleanup.
- Multi-AA routing — for resilience and coverage, support
3 – 4AAs simultaneously.
Documents that must be generated
Section titled “Documents that must be generated”- Consent artefact log per borrower (with timestamp, scope, expiry).
- Data fetch log per consent (what was fetched, when, from which FIP).
- Consent revocation acknowledgement.
Workflow that must exist
Section titled “Workflow that must exist”- New borrower AA consent flow.
- Re-consent for periodic refresh.
- Consent revocation handling.
- Fallback to PDF upload when AA fails.
Reports that must be produced
Section titled “Reports that must be produced”- AA consent funnel (request → consent → fetch success) for ops monitoring.
- Per-AA performance (latency, success rate, coverage).
- Data retention compliance — every fetched dataset must be deleted at consent end.
Audit evidence required
Section titled “Audit evidence required”- Consent artefacts.
- Data fetch logs.
- Revocation logs.
- Data deletion evidence (cryptographic proof of deletion preferred).
Sources
Section titled “Sources”- RBI Master Direction – NBFC-AA Directions, 2016,
DNBR (PD) CC.No.075/03.10.001/2016-17, 2 September 2016 (as amended). - Sahamati — Account Aggregator ecosystem alliance,
sahamati.org.in. - DPDP Act, 2023, available at
meity.gov.in. - AA Working Group / ReBIT for technical specifications (
api.rebit.org.in). - AA TSP vendors: Setu (
setu.co), FinBox (finbox.in), OneMoney FIU SDK.