Account Aggregator Security: What FIUs and FIPs Must Get Right in 2026

India’s Account Aggregator (AA) framework has quietly become the rails for consent-based financial data sharing. As of the end of 2025, more than 2.6 billion accounts were enabled for sharing across the network, and lenders, wealth platforms, insurers, and personal-finance apps now pull bank statements, deposits, and investment data through it instead of asking customers to upload PDFs or hand over net-banking credentials. That is a genuine security win over screen-scraping. But it also concentrates a lot of sensitive financial data into a small number of regulated participants — and the threat model shifts accordingly.

This post breaks down what each role in the AA ecosystem must actually get right in 2026: the obligations, the realistic attack surface, and a practical checklist. If you run an FIU or FIP, the parts that will get you breached or fined are not exotic — they are the same API authorisation, key-management, and data-lifecycle failures that hit every fintech, amplified by the fact that this is RBI-regulated financial infrastructure.

How the AA ecosystem works (the 60-second primer)

There are three regulated roles, and conflating them is the most common mistake leaders make:

• Account Aggregator (AA) — an RBI-licensed NBFC-AA that operates under the Master Direction – Non-Banking Financial Company – Account Aggregator (Reserve Bank) Directions, 2016. The AA is the consent intermediary. It does not lend, invest, or process the data — its registration is restricted to account aggregation only, with a minimum Net Owned Fund of ₹2 crore. Crucially, the AA is data blind: data passing through it is encrypted end-to-end, and the AA never holds the decryption key.
• Financial Information Provider (FIP) — the institution that holds the data: banks, NBFCs, insurers, asset managers, pension funds, depositories. The FIP exposes APIs that, on receiving a valid consent artefact, fetch the requested data, encrypt it, and hand it back through the AA.
• Financial Information User (FIU) — the institution that consumes the data: a lender underwriting a loan, a wealth manager building a consolidated portfolio view, a PFM app doing cash-flow analytics. The FIU defines the purpose, holds the keypair used to decrypt, and stores the fetched data.

The data flow, simplified: the customer authenticates with their chosen AA and approves a request. The AA creates a consent artefact — a digitally signed object whose contents are prescribed by Clause 6.3 of the Master Direction, including the customer’s identity, the purpose, the data types, the consent creation and expiry dates, the fetch frequency, and a notification URL. That artefact travels to the FIP. The FIP validates it, fetches the data, and encrypts it using the FIU’s public key. The AA relays the encrypted payload to the FIU, which decrypts it locally with its private key. The technical and security standards for all of this are set by ReBIT (RBI’s technology arm), and the ecosystem is coordinated by Sahamati, the industry self-regulatory body that runs the central registry, token services, and the empanelled-auditor certification that participants must pass before going live.

Why the encryption design matters for your threat model

The “data blind” property is the framework’s strongest security guarantee, and it changes where you should spend defensive effort. Because data is encrypted with the FIU’s public key — and, per ReBIT specifications, the keypairs used for a fetch are ephemeral and derived through an Elliptic-Curve Diffie-Hellman exchange — the AA genuinely cannot read what flows through it. A compromise of the AA leaks consent metadata and audit trails, not your customers’ bank statements.

The corollary is the part leaders underestimate: the FIU is where the plaintext lives and where the private key lives. The encryption is only as good as the FIU’s key management. If your private key is sitting in an environment variable, baked into a container image, or readable by your application service account, the entire end-to-end encryption story collapses at the one point an attacker actually wants to reach.

Security obligations by role

FIP security: the API is the perimeter

An FIP’s data-fetch endpoints are, by design, internet-reachable APIs that return sensitive financial records. That makes them a textbook target for the failures in the OWASP API Top 10. The two that hurt most here:

• Broken Object-Level Authorisation (BOLA/IDOR): if a fetch endpoint trusts an account identifier in the request without re-binding it to the specific, signed consent artefact, an attacker who can mint or replay a request may pull data for accounts they were never authorised to access. Every fetch must be authorised against the exact consent — not just a valid session.
• Broken authentication and consent-validation bypass: the FIP must cryptographically verify the consent artefact’s signature and that it is live, in-scope, and not expired or revoked on every call. Caching a “consent is valid” decision, or skipping signature verification under load, turns a one-time approval into an open tap.

FIPs must also guarantee data integrity in transit (sign responses so tampering is detectable), rate-limit and monitor for anomalous fetch patterns (a sign of consent-farming or mule activity), and honour revocation immediately rather than at next-renewal.

FIU security: you hold the keys and the data

The FIU carries the heaviest load because it ends up with decrypted financial data and the private key that unlocks it. Get these right:

• Key management. Generate and store the decryption private key in an HSM or a managed KMS, never in code, config files, or plaintext at rest. Enforce least-privilege so the application can request a decrypt operation but cannot export the key. Rotate keys and have a documented compromise-response runbook.
• Secure storage of fetched data. Encrypt the decrypted financial data at rest under a separate key, tokenise or mask where you can, and isolate it from general application stores. This data is “financial information” — exactly the category that attracts heightened obligations under the DPDP Act.
• Purpose limitation and consent honouring. Use the data only for the purpose the customer consented to. Re-using AA-sourced data for marketing, a new product, or model training the customer never agreed to is both a framework violation and a DPDP problem. Enforce this in code, not policy PDFs.
• Retention and deletion. Respect the consent’s data-life and storage limits. When consent expires or is revoked, delete the data on the timeline you committed to and prove it — deletion you cannot evidence is deletion regulators will not credit.

