DPDP Act for Fintech Companies in India: What RBI-Regulated Firms Must Know

Fintech is the hardest place in India to get DPDP compliance right — because you are already regulated, and that regulation does not go away.

RBI rules tell you to collect and retain certain data. The DPDP Act 2023 tells you to minimise it, get granular consent for it, and erase it when its purpose is served. These mandates do not cancel out. They stack. With the DPDP Rules 2025 notified on 13 November 2025 and full enforcement expected around May 2027, fintechs now have to satisfy both regimes at once.

This guide maps where RBI and DPDP collide, where DPDP goes further than your current onboarding flow, and exactly what to fix before the deadline.

Why Fintech Faces a "Dual Compliance" Mandate

Fintechs hold the most sensitive identity-and-money data in the country: PAN, Aadhaar-linked KYC, bank accounts and UPI handles, full transaction histories, credit behaviour, income data, and health or insurance proxies.

You are also almost always a Data Fiduciary — the entity that decides why and how personal data is processed — not a mere processor. That means the full weight of DPDP obligations applies to you directly. And large fintechs are prime candidates to be designated Significant Data Fiduciaries under §10(1), which adds a further layer (covered below).

What DPDP Adds on Top of Existing RBI Rules

RBI's framework is built around operational risk, financial stability, and consumer protection. DPDP is built around the individual's control over their personal data. They overlap but are not the same lens. DPDP adds obligations RBI never imposed:

• Granular, unbundled consent for each purpose (§6, Rule 3)
• Easy withdrawal of consent, and a duty to cease processing on withdrawal (§6(5), §6(6))
• Purpose limitation and erasure when the purpose is served (§8(7))
• Data Principal rights — access, correction, erasure, grievance redressal (§11–§14)
• Breach notification to the Data Protection Board on top of CERT-In and RBI channels

The One Misconception That Creates the Most Risk

Being RBI-regulated is not a DPDP exemption. It legitimises KYC because the law mandates KYC. It does not legitimise your marketing, your cross-sell, your analytics, or any credit scoring beyond what the regulation actually requires. We return to the precise boundary of §7(g) below.

The Data Fintechs Hold — and Why It Makes Them Prime Targets

The exposure differs sharply by sub-vertical. Map your own data estate against this:

Sub-vertical	Personal data typically held
UPI / payments	VPA, linked bank accounts, device IDs, transaction graph, geolocation
Digital lending / BNPL	PAN, Aadhaar/KYC, bank statements (via AA), bureau pulls, alternative data (SMS/contacts on older flows)
Insurtech	Health declarations, nominee data, beneficiary PII
Wealthtech / broking	PAN, demat details, income/net-worth, risk-profiling responses

The alternative-data column in digital lending is a live flashpoint. Older flows that scraped SMS inboxes and contact lists to score thin-file borrowers are now squarely in conflict with both RBI's Digital Lending Guidelines and DPDP's data-minimisation principle.

Consent Under DPDP — Where Most Fintechs Are Already Non-Compliant

This is where the gap between law and live product is widest. Most fintech onboarding flows in production today do not meet §6 as written.

What §6 Actually Requires (vs Your Current Onboarding Flow)

Section 6(1) requires consent that is free, specific, informed, unconditional, and unambiguous, given through a clear affirmative action, and limited to the data necessary for the stated purpose. Rule 3 of the DPDP Rules 2025 then requires the consent notice to be standalone, in plain language, and itemised — listing each category of data and each specific purpose.

Section 6 also gives users teeth:

• §6(5): withdrawing consent must be as easy as giving it.
• §6(6): on withdrawal, the fiduciary and its processors must cease processing within a reasonable time.

If your product can capture consent in one tap but requires an email and a five-day wait to withdraw it, you fail §6(5). If withdrawal does not actually stop downstream processing in your data pipeline and your vendors', you fail §6(6).

The Cross-Sell Consent Trap

Fintech growth economics run on cross-sell: open a wallet, then pre-approve a loan, then pitch insurance. DPDP collides with this directly.

Data collected for wallet-opening cannot be repurposed for loan pre-approval or insurance cross-sell without fresh, specific consent (§6(1) purpose-specificity plus §8(7) purpose limitation). The consent that onboarded the user for payments does not stretch to underwriting or insurance marketing. Each new purpose needs its own notice and its own affirmative action.

