DPDP Act and Account Aggregator in India: how the two consent regimes work together

"DPDP and AA are not the same regime, and they are not in conflict. They are two consent layers that legitimate Indian finance apps now run simultaneously - one for the data itself, one for the rail it travels on."

Quick answer

• The DPDP Act 2023 is India's general personal-data law administered by MeitY through the Data Protection Board, with penalties up to ₹250 crore per violation.
• Account Aggregator is the RBI-regulated consent rail for financial data, governed under the NBFC-AA Master Direction, with eight licensed AAs live as of 2026.
• The two regimes overlap on consent, purpose limitation, and data-subject rights, but they have different scopes (all personal data vs financial data), different regulators (MeitY vs RBI), and different consent formats (general vs the standardised AA consent artifact).
• For a consumer, the practical implication is: legitimate Indian finance apps will name both regimes in their privacy policy, route financial-data fetch through AA, and offer a DPDP-style grievance redressal path. If any of those three is missing, the app is not on a regulated track.
• For an app, both apply simultaneously: AA compliance does not exempt you from DPDP, and DPDP compliance does not let you skip AA when you need bank-side financial data.

Why this guide exists

The two most-cited regulatory frameworks in Indian consumer finance, mid-2026, are the DPDP Act 2023 and the RBI's Account Aggregator (AA) network. Both are about consent. Both are about data. Both involve a chain of regulated entities. And both get conflated in product marketing and consumer media to the point that users do not know what they are agreeing to.

A typical Indian finance app onboarding screen in 2026 collects: phone number, email, name, PAN, AA-linked bank statements, AA-linked mutual fund holdings, card statement uploads, and a tax-regime questionnaire. Some of that flows through AA; the rest does not. DPDP applies to all of it. The intent of this guide is to draw the line precisely so that users can read a privacy policy and understand what they have actually consented to, and so that app builders know which regime governs which data flow.

For the standalone consumer's guide to AA, see Account Aggregator India consumer guide. For the category guide on AI personal finance companions that build on both regimes, see AI personal finance companion for India.

The two regimes at a glance

DPDP Act 2023: what the law actually says

The DPDP Act became law on 11 August 2023. It does not regulate non-personal data (anonymised statistics, aggregate market data), and it does not apply to personal data processed for personal or domestic purposes by an individual.

Key actors

• Data principal: you, the individual whose personal data is being processed.
• Data fiduciary: the entity that decides why and how personal data is processed (the finance app, the bank, the merchant).
• Data processor: an entity that processes data on behalf of the fiduciary (cloud providers, KYC vendors, analytics platforms).
• Significant Data Fiduciary (SDF): a data fiduciary classified by the central government based on volume, sensitivity, risk; SDFs have additional obligations including a Data Protection Officer and independent data audit.
• Consent manager: a registered intermediary that helps data principals manage consents across data fiduciaries.

The "consent manager" concept in DPDP is the philosophical ancestor of the AA model, generalised to all personal data. AA is an instance of the consent-manager pattern, specifically for financial data, regulated by RBI.

What valid consent looks like

DPDP defines consent as "free, specific, informed, unconditional and unambiguous with a clear affirmative action." Each word is load-bearing:

• Free: not coerced by withholding service unless the service genuinely depends on the data.
• Specific: tied to a defined purpose, not a vague "for service improvement."
• Informed: the notice must describe what data, why, who will process it, and how to withdraw.
• Unconditional: the data principal cannot be required to consent to unrelated processing as a condition of consenting to the primary purpose.
• Clear affirmative action: pre-checked boxes do not count.

In addition, the act provides for "deemed consent" in defined situations (employment, certain public interest contexts, medical emergency). Most consumer finance use cases do not qualify for deemed consent and require explicit consent.

Data principal rights

• Access: a summary of personal data being processed and the processing activities.
• Correction: correct or complete inaccurate or incomplete data.
• Erasure: erase data after the purpose ends or consent is withdrawn.
• Nomination: nominate someone to exercise rights on death or incapacity.
• Grievance redressal: through the fiduciary's grievance officer, escalating to the Data Protection Board.

Most legitimate Indian finance apps now ship a "Delete Account" flow inside the app itself in response to this regime; that flow used to be email-only and slow.

Penalties

The act defines a graded penalty structure with the headline figures:

• Failure to take reasonable security safeguards: up to ₹250 crore per instance.
• Failure to notify the Board and affected data principals of a breach: up to ₹200 crore.
• Failure to fulfil obligations specific to children's data: up to ₹200 crore.
• Failure to fulfil additional obligations of an SDF: up to ₹150 crore.
• Breach of any other provision: up to ₹50 crore.

