A fintech app is a chain of Data Fiduciaries and processors

A fintech is rarely one Data Fiduciary acting alone. A lending app collects data, scores it through a bureau or an analytics partner, disburses through a bank or NBFC, collects through a payments processor, and pushes the borrower to a collections agency. Each of those relationships carries personal data, and the DPDP Act puts the duty to answer for all of it on the firm that decided why the data was collected.

This page covers the Act and Rules only. Sectoral regulators, the RBI among them, continue to apply alongside the Act, because Sec. 38(1) makes it additional to other laws, and the detail of those regimes is for your regulatory counsel. For the banking-sector view, see DPDP compliance for banks and BFSI; this page is about what changes when you are a product company with a partner chain.

Lending apps: purpose creep at onboarding

A typical lending flow asks for identity, contacts, device data, bank statements and location in one sequence of permissions. Sec. 6(1) limits consent to personal data necessary for the specified purpose, and the Act's own illustration is an app that asks for contact-list access along with its service: the consent is limited to what the service needs.

Three screens usually need separate answers: credit assessment, servicing the loan, and everything else, including marketing, cross-sell and model training. Sec. 6(2) makes any part of a consent that infringes the Act invalid to that extent, so a bundled tick does not fall in whole, but the part that reaches past what the purpose needs does not hold. The consent notice has to follow Rule 3: itemised data, specific purposes, and how to withdraw. See consent notice requirements.

Payments: processing that never needed consent

Not every use of data in payments rests on consent. Sec. 7 lists legitimate uses, including voluntary provision for a specified purpose under Sec. 7(a) and processing to fulfil an obligation under Indian law to disclose information to the State under Sec. 7(d). A payment instruction a customer has made falls naturally under Sec. 7(a). Whether a particular fraud-screening or reporting flow fits one of these uses is a question for counsel, not an assumption.

What does not fall within Sec. 7 is the secondary use: analytics on transaction histories to sell a product, or profiling to feed a credit offer from another firm. Those need consent that was asked for separately.

Data shared across partners

Sec. 11 gives a Data Principal the right to obtain a summary of the personal data processed and the identities of all other Data Fiduciaries and Data Processors with whom it has been shared, along with a description of what was shared. For a fintech, that means the sharing map has to exist and be queryable per customer: which bureau, which co-lender, which collections vendor, which analytics tool, and what each received.

Sec. 8(3) adds that where data is likely to be used to make a decision affecting the Data Principal, or disclosed to another Data Fiduciary, the Fiduciary must ensure its completeness, accuracy and consistency. A stale value passed from a lender to a bureau is the risk it describes.

Retention against erasure

Sec. 8(7) requires erasure on withdrawal or once it is reasonable to assume the purpose is no longer served, unless retention is necessary for compliance with law. The Act's illustration is a bank keeping client identity records for ten years after closure because banking law requires it.

A fintech should take the same approach per purpose, not per customer. Records that law requires you to keep are one answer. The marketing profile, the device log and the model-training copy beside them are others. Sec. 8(8) deems the purpose no longer served after a prescribed period of inactivity, and Rule 8(1) sets those periods only for the classes of Data Fiduciary and purposes listed in the Third Schedule, so check whether you appear there. Rule 8(3) separately requires keeping personal data, traffic data and logs of processing for at least one year from the date of processing, unless other law requires longer. The two sit side by side, and reconciliation is per purpose.

The vendor chain

Sec. 8(1) keeps the Data Fiduciary responsible for processing done on its behalf by a Data Processor, "irrespective of any agreement to the contrary", and Sec. 8(2) allows engaging one only under a valid contract. Withdrawal makes this concrete. Under Sec. 6(6) and Sec. 8(7)(b) the Fiduciary must cause its processors to cease processing and to erase. If a collections vendor holds a copy and you cannot tell it to stop, you have breached on the vendor's behalf.

A fintech with a long chain should know, for each vendor: what data it receives, under which purpose, how a withdrawal reaches it, and how it confirms erasure. Rule 6 includes processor security obligations in contracts as part of the minimum safeguards. A fuller treatment will be in vendor management under the DPDP Act.

Breach and security, because a fintech is a target

Sec. 8(5) carries the largest ceiling in the Schedule, up to 250 crore rupees, for failing to take reasonable security safeguards. Rule 6 lists the minimum, including encryption, masking, access control and log retention. Rule 7 runs two breach clocks, one to each affected Data Principal without delay and one to the Board with the detailed report in 72 hours. The amount is set by the Board after an inquiry, weighing the factors in Sec. 33(2). Whether a fintech is notified as a Significant Data Fiduciary under Sec. 10(1) depends on the volume and sensitivity of the data, and a lender or payments firm should assume it could be. The substantive duties commence on 13 May 2027.