India's Account Aggregator (AA) rail has quietly become one of the largest consented data-sharing systems in the world. If you are building an NBFC, a lending product, a personal finance app, or any fintech that ingests a user's bank statements, mutual fund holdings, or GST data, you will integrate with it. The regulatory framing is well documented. What is not well documented is what the AA framework does to your cloud architecture.
This post is for the CTO or founding engineer at a pre-seed or seed Indian fintech who has been told "we need to go live on Account Aggregator" and is now staring at the ReBIT API specification wondering what it means for the systems they actually run. It is not a walkthrough of the consent journey UX. It is a walkthrough of the eight architectural constraints the AA rail imposes on the infrastructure behind that UX.
Most generic AA articles explain the roles: the Account Aggregator (a special class of NBFC that brokers data), the Financial Information Provider (FIP, the bank or depository that holds the data), and the Financial Information User (FIU, you, the entity that consumes it). That framing is correct and useless for an engineer. The interesting question is: given those roles and the ReBIT protocol between them, what must your cloud environment look like to be both compliant and not a liability? Here is my answer, drawn from public specifications and labelled as opinion where it is opinion.
Quick context: the state of the rail in 2026
The AA framework sits on the Reserve Bank of India's Master Direction on NBFC-Account Aggregators, 2016 (as amended), and forms the financial layer of the Data Empowerment and Protection Architecture (DEPA). The protocol that all three parties implement is published by ReBIT, the Reserve Bank Information Technology arm, and interoperability is coordinated by the industry alliance Sahamati.
By 2026 the rail is at genuine scale. Sahamati's public ecosystem metrics show billions of financial accounts enabled for AA-based sharing across banks, depositories, insurers, and tax systems, with hundreds of millions of accounts actively linked by users. There are more than a dozen licensed Account Aggregators live, and the FIP and FIU counts run into the hundreds. For a founder this means the integration is a solved commodity on the happy path. The differentiation, and the risk, is entirely in how you architect the systems that sit behind your FIU handle.
1. The AA rail relocates a trust boundary into your VPC
The core design principle of the AA framework, stated across the RBI Master Direction and the ReBIT specification, is that the Account Aggregator is a "consent broker and data blind pipe." The AA moves encrypted financial information from the FIP to the FIU but never sees the plaintext, because it does not hold the decryption key. That is elegant for the AA. For you, the FIU, it means the plaintext financial data materialises for the first time inside your own environment, at the moment your service decrypts the payload.
Architecturally this is a relocated trust boundary. In a traditional integration you pull data from a vendor API over TLS and the vendor is jointly responsible for what leaks. On the AA rail, the FIP and the AA have discharged their obligation the instant the encrypted blob reaches you. Everything after decryption is your surface. That single fact should drive where you terminate decryption (a narrow, isolated service rather than your monolith), what that service is allowed to talk to, and how aggressively you scope its IAM role.
Takeaway: treat the decryption step as the highest-sensitivity boundary in your system and design a dedicated, minimally-privileged service around it rather than decrypting inline in a general application server.
2. You do not hold the key at the AA layer, and that constrains the FIU side too
The ReBIT data flow uses ephemeral key agreement: for each FI (financial information) fetch, both sides generate fresh key material and derive a shared secret. The public specification names the algorithm as ECDHE over Curve25519 in the KeyMaterial section of the Dataflow API. The FIU generates a key pair per session, the FIP encrypts the response to the derived shared secret, and only the FIU's ephemeral private key can decrypt it.
The consequence most teams miss: the private half of that ephemeral key pair is the crown jewel for the duration of a session, and it must never be logged, cached to disk, or serialised into a queue payload. If your worker architecture passes the session context through a message broker, the naive implementation puts a live decryption key into Redis or SQS. That is an avoidable exposure. The key should live only in the memory of the process that will perform the decryption, for the shortest possible window.
Takeaway: keep ephemeral private keys in-process and short-lived; never let them cross a persistence or messaging boundary, and scrub them from any structured logging.
3. Ephemeral key management is an infrastructure problem, not an application one
Because a new key pair is generated per FI request, key generation and key hygiene become a hot-path infrastructure concern rather than a one-time setup. Two mistakes are common. The first is generating keys with a weak or non-vetted library; the ReBIT flow depends on Curve25519, so use a maintained cryptographic library (libsodium, the platform's native crypto, or a cloud KMS that supports the curve) rather than hand-rolled code. The second is using a single long-lived key pair for every session because ephemeral generation felt like premature optimisation. That defeats the forward-secrecy property the protocol is designed to give you.
For the signing keys (as opposed to the ephemeral encryption keys), the picture is different. Your FIU identity is proven with a long-lived signing certificate, and that private key genuinely should live in a hardware-backed store: AWS KMS, CloudHSM, GCP Cloud KMS, or an equivalent. The pattern that works is a clean split: hardware-isolated long-lived signing identity, in-memory ephemeral encryption keys per session.
Takeaway: separate the two key classes cleanly. Long-lived signing keys go in a KMS or HSM; per-session encryption keys are generated with a vetted Curve25519 library and held only in memory.
4. Mutual authentication spans three parties, so certificate lifecycle is a shared risk
The AA protocol is built on mutual authentication between FIU, AA, and FIP. Every request is signed, and the ReBIT specification requires signature verification at each hop, so the consent artefact and the FI request carry a detached signature the receiving party validates before acting. In practice this means your FIU service maintains signing credentials, trusts the AA's public keys, and is in turn trusted by the AAs you integrate with.
The operational trap is certificate expiry. A signing certificate that lapses does not fail loudly at deploy time; it fails at the next real user's consent request, in production, silently returning verification errors. I have seen more than one integration break not from a code bug but from an unrotated certificate nobody owned. Build certificate expiry into your observability from day one: track the notAfter date of every certificate in the trust chain as a monitored metric with an alert well before expiry, and rehearse the rotation rather than discovering the runbook during an incident.
Takeaway: instrument certificate expiry as a first-class monitored metric across your own and your counterparties' certificates, and rehearse rotation before it is urgent.
5. The consent artefact is a first-class object in your data model
In the AA framework, consent is not a boolean flag. It is a digitally signed, machine-readable artefact that encodes the purpose of the data access, the specific FI types requested, the date range of data, the frequency and duration of access, and the consent expiry. The ReBIT specification defines this structure, and the FIP verifies the consent artefact's signature before honouring any FI request. Every subsequent data pull must be justifiable against the exact terms of a live consent.
Teams that model consent as a single column ("has_consented = true") will fail an audit and, worse, will over-fetch. The correct model treats each consent artefact as an immutable record with its own lifecycle: requested, active, paused, revoked, expired. Your data-fetch code must read the artefact's terms at fetch time and refuse any request that falls outside the granted purpose, FI types, or date range. Consent revocation, which a user can trigger at any time through their AA app, must propagate to your systems and stop future fetches immediately.
Takeaway: store consent artefacts as immutable, lifecycle-tracked records, and make every data fetch validate against the specific granted terms rather than a global consent flag.
6. Data minimisation and purpose limitation have to live in code
The framework's data-minimisation principle is not aspirational language; it is enforced by the consent artefact's scoping of FI types and date ranges. If a user consents to share six months of savings-account transactions for a loan underwriting purpose, requesting twelve months, or pulling their mutual fund holdings under the same consent, is a violation. Because the consent terms are machine-readable, the enforcement point is your code, not a policy document a compliance person keeps in a drawer.
Practically, this argues for a thin validation layer between your business logic and the AA fetch call that rejects any request not fully covered by an active consent. It also argues for purpose-scoped storage: data pulled for underwriting should not silently become training data for a recommendation model, because that is a new purpose the user never consented to. The DEPA design intends purpose limitation to be end to end, and the cleanest way to honour it is to tag stored financial data with the consent ID and purpose it was fetched under, then gate downstream access on that tag.
Takeaway: enforce FI-type, date-range, and purpose limits in a validation layer at fetch time, and tag stored data with its originating consent and purpose so downstream use cannot quietly exceed the grant.
7. Immutable audit logging is a regulatory expectation
The Master Direction expects Account Aggregators and participants to maintain audit trails of consents and data flows. As an FIU you are not the AA, but any credible readiness posture, and any enterprise or regulatory review, will ask you to show who accessed which consented data, when, and under which consent. That is an append-only audit-log requirement, and it is easy to get wrong by writing audit entries to the same mutable database your application can update.
The architecture that holds up is a separate, append-only audit store that the application can write to but not modify or delete, with tamper-evidence. On AWS this can be an object-lock-protected S3 bucket or a dedicated ledger service; on GCP, a write-once log sink. The point is not the specific product. The point is that the audit trail must survive a compromise of, or a bug in, the primary application. If an attacker who owns your app server can also rewrite the audit log, the audit log proves nothing.
Takeaway: write consent and data-access audit entries to a separate append-only, tamper-evident store that the primary application cannot retroactively alter.
8. Consent-in does not mean retention-forever: the DPDP intersection
The AA rail governs how data reaches you. India's Digital Personal Data Protection Act, 2023, published by the Ministry of Electronics and Information Technology, governs what you may then do with it and for how long. Financial data pulled over AA is personal data, and DPDP's principles of purpose limitation, storage limitation, and the data principal's right to erasure apply the moment it lands in your environment. A user granting a one-time consent to share statements for a loan decision has not granted you the right to keep those statements indefinitely.
Architecturally this means retention is a design input, not an afterthought. Store financial data with a defined time-to-live tied to the purpose it was fetched for, and build a deletion path that can honour an erasure request without a manual database surgery. The consent-ID tagging from section six pays off here: if every record knows which consent and purpose it belongs to, expiring or deleting data on consent revocation or retention lapse becomes a query, not an archaeology project.
Takeaway: design storage limitation and a working deletion path in from the start; tie retention to the fetch purpose and make erasure a supported operation, not an emergency.
The summary table
| Architectural constraint | What it forces | Where it usually breaks |
|---|
| Relocated trust boundary | Isolated decryption service, tight IAM | Decrypting inline in the monolith |
| FIU holds the only key | Ephemeral keys stay in-process | Session keys leaked into queues or logs |
| Ephemeral key management | Vetted Curve25519 lib, per-session keys | Reused long-lived key pair, weak library |
| Three-party mutual auth | Certificate lifecycle monitoring | Silent expiry in production |
| Consent artefact model | Immutable, lifecycle-tracked records | Single has_consented boolean |
| Data minimisation | Fetch-time validation, purpose tags | Over-fetch, purpose creep |
| Immutable audit | Append-only tamper-evident store | Audit log in the mutable app database |
| DPDP retention | TTL storage and a real deletion path | Keeping data forever by default |
Stage-specific recommendation
If you are a pre-seed FIU integrating for the first time: do not build the AA client yourself. Use a licensed AA's SDK or a technical service provider for the protocol plumbing (mutual TLS, signing, the ReBIT message shapes) and spend your engineering budget on the eight architectural constraints above, which no SDK solves for you. The decryption isolation, consent modelling, audit store, and retention design are your responsibility regardless of who provides the client.
If you are a seed-stage lender pulling AA data at volume: the ephemeral key discipline and the audit store stop being theoretical. At volume, a leaked session key or a mutable audit log is a matter of when, not if. Invest in the isolated decryption service and the append-only audit trail before you scale fetch throughput, because retrofitting them after you are processing thousands of consents a day is far more expensive.
If you are pursuing an NBFC-AA licence yourself: your bar is higher than any FIU's. The RBI Master Direction sets minimum net owned funds and a leverage ceiling, and requires that account aggregation be your sole business, but the operational bar is the blind-pipe guarantee: you must be able to demonstrate that your systems never hold decryption keys or plaintext financial data. That is an architecture and evidence problem, and it should be designed and independently reviewed before, not after, your application to the regulator.
The trap: treating AA as an API integration
The most expensive framing error I see is treating Account Aggregator as "just another data API." The protocol is the easy 20 percent. The consent lifecycle, the key hygiene, the audit immutability, and the retention discipline are the 80 percent that determines whether your AA integration is an asset or a breach waiting to be reported. None of that is in the SDK. All of it is in your cloud architecture.
The teams that get this right treat the AA integration as a security architecture project that happens to include an API client, not an API integration that happens to touch financial data. That reframing changes where the engineering effort goes, and it is the difference between an integration that passes scrutiny and one that becomes an incident.
If you want a second opinion on your AA architecture
MatrixGard runs a free 20-minute architecture and gap review for pre-seed and seed fintechs building on the Account Aggregator rail. Your consent model, your key handling, your audit and retention design, and the most likely gaps against the ReBIT and DPDP expectations, my honest read in 20 minutes. No NDA required for the first conversation. Send a note.
Avinash S is the founder of MatrixGard. Fractional DevSecOps for pre-seed and seed startups across India, the GCC, the UK, and the US. Almost a decade of building, breaking, and securing cloud infrastructure for fintech, healthtech, and SaaS workloads.
Methodology note. Framework and role definitions are taken from the RBI Master Direction on NBFC-Account Aggregators, 2016 (as amended). Protocol details, including the ECDHE over Curve25519 key agreement, the consent artefact structure, and the mutual-authentication and signature-verification requirements, are taken from the ReBIT NBFC-AA API Specification and the ReBIT and Sahamati published materials. Retention and erasure points reference the Digital Personal Data Protection Act, 2023. Ecosystem scale figures are directional, drawn from Sahamati's public metrics; treat them as approximate. The eight-constraint framing and the "where it usually breaks" column are practitioner opinion based on common early-stage architecture patterns, not a published standard. This post is engineering guidance, not legal or regulatory advice; confirm your specific obligations with qualified counsel and the current RBI directions.
