DPDP Act for fintech companies: roles, consent and sector rules

Fintech is a market label. Under the Act, roles turn on who determines the purpose and means of a processing activity and who acts on that person's behalf. The Act contains 4 financial services illustrations: a bank account opened through video KYC, an insurance policy bought through an app, a savings account closed while another law requires records to stay, and a defaulted bank loan.

Start with the data flow, not the licence

Section 2(i) makes the person that determines the purpose and means a Data Fiduciary. Section 2(k) makes a person processing on that fiduciary's behalf a Data Processor. Neither definition asks whether the person holds an RBI or IRDAI licence.

That means 1 business can hold several roles at once. A lending platform can be a Data Fiduciary for its borrowers and its own staff, a Data Processor when it operates a bank's journey to the bank's instructions, and another Data Fiduciary if it reuses the same data for a purpose it chose. A payment or insurance partner can likewise process on another person's behalf for 1 step and determine a separate purpose for the next. Those applications are interpretation. The statutory test is purpose and means, and the Act does not resolve every split where 1 party sets the purpose while another designs much of the means. The role guide keeps that full analysis.

Notice and consent attach to the purpose

Section 4 permits processing only in accordance with the Act, for a lawful purpose, on consent or for certain legitimate uses. A section 5 notice applies when the Data Fiduciary requests consent under section 6.

The section 5 Illustration is written around digital banking. An individual opens a bank account on an app or website and chooses live video KYC. The bank must accompany or precede the request with a notice describing the personal data and the purpose of processing. Section 6 then requires consent to be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action and limited to data necessary for the specified purpose.

The section 6(2) Illustration is written around insurance. Consent to process data for issuing the policy stands, but a supposed consent to waive the right to complain to the Board is invalid. That is a useful design rule: a single accept button cannot turn away a right the Act gives the customer.

Section 7(a) can cover the specified purpose for which a customer voluntarily provided data, if the customer has not indicated that she does not consent to that use. On this site's reading, those words do not create an open permission for every use connected with the account, loan or policy. A later analytics, marketing or data sharing purpose needs its own ground. The consent guide owns the general test.

A consent platform is not automatically a Consent Manager

The Act uses Consent Manager as a defined legal role, not as a description for every dashboard, account aggregator, consent record or data sharing interface. Section 6(9) says every Consent Manager must be registered with the Board, and Rule 4 supplies the registration process. Section 6(7) and 6(8) describe the channel: the Data Principal may give, manage, review or withdraw consent through the Consent Manager, which is accountable to her and acts on her behalf.

So a fintech should not place the label on itself merely because it stores permissions or moves data. Registration is part of the legal role. The Consent Manager explainer covers the definition and duties, while who needs to register keeps the business decision.

The loan default exemption is activity specific

Section 17(1)(f) is the clause most directly relevant to loan default processing in financial services. It is not a sector carve out and requires all of the following:

1. A person has defaulted on a payment due on a loan or advance.
2. The loan or advance came from a financial institution, using the meaning borrowed from the Insolvency and Bankruptcy Code, 2016.
3. The purpose is to ascertain that person's financial information, assets and liabilities.
4. The processing follows the provisions on disclosure of information or data in other law in force.

The Act illustrates a borrower missing a monthly repayment and a bank processing the borrower's personal data to ascertain her financial information, assets and liabilities. It does not say the bank is exempt. It identifies 1 purpose after 1 default.

When a clause in section 17(1) applies, the opening words disapply Chapter II except sections 8(1) and 8(5), Chapter III and section 16 for that processing. Responsibility under section 8(1) and reasonable security safeguards under section 8(5) survive. Clause (f) does not change the ordinary framework for the organisation's other processing, unless another exclusion or exemption independently applies. The section 17 guide maps the other clauses and the precise duties that survive.

Contracts do not transfer responsibility

Fintech journeys often pass through KYC vendors, cloud services, analytics providers, payment infrastructure and customer support vendors. Section 8(2) allows a Data Fiduciary to use a Data Processor for an activity related to offering goods or services only under a valid contract. Section 8(1) keeps the fiduciary responsible for processing by it or on its behalf, irrespective of any agreement to the contrary.