These are statutory caps; actual penalties are decided by the Data Protection Board on a case-by-case basis.

Status in 2026

The DPDP Act became law in 2023, but its operationalisation depends on subordinate rules notified by MeitY and the constitution of the Data Protection Board. As of mid-2026, the phased rollout continues; finance apps are largely operating in a "build to compliance" mode, treating the law as in force on its principles even where every procedural rule has not been notified. The right way to read this guide is: principles are settled; procedural detail evolves; check MeitY's latest notification before relying on any specific deadline.

Account Aggregator: what the rail actually does

Account Aggregator is a narrower system. It is purpose-built for financial data, with the consent format, regulators, and entity types defined by RBI rather than MeitY.

Key actors

• FIP (Financial Information Provider): the entity holding your financial data. Banks, mutual fund RTAs, insurance companies, pension funds, GST networks, depositories.
• FIU (Financial Information User): the app or institution that wants to read your data. Lenders, finance apps, planning tools, RIAs.
• AA (Account Aggregator): the RBI-licensed NBFC-AA that brokers the consent between FIP and FIU. It does not store or read the data; it routes it.

As of 2026, the licensed AAs include OneMoney, Finvu, NESL Asset Data, Setu Bridge, Anumati, Perfios, CAMS, and a handful of newer additions. Most large finance apps integrate with two or three AAs to provide consumer choice and redundancy.

The consent artifact

AA consent is a signed JSON document with prescribed fields, the most important of which are:

• The FIP and FIU identities.
• The data categories (e.g., DEPOSIT account statements, EQUITIES holdings, INSURANCE policy details).
• The fetch frequency (one-time, periodic monthly, daily).
• The duration of consent.
• The purpose of fetching the data.

The artifact is machine-readable and tied to a unique consent ID. Both the data principal and the FIU can revoke a consent before its expiry. Per Sahamati, the industry body for the AA network, more than 100 million consents had been fulfilled across the network as of early 2025 with 1,500+ FIUs live; the rail is well past the experimental stage.

For a detailed walk-through of the AA consent flow, see Account Aggregator India consumer guide.

Penalty structure

There is no fixed monetary cap akin to DPDP's ₹250 crore. RBI exercises power under the Banking Regulation Act and the RBI Act to:

• Suspend or cancel the NBFC-AA licence (the consent intermediary).
• Impose monetary penalties on the FIP or FIU's underlying licence (banking, NBFC, asset management).
• Issue prudential restrictions until compliance is restored.

The practical risk for a finance app is loss of access to the AA rail, not the fine. An FIU cut off from AA cannot ingest fresh financial data from banks; the product effectively stops working.

Where DPDP and AA overlap

Both regimes are built around the same five-element backbone:

1. Notice: explicit, intelligible explanation before any data is processed.
2. Consent: affirmative, specific, withdrawable.
3. Purpose limitation: data used only for the declared purpose.
4. Data minimisation: only the data needed for the purpose is processed.
5. Subject rights: access, correction, erasure, grievance redressal.

A consumer who reads an AA consent screen and a DPDP notice from the same finance app will recognise the same five elements expressed in two different formats. This is intentional: AA was a regulatory precursor, and DPDP generalises the pattern to all personal data.

Where DPDP goes beyond AA

• Scope of data: DPDP covers any personal data - name, phone, email, location, biometrics, device identifiers, photos. AA only covers financial data from FIPs.
• Cross-border transfer: DPDP allows cross-border transfer by default with restrictions on countries notified by the central government. AA's consent artifact is generally not used for cross-border transfer.
• Children's data: DPDP has specific rules for data principals under 18 - verifiable parental consent, prohibition on targeted advertising. AA has no comparable provision; financial data for minors is typically routed through a guardian's consent under separate rules.
• Significant Data Fiduciaries: DPDP introduces additional obligations (DPO, audits, impact assessments) for SDFs. AA has supervisory obligations on the NBFC-AA itself but no equivalent classification for FIUs.
• Deemed consent: DPDP recognises certain processing without explicit consent (employment, public interest, medical emergency). AA requires explicit, specific consent for every fetch.

Where AA is stricter than DPDP

