Why there are suddenly two "consent" systems
If you have used a loan app, a wealth platform, or even a UPI-linked investment tool in the last couple of years, you have probably tapped "Approve" on an Account Aggregator (AA) consent screen. This is the RBI-built system — run by entities like Setu, Finvu, Onemoney and others — that lets you pull your bank statements, mutual fund holdings, GST filings or insurance policy data and share them digitally with a lender or advisor, instead of emailing PDFs.
Separately, India now has the Digital Personal Data Protection (DPDP) Act, 2023, with its Rules notified to bring it into force. This law governs how any company — not just financial ones — collects, stores, and uses your personal data, and it too runs on a consent model, with its own notices, its own withdrawal mechanism, and its own grievance process.
So you now have two consent architectures sitting on top of the same act — you sharing your bank data with a fintech app. Legal commentators have flagged this as a potential "paradox": which consent actually governs, and what happens if the two frameworks ask for different things?
How the AA consent actually works today
The Account Aggregator framework was designed specifically for financial data sharing, with a fairly rigid, purpose-bound structure. Every time you approve a data pull, the consent artefact specifies:
- Exactly which accounts and data types are being shared (savings account, FD, mutual fund folio, GST returns, etc.)
- The specific purpose — say, "loan underwriting" or "wealth advisory"
- A validity window — a one-time pull, or a recurring pull for a set period
- An expiry date after which the consent lapses automatically
Crucially, the data itself never sits with the Account Aggregator. It only passes through as an encrypted pipe between your bank (the Financial Information Provider) and the app requesting it (the Financial Information User). The AA cannot see or store the underlying numbers. This is a narrow, technical, financial-sector-specific consent model that RBI has spent years refining.
What the DPDP Rules add on top
The DPDP framework is broader and horizontal — it applies to any "Data Fiduciary" (the company using your data) and treats you as the "Data Principal" with a defined set of rights: to be given a clear notice in plain language, to withdraw consent at any time, to ask what data is held about you, and to have it corrected or erased in many cases. It also introduces "Consent Managers" — registered intermediaries who can let you view and manage all your consents across apps and companies from one dashboard. If that sounds familiar, it's because it echoes what AAs already do for financial data specifically. The overlap is real: both systems use terms like "consent artefact," both have expiry and revocation, and both are trying to solve the same basic problem — giving individuals visibility and control over who holds their data.
Where the friction shows up is in the details. DPDP consent notices need to be itemised and understandable on their own, independent of any other agreement. AA consent artefacts are technical, machine-readable objects designed for interoperability between financial institutions, not necessarily written for a lay reader to parse unaided. A lender relying on an AA pull may now need to layer a separate DPDP-compliant notice and consent capture on top of the AA flow to be fully compliant with both regimes — which is exactly the "paradox" legal commentators are pointing to: two consent regimes, doing similar jobs, with no formal bridge between them yet.
What this actually means for you, practically
You don't need to resolve the legal debate to protect yourself. A few things are worth internalising as a user of AA-based apps:
- Two "no" buttons, not one. You can withdraw AA consent (stopping a specific data-sharing pipe) and separately exercise DPDP rights (asking a company to delete data it already stored after receiving it). These are different actions with different effects — withdrawing AA consent stops future pulls, it does not erase data the app already has.
- Check what's already been copied. Once an app pulls your bank statement via AA, that data typically lands in the app's own systems for underwriting. The AA pipe closing doesn't delete that copy. DPDP rights are your lever to ask for deletion of that stored copy — request it explicitly, in writing, if you stop using an app.
- Read the purpose field, not just the account list. AA consent screens usually show which accounts are being accessed but bury the purpose and validity period in smaller text or a details/expand link. Always check the duration — a one-time pull for a loan application is very different from a 3-year recurring consent for "credit monitoring."
- Consent Managers are coming to give you one dashboard. As DPDP Consent Managers get operational, expect to eventually see a single view of every consent you've granted — AA and non-AA — with one-tap revocation. Until then, you're relying on each app's own settings page to track what you've approved.
A practical checklist before you tap Approve
Whether you're linking a bank account for a personal loan, a mutual fund folio for a robo-advisor, or GST data for a business loan, run through this quickly:
- Is this a one-time pull or recurring access — and for how long?
- Does the app clearly state why it needs this specific data, not just a generic "for verification"?
- Is there a visible option later to revoke or review this consent inside the app's settings?
- Does the app's privacy notice separately mention data retention and deletion timelines, as required under DPDP?
The two frameworks will likely converge over time — RBI and the data protection authority coordinating on a common technical standard is the most sensible long-term outcome, and regulators have already signalled interest in this. Until that happens, the safest approach is to treat every AA approval screen as one half of the picture, and actively use your DPDP rights — access, correction, deletion — as the other half, especially once you stop using an app or a loan closes.