The Section 7 "Legitimate Uses" List — and What's NOT on It

DPDP has no "legitimate interest" ground like GDPR Article 6(1)(f). There is no balancing test you can invoke. Section 7 provides a closed list of "Certain Legitimate Uses" — and if your processing is not on the list, you need consent. Full stop.

For fintech, the relevant entries are narrow:

• §7(b) — provision of State benefits/services. This is largely a State-actor ground. It is not generally available to private fintechs.
• §7(g) — compliance with any law in force. This is the key fintech ground. KYC under PMLA and RBI Master Directions, reporting to Credit Information Companies, statutory FIU-IND reporting — these can rest on §7(g).

On bureau data specifically, note the two directions of flow are treated differently. Furnishing data to CIBIL/Experian/CRIF can rest on §7(g) because the CIC Regulation Act mandates it. Pulling a bureau report to underwrite a new applicant is conventionally consent-based. Do not assume one ground covers both.

The Four Regulatory Conflict Zones You Must Resolve

This is the differentiating work for a fintech compliance programme — reconciling two live regimes. Here are the four zones, and how each resolves:

Conflict area	RBI position	DPDP position	Resolution
Data retention	PMLA / AML mandate retention (often 5–10 years)	§8(7): erase when purpose is served	§8(7) yields to legal-retention requirements. Segment retained-by-law data from delete-on-request data.
Consent	Digital Lending Guidelines restrict device access	§6(1): specific, granular, unbundled consent	DPDP reinforces RBI here — more granular consent required, not less
Data localisation	RBI mandates domestic storage for payment data (PA/PG circulars)	"Negative list" transfer regime (Rule 14)	RBI localisation is mandatory; DPDP adds a broader transfer framework on top
Vendor / processor liability	RBI outsourcing guidelines (operational-risk focus)	§8(2): processor contract mandatory; fiduciary stays primarily liable	Different focus — both required; an RBI outsourcing contract is not a DPDP processor agreement

Data Retention — PMLA Keeps Data, DPDP Deletes It

This is the conflict fintech teams worry about most, and it has a clean resolution. Section 8(7) requires erasure when the purpose is served — but it yields where another law in force requires retention. PMLA/AML retention (typically 5–10 years) is such a law.

The practical fix is data segmentation: tag every record as either "retained because the law requires it" or "delete when the purpose is served / on request." A user's erasure request must purge the second category while lawfully preserving the first. A flat "we keep everything for 10 years because RBI" position fails §8(7); a flat "we delete on request" position fails PMLA. You need both buckets, governed separately.

Consent — Where RBI and DPDP Actually Align

Not every overlap is a conflict. On consent, the two regulators pull the same direction. RBI's Digital Lending Guidelines already restrict the device access and data collection that lending apps can demand. DPDP §6(1) layers granular, unbundled consent on top. Here DPDP reinforces RBI — your compliance work satisfies both at once.

Data Localisation — Two Stacking Requirements

RBI's payment-system circulars mandate that payment data be stored domestically. DPDP, separately, governs cross-border transfers through a "negative list" model under Rule 14 — transfers are permitted except to countries the government restricts. These do not cancel: RBI localisation is a hard floor for payment data, and DPDP's transfer framework applies on top for everything else. You comply with both.

Processor / Vendor Liability

RBI's outsourcing guidelines focus on operational risk. DPDP §8(2) requires a processor contract and keeps the fiduciary primarily liable for what its processors do with personal data. An RBI-compliant outsourcing agreement is not automatically a DPDP-compliant processor agreement — the clauses about purpose limitation, cease-on-withdrawal (§6(6)), and breach cooperation are DPDP-specific. Both contracts are required.

Account Aggregator and the Unsettled Consent-Manager Question

The Account Aggregator (DEPA) framework already issues purpose-specific, time-bound consent artefacts — and those align well with §6's specificity requirement. But DPDP adds obligations the AA artefact alone does not satisfy: §6(5) easy withdrawal, §6(6) cease-processing, and the §11–§14 Data Principal rights over data pulled through an AA.

Children's Data — the §9 Obligation Fintechs Underestimate

A child under DPDP is anyone under 18 — not 13 or 16 as under GDPR/COPPA-style regimes. That single fact reshapes the obligation for any product a minor can reach.

