Implementing India's Account Aggregator Framework: A Builder's Guide

The Account Aggregator framework is the part of India’s financial stack that most outsiders have not heard of and that, for builders, is the most operationally consequential. Where UPI moves money, AA moves data — bank statements, mutual fund holdings, insurance policies, tax filings, GST returns — across institutions, on the consent of the customer, in a standardized format. The framework went live in 2021, hit a billion consent artefacts in 2024, and by early 2026 underpins essentially every meaningful new lending, wealth, and insurance product in the country.

I want to walk through how the system actually works and what it takes to integrate, because the AA flow is the kind of thing where the protocol is simple but the operational reality has corners.

The four roles#

There are four participant roles in the AA framework, defined by the RBI’s NBFC-AA master direction.

FIPs (Financial Information Providers) are the entities that hold the customer data — banks, mutual fund RTAs (CAMS, KFin), insurance companies, the income tax department (via Cleartax-style consent flows), pension funds. They expose data via standardized AA APIs.

FIUs (Financial Information Users) are the consumers — lenders running underwriting models, wealth platforms aggregating holdings, insurance underwriters pricing policies, advisory platforms doing financial planning. They request data through an AA.

AAs (Account Aggregators) are licensed NBFC-AAs that sit between FIPs and FIUs. They never see the data itself — they route encrypted blobs — but they handle the consent lifecycle, the customer authentication, and the audit trail. There are roughly a dozen live AAs in 2026, including Finvu, Onemoney, Setu’s Bridge, NeSL Asset Data, and Cookiejar. The customer picks which one to use.

The customer is the consent-granting party. Their consent is captured as a digitally signed artefact with a defined purpose, duration, data range, and frequency — never as a long-lived blanket authorization.

The architecture is intentionally not “open banking” in the European sense. The customer’s bank is not the routing layer. The AA is the routing layer, and it is its own regulated entity. This separation makes the trust model cleaner — the bank cannot see who is asking for the customer’s data — and it lets the consent artefact be the single source of truth.

A consent artefact#

A consent artefact is the unit of granted access. Concretely it is a JSON document signed by the AA on the customer’s behalf, containing fields like:

{
  "consentStart": "2026-03-12T10:00:00.000Z",
  "consentExpiry": "2026-09-12T10:00:00.000Z",
  "consentMode": "VIEW",
  "fetchType": "PERIODIC",
  "consentTypes": ["TRANSACTIONS", "PROFILE", "SUMMARY"],
  "fiTypes": ["DEPOSIT"],
  "DataConsumer": {
    "id": "lender@example-aa",
    "type": "FIU"
  },
  "Customer": { "id": "9999999999@example-aa" },
  "Purpose": {
    "code": "101",
    "text": "Loan underwriting",
    "category": { "type": "Loan" }
  },
  "FIDataRange": {
    "from": "2025-09-12T00:00:00.000Z",
    "to": "2026-03-12T00:00:00.000Z"
  },
  "DataLife": { "unit": "MONTH", "value": 6 },
  "Frequency": { "unit": "MONTH", "value": 1 },
  "DataFilter": [
    { "type": "TRANSACTIONTYPE", "operator": "=", "value": "DEBIT" }
  ]
}

The consent must be granular — purpose-specific, time-bound, data-scope-limited — and it must be revocable at any time by the customer. The audit trail is non-repudiable; an FIU cannot claim it had data access it did not have.

The integration flow for an FIU#

If you are building a lending product and want to pull bank statements via AA, the flow is roughly:

1. Discover the customer’s accounts. Ask the customer for their mobile number. The AA presents a list of FIPs (banks, MF houses) where the number is linked, allowing them to add more.

2. Request consent. Construct a consent request specifying purpose (loan underwriting), data types (transactions, profile), date range (typically last 6-12 months), frequency (one-time for a loan; recurring for a credit line), and DataLife (how long you may store the fetched data). Post the request to the AA. The customer is redirected to the AA’s app or web flow to approve.

3. Receive the consent ID. Once the customer approves, the AA returns a signed consent artefact and a consent ID. You store both.