• Standardised consent format: AA's JSON consent artifact is machine-readable and uniform across all AAs and FIUs. DPDP allows any reasonable consent format.
• Granular categories: AA defines a fixed taxonomy of data categories (DEPOSIT, EQUITIES, MUTUAL_FUND, INSURANCE_POLICIES, GSTN, etc.). DPDP relies on the fiduciary's own description.
• Mandatory expiry: AA consents must have a defined duration; "perpetual consent" is not allowed. DPDP consent persists until withdrawn.
• Network supervision: RBI directly inspects NBFC-AAs and AA participants. The Data Protection Board under DPDP exists, but its operating cadence is still being established.

What this means for users

If you are an Indian consumer linking a finance app:

1. Look for AA in the bank-linking flow. If the app screen-scrapes your bank or asks for your net banking password, walk away. AA is the regulated alternative.
2. Read the DPDP-style privacy policy for everything outside AA: KYC, app analytics, device data, marketing.
3. Check the data deletion path. A legitimate app under DPDP should support in-app account deletion, not email-only.
4. Know which regulator to escalate to. AA disputes go to the AA's grievance officer and ultimately RBI. DPDP disputes go to the data fiduciary's DPDP grievance officer and ultimately the Data Protection Board.
5. Track your consents. Sahamati's "MyConsents" surface or the app's own consent dashboard should let you revoke an AA consent at any time. DPDP consent revocation is via the data fiduciary's interface.

What this means for finance apps

Building under both regimes requires a coherent compliance posture:

• Dual notice + consent flow: one screen for AA consent (the JSON artifact, signed via the chosen AA), and one or more screens for DPDP-grade consent on the rest of the personal data (PII, analytics, marketing).
• Privacy policy that names both: the policy must specify which data flows through AA (and name the AA provider), and which data is processed under DPDP with the fiduciary's own purpose definition.
• Audit trails: AA fetches generate machine-readable logs at the AA layer. DPDP requires the fiduciary to maintain processing records and, if classified as SDF, to commission independent audits.
• Data Protection Officer: required for SDF status under DPDP; useful (though not mandatory) for AA-only finance apps. Most credible finance apps appoint one by default.
• Grievance redressal: two separate grievance paths, both surfaced in-app. Conflating them is a common audit finding in early DPDP enforcement actions.

Common misconceptions

• "DPDP made AA mandatory for all finance apps." It did not. AA is still optional in the sense that some apps can ingest financial data via direct integration (e.g., a bank's own app accessing its own customer data). For third-party finance apps wanting cross-institution data, AA is the regulated path; the DPDP Act endorses the principle of consent-based access without prescribing AA specifically.
• "AA is DPDP's data rail." No. AA is RBI's data rail for financial data. DPDP does not have a single rail; it is a horizontal data protection law that applies across all personal data, with consent manager as a permitted intermediary pattern.
• "DPDP replaces the IT Act SPDI rules entirely." Eventually yes, but during the phased rollout the SPDI rules (Information Technology Reasonable Security Practices and Procedures and Sensitive Personal Data or Information Rules, 2011) continued to apply until MeitY notified their replacement under DPDP.
• "GDPR experience translates directly to DPDP." Mostly, but not entirely. Deemed consent provisions, the absence of a separate sensitive-data category, and the ₹250 crore cap make the two regimes feel and operate differently. Apps building for India should treat GDPR-readiness as helpful but not sufficient.

How to evaluate a finance app under both regimes

Five questions, in order. Any "no" is a hard fail.

1. Is the app a registered FIU on the AA network, with the AA provider named in the privacy policy?
2. Does the AA-linked flow use the standardised consent artifact format, with categories and duration specified upfront?
3. Does the privacy policy explicitly reference the DPDP Act 2023 and describe the data fiduciary role?
4. Does the app offer in-app data access, correction, and deletion paths under DPDP?
5. Are the two grievance officers (DPDP grievance officer and AA grievance escalation) named separately and reachable?

Apps that pass all five are running the regulated path on both regimes. Apps that pass only the first two are AA-compliant but DPDP-loose. Apps that pass only the last three are DPDP-aware but not using the AA rail. The first two together with the last three is the standard a finance app should be evaluated against in 2026.

Where Qubera fits

Qubera operates as a Financial Information User on the AA network through Setu Bridge as the AA provider, with the standardised consent artifact powering every account fetch. The DPDP-side compliance includes a published privacy policy that names the data fiduciary role, in-app account deletion, separate grievance officers for DPDP and AA escalation, and an explicit consent layer for non-AA personal data (KYC, device, analytics). The two regimes apply simultaneously to the product; the privacy policy and onboarding screens make the boundary visible to the user rather than blurring them into a single click-through.

For the standalone consumer's guide to AA, see Account Aggregator India consumer guide. For the category guide on AI personal finance companions built on top of these regimes, see AI personal finance companion for India.