AA security: integrity without access

The AA’s mandate is unusual — its security goal is to be useful but blind. It must guarantee the integrity of the consent lifecycle (creation, notification, expiry, revocation can’t be tampered with), protect the audit log and the customer-to-account identity mapping, and architecturally ensure it never comes into possession of a decryption key. Insider misuse of consent metadata, and any drift that would let the AA read payloads, are the failures that would break the framework’s core trust assumption.

The threat model in practice

• API attacks (BOLA, broken auth, mass assignment): the dominant risk on the FIP side and on any FIU-facing webhook. Authorise per-consent, verify signatures every call.
• Consent manipulation: forged, replayed, or scope-inflated consent artefacts. Signature verification, expiry/revocation checks, and binding the artefact to the exact data request are the defences.
• Key compromise: the single worst outcome for an FIU. HSM/KMS-backed keys, no exportability, rotation, and monitoring of decrypt operations.
• Insider misuse: staff at any role pulling more than their job needs. Least-privilege, access logging, and separation of duties — especially around the FIU’s data store and the AA’s metadata.
• Data-at-rest theft: the breach scenario regulators will judge you on. India is a top-five ransomware-victim geography and financial services are among the hardest-hit sectors, so assume the attempt and design for blast-radius containment.

DPDP Act overlap and breach liability

AA data is financial information about identifiable individuals, so it sits squarely inside the Digital Personal Data Protection (DPDP) Act, 2023. The DPDP Rules were notified on 13 November 2025, with full compliance required by 13 May 2027 and penalties up to ₹250 crore. For an FIU, the AA framework’s purpose-limitation and consent obligations and the DPDP Act’s data-fiduciary duties reinforce each other — but DPDP adds explicit breach-notification and data-principal-rights teeth.

Layer on the operational reporting reality: CERT-In requires reporting of covered incidents within 6 hours of becoming aware, and mandates 180-day log retention — which is one more reason your FIU and FIP access logs need to be complete and tamper-evident. None of this is optional for regulated financial entities; see our breakdown of the RBI cybersecurity framework for banks and NBFCs for how these obligations stack, and the DPDP compliance hub for the data-protection side.

A practical security checklist

For FIUs:

1. Private decryption key in HSM/KMS, non-exportable, rotated, with a compromise runbook.
2. Fetched financial data encrypted at rest under a distinct key, isolated, masked where feasible.
3. Purpose limitation enforced in code; no secondary use without fresh consent.
4. Retention and deletion tied to the consent’s data-life; deletion evidenced.
5. Per-consent authorisation on every webhook/endpoint; signature and expiry verified each call.
6. CERT-In-grade, tamper-evident access logging; 6-hour incident playbook rehearsed.

For FIPs:

1. Verify the consent artefact’s signature, scope, expiry, and revocation on every fetch — no caching of the decision.
2. Bind each fetch to the specific consent and account; close BOLA/IDOR gaps.
3. Sign responses for end-to-end integrity; rate-limit and anomaly-monitor fetch patterns.
4. Honour revocation immediately.
5. Retain audit logs for the full 7-year window.

Where independent VAPT and audits fit

Going live on the AA network already requires certification against ReBIT technical standards via a Sahamati-empanelled auditor — but that is a point-in-time onboarding gate, not ongoing assurance. RBI’s broader expectations for regulated entities, including the tightened IT outsourcing norms taking effect in October 2026 (cloud audit rights, documented exit plans), point toward continuous, independent testing. For AA participants that means regular, scope-appropriate VAPT of the fetch and consent APIs, key-management and secrets reviews, and validation that purpose-limitation and deletion controls actually behave as documented — because the gap between a control on paper and a control that holds under attack is exactly what a breach report exposes.

Frequently Asked Questions

Can an Account Aggregator read my customers’ financial data?

No. The AA is “data blind” by design — data flowing through it is encrypted end-to-end with the FIU’s public key, and the AA never holds the decryption key. An AA can see consent metadata and audit trails, but not the financial payloads.

Who is liable if AA-sourced data is breached at an FIU?

The FIU. Once data is decrypted and stored, the FIU is responsible for protecting it under both the AA framework’s obligations and its DPDP Act data-fiduciary duties — including breach notification, purpose limitation, and deletion. A breach at the FIU is an FIU liability, with DPDP penalties up to ₹250 crore in play.

What is the single most important control for an FIU?

Key management. The entire end-to-end encryption guarantee rests on the FIU’s private key staying secret. Store it in an HSM or KMS, make it non-exportable, and monitor decrypt operations. A leaked private key turns “data blind” into “data exposed.”

Does AA certification mean we are secure?

No. Sahamati-empanelled certification against ReBIT standards is a one-time onboarding requirement that proves baseline conformance. It is not a substitute for ongoing penetration testing, secure key management, or DPDP and RBI breach-readiness, all of which are continuous obligations.

Account Aggregator participation puts RBI-regulated financial data into your stack, and the framework’s elegant encryption design only protects you up to the point where your own key management, API authorisation, and data lifecycle take over. If you operate as an FIU or FIP and want an independent read on whether your consent APIs, key handling, and retention controls hold up under attack, talk to our team about an AA-focused security review.