4. Trigger an FI request. Call the AA’s /FI/request endpoint with the consent ID. The AA validates the consent, identifies the FIPs, requests data from each, encrypts the response with a key you provided, and returns a session ID.

5. Fetch the encrypted data. Call /FI/fetch/{sessionId} to download the encrypted FI data. Decrypt it with your private key — the AA never had your private key, so it never saw plaintext.

6. Parse and use the data. The data comes in standardized XML/JSON formats specified by ReBIT (Reserve Bank Information Technology). Transactions follow a defined schema with date, amount, debit/credit, description, balance.

7. Store under the consent constraints. If DataLife is 6 months, you delete after 6 months. The AA can audit you on this.

A complete first-time consent flow takes the customer 30-60 seconds. A recurring fetch on an existing consent is API-only and completes in under 5 seconds.

Where the operational corners are#

The protocol is clean. The reality has friction.

FIP coverage is uneven. Major private and public sector banks are all live in 2026. Some cooperative banks are not. Mutual fund and insurance FIPs joined later and have varying API quality. Before launching a product, verify coverage for the institutions your target customers actually use.

Consent UX matters enormously. Drop-off in the AA consent flow is the largest funnel issue for AA-powered products. The customer is bounced from your app to the AA app and back. If the AA app is slow, broken, or asks for extra details, the customer abandons. Picking the right AA partner — based on UX quality, FIP coverage, and SLA — is more important than the price.

Data freshness is bank-side. When you fetch transactions, the FIP returns what is in its core banking system at that moment. If the customer made a transaction five minutes ago and the FIP hasn’t posted it, you don’t see it. For underwriting this is fine; for some realtime use cases it matters.

ReBIT schemas have evolved. What was a Transaction in 2022 has added fields in 2024 and 2026. Your parser needs versioning. The data engineering team maintains this kind of schema-evolution discipline as a matter of course; if you are doing it ad-hoc, allocate engineering time.

Consent revocation is real. Customers can revoke at any time through their AA app. Your recurring fetches will start returning consent-revoked errors. You need to handle this gracefully — notify the customer, request re-consent, and stop using the data you already have if the purpose no longer applies.

What it enables in 2026#

The original FAQ pitch was “instant loan underwriting on consented bank statements.” That is real and common. But by 2026 the use cases extend much further.

• Personal financial management — apps like Jupiter and Fi pull AA data to give consolidated balance, transaction, and investment views.
• Wealth advisory — Cube, Smallcase, and INDmoney pull mutual fund and brokerage holdings via AA for portfolio analysis.
• Insurance pricing — health insurers pull pharmacy and lab data via AA-extended FIPs to underwrite policies dynamically.
• Loan refinancing — lenders can identify high-cost loans on a customer’s bank statement and offer to refinance, with consent.
• MSME credit — GST returns are now an AA FI type; small business lending uses tax-filing data alongside bank statements for underwriting.

The volume reflects this. As of February 2026, the AA framework has cleared over 1.4 billion consent artefacts since launch and is running at roughly 70 million per month.

The DPDPA overlay#

The Digital Personal Data Protection Act (DPDPA), notified in 2023 and operational from late 2024, sits on top of the AA framework as the general data-protection law. AA was built consent-first, so most of DPDPA’s principal-of-processing requirements were already met by design. The main new obligations for AA participants in 2026 are around data fiduciary registration, breach notification timelines (72 hours), and the right of erasure when the purpose ends. The DPDPA compliance post covers this in more depth.

Where pdpspectra fits#

We build AA integrations for lenders, wealth platforms, and insurance carriers across India out of our Kathmandu and Boston teams. If you are integrating AA — first time, or migrating from a tactical integration to a production-grade one — our team handles the protocol work, the schema versioning, the consent UX, the DPDPA overlay, and the audit-grade logging.

Related reading: the Indian fintech stack post, the DPDPA compliance engineering guide, and the open banking comparison post.

---

Consented data is the new credit bureau. Talk to our team about your AA integration.