DPDPA Compliance for Fintechs in India

Usually both, in different places, and the whole compliance design depends on separating them. Where you source, onboard and service borrowers strictly on the lender's instructions for the lender's loan, you are a Data Processor: you may process only under a valid written contract with the lender specifying purpose, security obligations, sub-processing limits and deletion on exit, and the lender carries fiduciary liability. But the moment you process for your own purposes — building a proprietary risk model, cross-selling insurance or a second product, retaining rejected applicants for your own funnel, running marketing or app analytics — you are determining the purpose yourself, which makes you a Data Fiduciary with your own notice and lawful-ground obligations. Section 6 consent is the default; Section 7 legitimate uses are a closed list and none of them covers commercial lending, credit assessment, cross-sell or collections. Two consequences worth planning for: you need to be able to say, per data element, which hat you were wearing when you collected it, and your lender agreements should allocate roles explicitly rather than leaving it to be inferred later. None of this displaces RBI's digital lending directions on data collection, storage and disclosure — those continue to bind you independently.

No. Section 6 consent must be free, specific, informed, unconditional and unambiguous, given by clear affirmative action, and limited to the personal data necessary for the specified purpose — with a notice that itemises purposes in plain language, in English or any Eighth Schedule language, and withdrawal as easy as giving. An OS-level permission prompt, a terms-and-conditions checkbox, or a bundled "I agree" covering onboarding, underwriting, marketing, analytics and partner sharing in one action fails on specificity and on the unconditional requirement — you cannot make access to the product contingent on consent to purposes the product doesn't need. Practically this means: separate the underwriting purpose from the marketing purpose from the analytics purpose; stop collecting contact lists and SMS content unless you can state a necessary purpose and defend it, noting RBI's digital lending directions independently restrict access to phone resources; and audit your embedded SDKs, because an attribution or analytics SDK shipping device identifiers to a third party is processing you are answerable for whether or not product told legal about it. Two more points: DPDPA has no separate "sensitive personal data" tier, so a bank statement, a location trail and a phone number sit under one standard — the difference is the harm, not the rule; and any user under 18 triggers Section 9, requiring verifiable parental consent and barring behavioural tracking and targeted advertising directed at that child, which is a hard constraint on teen-focused products.

It covers one link in the chain, not your whole position. In the AA framework the aggregator is a consent intermediary and the artefact records the user's approval for a specified data flow from the financial information provider to you as the financial information user, for a stated purpose and duration. That artefact is strong evidence for the retrieval itself, and the AA is separately regulated by RBI. What it does not do is authorise everything downstream: how long you keep the statement after the credit decision, whether you re-use it to score the user for a different product, whether you share derived insights with a partner, or whether you can retain it after the artefact expires or is revoked. Those are your purposes, needing your own notice and lawful ground, and the artefact's stated purpose and validity period are a ceiling you can't quietly exceed. A revocation upstream should propagate through your systems and your partners' — build the plumbing for that now rather than discovering it in an audit. DPDPA's consent-manager provisions and the AA framework are also separate regimes; a registered AA is not automatically a DPDPA consent manager, and vice versa.

On breach: two clocks start at detection and both must be met; they are cumulative, not alternatives. CERT-In requires reporting of covered cyber incidents within 6 hours. Separately under DPDPA, you must intimate every affected user without delay (Rule 7(1)), give the Board an initial description without delay (Rule 7(2)(a)), and file detailed particulars within 72 hours (Rule 7(2)(b)). If you're RBI-regulated or a partner to a regulated entity, incident reporting to the Regulator runs alongside, and your lender contracts will usually impose their own notification timelines — build one playbook that satisfies all of them, with a named owner and pre-drafted templates, because the 6-hour clock does not survive an improvised escalation. Failure to maintain reasonable security safeguards attracts up to ₹250 crore, and failure to give the required breach intimation is assessed separately at up to ₹200 crore. Note that a ransomware event with no confirmed exfiltration is still a personal data breach if it caused loss of access to the data; "nothing was stolen" is not an exemption. On SDF status: it is conferred by Central Government notification, assessed against factors including the volume and sensitivity of personal data processed and risk to the rights of Data Principals, sovereignty, electoral democracy and public order — not triggered automatically by user count or funding stage. But a consumer fintech processing financial data at national scale is a more plausible candidate than most sectors, so it is worth building toward Rule 13 readiness (and remember Rule 15 transfer restrictions can bind any fiduciary transferring data abroad; Rule 13(4) localisation is SDF-specific) — annual DPIA, independent data audit, algorithmic due diligence over your models, and an India-based Data Protection Officer reporting to your board — rather than assuming you'll be outside it. Until notified, you owe the baseline duties in full: valid consent, purpose limitation, accuracy, erasure once the purpose and any statutory retention period end, security safeguards, breach notification, and a published grievance channel with a named contact and a response timeline not exceeding ninety days under Rule 14(3).