• §9(1): verifiable parental consent is required before any processing of a child's data.
• §9(3): an absolute ban on tracking, behavioural monitoring, and targeted advertising directed at children — even with parental consent. There is no consent that buys you out of this.
• Rule 10: the fiduciary must verify parental identity using identity/age data it already holds, data the parent voluntarily provides, or a virtual token issued by an authorised entity.

For fintech, this bites in places teams do not expect: Jan Dhan and minor accounts, family-shared devices and phone numbers, and any flow where a 17-year-old can actually complete sign-up. "Our product is for adults" is not a defence if minors can in fact register. You need real age-gating, not a disclaimer.

Will Your Fintech Be a Significant Data Fiduciary?

Section 10 lets the Central Government designate specific fiduciaries as Significant Data Fiduciaries based on factors including the volume and sensitivity of data processed and risk to the sovereignty, integrity, and security of India — including financial stability.

If designated, the additional obligations are substantial:

• A Data Protection Officer based in India, reporting to the board or governing body
• An independent Data Auditor
• A DPIA and audit every 12 months (Rules 12/13)
• Algorithmic due diligence on automated systems — directly relevant to ML credit-scoring and fraud models
• Hard data localisation for categories the government specifies

For any fintech running ML-driven underwriting or fraud detection, the algorithmic due-diligence requirement is the one to start scoping now — it touches your core models, not just your paperwork.

DPDP Penalties — What's at Stake for Fintech

Penalties under the Act's Schedule are fixed-rupee caps — not a percentage of turnover — assessed per inquiry and at the Board's discretion:

Failure	Maximum penalty
Failure to take reasonable security safeguards	₹250 crore
Failure to notify a breach	₹200 crore
Non-compliance with children's data obligations	₹200 crore
Non-compliance with SDF obligations	₹150 crore
Breach of any other provision (residual)	₹50 crore

For a fintech, breach exposure is the standout risk. A single incident can stack the ₹250 crore safeguards head and the ₹200 crore notification head — and because breach notification involves CERT-In, RBI, and the Data Protection Board in parallel, the operational failure mode is missing the 72-hour DPDP breach-notification clock while scrambling to meet CERT-In's tighter 6-hour deadline.

For a fuller treatment of the penalty framework and the seven factors the Board weighs, see DPDP Act penalties explained.

A DPDP Compliance Readiness Checklist for Fintechs

These are the ten gaps where Indian fintechs are most often failing today. Work them in order:

1. Bundled onboarding consent — unbundle every purpose into a separately consentable item (§6(1), Rule 3).
2. No withdrawal / cease-processing plumbing — make withdrawal as easy as consent and ensure it actually halts processing downstream (§6(5), §6(6)).
3. Over-collection for credit scoring — minimise to what each purpose needs; retire SMS/contacts scraping.
4. Cross-sell on stale consent — require fresh, specific consent before repurposing data for loans or insurance.
5. Retention sprawl — segment RBI/PMLA-mandated retention from delete-on-request data (§8(7)).
6. Processor contracts not DPDP-compliant — upgrade RBI outsourcing agreements to §8(2) processor agreements.
7. No reconciled breach readiness — one runbook that sequences CERT-In (6h), RBI, and the DPB (the 72-hour DPDP breach-notification clock).
8. Children / age-gating failures — real verifiable parental consent and the §9(3) advertising ban, not a disclaimer.
9. No published DPO contact or grievance SLA — publish a contact and meet the grievance timelines (Rule 9, Rule 14).
10. No SDF readiness planning — scope DPO, independent audit, DPIA cadence, and algorithmic due diligence now.

The 2027 Deadline — What to Do Now

The DPDP Rules 2025 were notified on 13 November 2025, and commencement is phased — some obligations are immediate, others follow 12-month and 18-month timelines, with full enforcement expected around May 2027.

That phased structure is not a reason to wait. The law is live, and the heaviest fintech-relevant work — unbundling consent, building withdrawal plumbing, segmenting retention, reconciling breach timelines, and scoping SDF obligations — takes quarters, not weeks. Fintechs that start now close gaps deliberately; those that wait will rebuild their consent and data architecture under live enforcement.

Start by mapping which obligations apply to your sub-vertical and where your current flows already breach §6. For the full section-by-section framework underneath this guide, read our plain-English DPDP Act guide.

Frequently Asked Questions