The contract is therefore necessary and not enough. The business still needs to decide whether each recipient acts on its behalf or for an independent purpose, and whether data likely to affect a customer or to be disclosed to another Data Fiduciary is complete, accurate and consistent under section 8(3). The processor obligations and processing agreement clauses stay the canonical pages for that work.

Retention follows purpose, then yields to other law

Section 8(7) requires erasure on withdrawal of consent or when it is reasonable to assume the specified purpose is no longer served, whichever is earlier, unless another law requires retention. Its banking Illustration closes a savings account and then keeps the identity record for 10 years because law applicable to banks requires it. The number comes from that other law, not from the DPDP Act.

A practical way to build a fintech retention register is:

1. identify the purpose and the section 8(7) trigger;
2. identify the exact other law, person and record class that require longer retention;
3. pass the erasure instruction to every Data Processor; and
4. separately account for Rule 8(3), which requires personal data, associated traffic data and other processing logs for at least 1 year for the Seventh Schedule purposes.

The 3 classes under Rule 8(1) and the Third Schedule are an ecommerce entity with at least 2 crore registered users in India, an online gaming intermediary with at least 50 lakh registered users in India, and a social media intermediary with at least 2 crore registered users in India. Fintech status alone is not a class, though a business may meet 1 of those definitions on its own facts. The retention guide keeps the definitions, timers and interaction between duties.

Section 16 is similarly not a free standing localisation rule. It lets the Central Government restrict transfers to a notified country or territory and preserves other Indian law that gives a higher degree of protection or restriction. Use the cross border transfer guide for the current notification check and keep sector transfer rules in the same register.

RBI and IRDAI do not have the same status

Section 38 says the Act is additional to other law in force and prevails only to the extent of a conflict. As a practical recommendation, keep both a DPDP map and a regulator map.

The cited RBI text records the regulator's proposed direction, not a live obligation. Its page prints a placeholder date and reference number; the press release supplies the 15 July release date and 17 August comment deadline.

The IRDAI position is different. Its circular directs insurers, insurance intermediaries and the other listed entities to adhere to the attached Guidelines from the current financial year, and clause 1.10 contains the DPDP sentence. That live IRDAI requirement does not alter the commencement dates in the DPDP instruments. On this site's reading, clause 1.10 applies now while each DPDP provision follows its own commencement status.

When the DPDP pieces commence

Section 2, which carries the role definitions, and section 38 are already in force. Section 6(9) is in the 1 year group and Rule 4 is on the matching Rules track. Computed from the printed publication dates, both commence on 13 November 2026. That date is interpretation until officially confirmed and could move by up to 2 days, to 15 November 2026, because the eGazette record carries the next date and neither instrument explains how to count the period.

Sections 3 to 5, sections 6(1) to 6(8) and 6(10), and sections 7 to 17 sit in the 18 month group. Rules 3, 5 to 16, 22 and 23 do too. Their computed date is 13 May 2027, interpretation until officially confirmed, with the same uncertainty taking the latest reading to 15 May 2027. The current status article keeps the provision by provision picture.

A practical fintech preparation sequence

These are recommendations, not statutory requirements:

1. Map each customer, employee and partner data flow, then assign the Data Fiduciary and Data Processor roles for that flow rather than for the company as a whole.
2. Record the specified purpose and the section 4 ground. Keep section 7(a) tied to the purpose for which the customer provided the data.
3. Put every Data Processor relationship under a valid contract and make erasure, security and breach actions executable across the chain.
4. If relying on section 17(1)(f), record the default, the financial institution, the ascertainment purpose and the other law that permits disclosure. Keep ordinary processing outside that record.
5. Build retention from the section 8(7) purpose test, then attach the exact sector law behind every longer period. Do not copy the bank Illustration's 10 years into another business without its law.
6. Keep RBI, IRDAI and other sector controls in a separate register so a draft is never presented as a duty and a live sector rule is never lost inside the DPDP plan.

Start with the role checker, review vendors with the processor checklist, and bring the results together in the company compliance plan.