Account Aggregator × DPDPA
India now runs three consent regimes over the same customer. The RBI consent artefact, Section 6 consent under DPDPA, and the Rule 4 Consent Manager. Two regulators. One screen. No published reconciliation.
A purpose code is not a notice. A machine readable artefact is not affirmative action. The consent that satisfies the Reserve Bank does not automatically satisfy the Data Protection Board.
Why one customer now gives three consents
The Account Aggregator framework was built by the Reserve Bank of India for financial information. It defines a consent artefact with a purpose code, a data range, a fetch frequency and a validity period. It is elegant, machine readable and confined to one sector.
DPDPA was built for all digital personal data. Section 5 requires an itemised notice. Section 6 requires consent that is free, specific, informed, unconditional and unambiguous, given by clear affirmative action, with withdrawal as easy as giving.
Rule 4 of the DPDP Rules, 2025 then adds a third construct, a registered Consent Manager acting in fiduciary capacity, commencing on 13 November 2026.
Three constructs. Two regulators. One customer who thinks they clicked once.
Three Consent Constructs Side by Side
RBI Consent Artefact
Regulator: Reserve Bank of IndiaSource
NBFC Account Aggregator Master Direction, 2016
Scope
Financial information only, from entities regulated by RBI, SEBI, IRDAI and PFRDA
Construct
A machine readable artefact carrying identity of the user, purpose code, data range, fetch type, frequency and validity period
Where It Breaks
Purpose codes are drawn from a controlled list. A code is a category, not an itemised statement of the personal data and the purpose required by Section 5
Section 6 Consent
Regulator: Data Protection Board of IndiaSource
Digital Personal Data Protection Act, 2023
Scope
All digital personal data, every sector, no threshold
Construct
Free, specific, informed, unconditional and unambiguous consent by clear affirmative action, preceded by an itemised notice under Section 5
Where It Breaks
Requires withdrawal parity under Section 6(6) and consequences of withdrawal to be borne by the Data Fiduciary, which a purpose code does not express
Rule 4 Consent Manager
Regulator: Data Protection Board of IndiaSource
DPDP Rules, 2025, First Schedule
Scope
Any sector, any Data Fiduciary that onboards to the platform
Construct
A registered intermediary acting in fiduciary capacity, operating an interoperable platform, holding consent records for seven years, unable to read the data it moves
Where It Breaks
Commences 13 November 2026. No entity holds this registration today, so no live flow rests on it
Eight Places the Reconciliation Breaks
Purpose Code versus Itemised Notice
A purpose code says lending. Section 5 requires the notice to itemise the personal data to be processed and the purpose. A code is a label on a bucket. The notice must describe what is in the bucket.
Section 5, Section 6Withdrawal Parity
The aggregator app makes withdrawal easy. The lender's own consent, taken at onboarding in its own journey, frequently does not. Section 6(6) requires parity for each consent, taken where it was taken.
Section 6(6)Two Consents, One Screen
Customers experience one flow and give two legally distinct consents. When the flows are collapsed into a single screen, neither is specific. Bundling is the fastest way to lose both.
Section 6(1)The Data Blind Fallacy
An aggregator that cannot read financial information still processes the customer's registration, mobile number, linked account handles and consent history. That is personal data and it is processed in its own right.
Section 2(i), Section 2(t)Co-lending and Onward Sharing
Data fetched for a purpose by one lender then travels to a co-lender, a servicer, a collections agency and a credit bureau. Each hop needs a lawful basis and a Section 8(2) processor contract or a fresh fiduciary position.
Section 8(2)Erasure versus Retention
Section 8(7) with Rule 8 requires erasure once the purpose is served. Lending, KYC and tax law require retention. The reconciliation is a documented retention register, not a policy sentence.
Section 8(7), Rule 8Breach Across Four Regulators
A single incident in an aggregator flow can trigger intimation to the Data Protection Board under Rule 7, CERT-In reporting, RBI incident reporting and the customer. Four clocks, one event.
Section 8(6), Rule 7The Registration Question
When Rule 4 commences, the market will ask whether an Account Aggregator should also register as a Consent Manager. The answer turns on the conflict of interest condition in Part A, not on product fit.
Rule 4, First ScheduleOne Question Every Lending Board Should Ask
Take one live customer. Pull every consent record held against that customer across the aggregator flow, the onboarding journey, the app permissions and the marketing database.
Now answer four things. What personal data was itemised. What purpose was stated. How withdrawal was offered. Who received the data afterwards.
Most institutions cannot answer any of the four from a single record. That is not a documentation gap. That is the absence of a consent that Section 6 would recognise.
The build window closes on 13 May 2027. The record you cannot produce then is the record the Board will ask for first.
Related DPDPA Resources
DPDPA for BFSI
Sector convergence overview
DPDPA for Consent Managers
Rule 4 registration
Fintech Compliance
Product level playbook
Processor Agreements
Section 8(2) drafting
BFSI Architecture
Control design for financial services
Data Localisation
Section 16 with RBI overlay
Breach Response
Rule 7 staged intimation
DPDPA Consulting
Counsel led advisory
Consent Architecture for Lending
AMLEGALS maps every consent across the customer journey, fixes the lawful basis for each processing operation, and papers the processor chain under Section 8(2) without breaking the aggregator flow.
Our data privacy counsel will reach out within one working day.
What lenders and aggregators are asking
Is an Account Aggregator a Consent Manager under DPDPA?
No. An Account Aggregator is a non banking financial company registered with the Reserve Bank of India under the Master Direction on NBFC Account Aggregator, 2016, and it is confined to financial information from notified financial sector regulators. A Consent Manager is registered with the Data Protection Board under Rule 4 of the DPDP Rules, 2025 and is not confined to any sector. Two regulators, two registrations, two tests. Holding one confers nothing under the other.
Does an Account Aggregator consent artefact satisfy Section 6 of DPDPA?
Not automatically. The artefact is a machine readable structure carrying the user identity, a purpose code, the data range, the fetch frequency and a validity period. Section 6 requires consent that is free, specific, informed, unconditional and unambiguous through clear affirmative action, preceded by an itemised notice under Section 5. Where the purpose code is generic, where the notice does not itemise the personal data, or where withdrawal is not as easy as giving, the artefact will not carry Section 6 on its own.
Who is the Data Fiduciary in an Account Aggregator flow?
The Financial Information Provider and the Financial Information User each determine the purpose and means of their own processing and are each a Data Fiduciary for that processing. The aggregator is data blind by regulatory design and does not read the financial information it routes. That narrows its fiduciary position but does not remove it, because it processes the customer's own registration and consent data in its own right.
What happens when a customer withdraws consent in the aggregator app?
Withdrawal stops further flow. It does not by itself erase data already delivered to the Financial Information User. Section 6(6) requires withdrawal to be as easy as giving. Section 8(7) with Rule 8 requires erasure once the purpose is no longer served, unless retention is required by law. Because lending records carry independent retention obligations, the defensible answer is a documented retention justification rather than reflex deletion.
Do lenders need fresh consent when DPDPA obligations commence on 13 May 2027?
In most cases yes, for consent taken before the notice standard existed. Section 5 requires the itemised notice, and where consent was obtained before commencement the Act contemplates that the Data Fiduciary give the notice as soon as reasonably practicable and continue processing until the Data Principal withdraws. The practical question is whether the existing record can evidence a Section 6 quality consent at all. Most cannot.
Does Section 7 legitimate use cover credit underwriting?
Section 7 covers specified legitimate uses including compliance with law and certain employment and public interest situations. Statutory KYC obligations can sit there. Credit profiling, risk scoring, cross selling and portfolio analytics generally cannot, because they are commercial purposes chosen by the lender rather than obligations imposed on it. The segregation of statutory processing from commercial processing of the same data is the core drafting exercise.
Is a digital lending app a Data Fiduciary or a processor?
It depends on who decides the purpose and means. A lending service provider operating under a lender's instructions is a processor and must be bound by contract under Section 8(2). A platform that decides its own targeting, retention or product logic is determining means and is a Data Fiduciary in its own right regardless of what the contract calls it. Labels do not decide status. Control does.
How does AMLEGALS advise on this intersection?
We map every consent taken across the customer journey, identify the lawful basis for each processing operation, redraft the notice and consent layer to satisfy Section 5 and Section 6 without breaking the aggregator flow, and paper the processor chain under Section 8(2). Where the client is preparing for Rule 4, we run the eligibility and conflict of interest analysis separately.
