AMLEGALS — Strategic Lawyering
Financial Services — Consent Collision

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.

RBI ArtefactSection 6 ConsentRule 4 ManagerFIP × FIUCo-lending Chains

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.

The Position in One Paragraph

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.

Regime Comparison

Three Consent Constructs Side by Side

RBI Consent Artefact

Regulator: Reserve Bank of India

Source

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 India

Source

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 India

Source

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

Failure Points

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 6

Withdrawal 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 8

Breach 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 7

The 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 Schedule
The Practical Test

One 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.

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.

Request a Confidential Briefing

Our data privacy counsel will reach out within one working day.

Insights & Answers

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.