DPDP Act and KYC: What Fintech Companies Need to Know About India’s New Data Protection Framework

India’s Digital Personal Data Protection Act 2023 and the DPDP Rules notified in November 2025 — with an 18-month compliance deadline of May 2027 — have changed the legal landscape for every organisation that processes customer personal data. For fintechs and NBFCs, the impact is particularly acute: KYC workflows are inherently data-intensive, involving the collection of Aadhaar, PAN, photographs, financial statements, and address proof. The same data flows that satisfy RBI KYC requirements are now subject to a second, overlapping compliance framework with its own consent, retention, purpose limitation, and data rights obligations. Non-compliance attracts penalties up to ₹250 crore. This guide explains what the DPDP Act changes for KYC-intensive fintechs and what dual compliance — RBI plus DPDP — actually requires in operational terms.

Table of Contents

1. The Dual Compliance Mandate: RBI KYC + DPDP Act
2. Consent Under DPDP: What Changes for KYC Data Collection
3. Purpose Limitation and Data Minimisation in KYC Workflows
4. KYC Data Retention: Reconciling RBI and DPDP Requirements
5. Vendor and LSP Obligations Under DPDP
6. Building DPDP-Compliant KYC Workflows: A Practical Framework
7. Key Takeaways
8. Frequently Asked Questions
9. Conclusion

The Dual Compliance Mandate: RBI KYC + DPDP Act

India’s fintech ecosystem now operates under two intersecting compliance regimes. The RBI KYC Master Directions establish what data must be collected, from whom, and how it must be verified. The DPDP Act establishes how that data may be used, how long it can be retained, and what rights the data subject has over it. The two frameworks share the objective of protecting consumers, but they do not always align on the operational details — creating genuine complexity for compliance teams.

The most important point of interaction is consent. The DPDP Act requires explicit, informed consent for the collection and processing of personal data, with a clear statement of purpose. The RBI KYC Master Directions permit — and in some cases require — the collection of identity and financial data as a regulatory obligation. The DPDP Rules clarify that “legitimate use” — processing necessary to comply with a law or regulation — can substitute for consent in specific cases. For RBI-mandated KYC, this means the legal basis for data collection is the regulatory obligation rather than consent. However, any processing that goes beyond the minimum required for regulatory compliance — such as using KYC data for marketing or credit scoring beyond the origination decision — requires specific consent.

Fintechs that use KYC data for purposes beyond the RBI mandate — cross-selling, behavioural profiling, alternative credit scoring — must ensure that consent for these additional purposes is separately obtained, clearly described, and revocable by the customer on request.

Consent Under DPDP: What Changes for KYC Data Collection

The DPDP Act requires that consent be free, specific, informed, and revocable. The consent notice must describe in plain language: what data is being collected, the specific purpose for which it will be used, with whom it will be shared, and how long it will be retained. Pre-checked boxes, bundled consents (one consent for multiple unrelated purposes), or consents buried in terms and conditions do not meet the standard.

For KYC for fintech workflows, this has two operational implications. First, the onboarding consent flow must clearly distinguish between data collected to satisfy RBI KYC requirements (for which the legal basis is regulatory obligation) and data collected for any additional purpose (for which explicit consent is required). Second, the consent record — including the timestamp, the consent text presented to the user, and the user’s affirmative action — must be maintained for the audit trail required under the DPDP Rules.

Fintechs using LSPs (Lending Service Partners) or third-party KYC vendors must ensure that their vendor contracts specify that the vendor will only process data for the stated purposes and will not retain, share, or reuse KYC data beyond what the fintech has disclosed to the customer. A vendor data processing agreement that is silent on purpose limitation and retention is a DPDP Act compliance risk.

Purpose Limitation and Data Minimisation in KYC Workflows

Purpose limitation — the requirement that data collected for one purpose not be used for a different, unrelated purpose without fresh consent — creates a direct constraint on how KYC data can be used downstream. Data collected for Aadhaar-based eKYC at account opening cannot subsequently be used for location analytics, marketing segmentation, or alternative credit modelling without specific consent for each of those purposes.

Data minimisation — collecting only what is necessary for the stated purpose — creates pressure on KYC workflows that have historically collected more data than required. An onboarding flow that requests income documents, employment details, and utility bills when only Aadhaar and PAN are required for the KYC purpose must justify each additional data point. The DPDP Rules place the burden of justification on the Data Fiduciary (the fintech) rather than requiring the user to object.

For biometric data — which is classified as sensitive personal data — stricter handling obligations apply. Aadhaar biometric authentication data retrieved via UIDAI cannot be stored locally under UIDAI rules; this restriction is reinforced by DPDP. Any liveness check data that constitutes biometric information must have a defined retention purpose and deletion schedule.

KYC Data Retention: Reconciling RBI and DPDP Requirements

The RBI KYC Master Directions require Regulated Entities to retain KYC records for at least five years after the end of the business relationship. PMLA requires transaction records to be maintained for ten years. The DPDP Act requires that personal data be retained only for as long as necessary for the purpose for which it was collected — with mandatory deletion once the purpose is fulfilled or the legal retention period expires.

For most KYC data, the RBI and PMLA retention obligations define the minimum retention period, and the DPDP Rules recognise that legal obligations can extend the retention period beyond what the DPDP Act’s default minimisation principle would otherwise require. The operative conclusion: KYC records must be retained for the period required by the applicable financial regulation, and must be deleted — with a documented deletion log — at the end of that period.

The practical challenge is not the retention period itself but the deletion process. Many fintech data architectures retain data indefinitely in data warehouses and analytics pipelines. The DPDP Rules require that deletion be technically enforced, not just policy-stated. Organisations that have not built data lifecycle management into their architecture — with automated deletion triggers at the end of defined retention periods — face significant remediation effort before the May 2027 compliance deadline.

Vendor and LSP Obligations Under DPDP

The DPDP Act places obligations on both Data Fiduciaries (the entity that determines the purpose and means of processing) and Data Processors (entities that process data on behalf of the Fiduciary, under contract). For fintechs, any third-party KYC vendor, LSP, or verification API provider that handles customer personal data is a Data Processor.

The fintech must ensure that its contracts with these processors include specific provisions: limitations on data use (processor may only use data for the services provided), security standards, deletion obligations at contract termination, sub-processing restrictions, and breach notification timelines. A vendor who is ISO 27001 certified provides a baseline security assurance but not automatically a DPDP compliance assurance — the contractual obligations must be separately addressed.

For Aadhaar-based KYC vendors, the UIDAI framework already imposes strict data handling restrictions that align with DPDP’s requirements. However, for non-Aadhaar verification data — PAN, GST, document images — the DPDP data processor obligations must be explicitly addressed in vendor agreements.

Building DPDP-Compliant KYC Workflows: A Practical Framework

A DPDP-compliant KYC workflow for fintechs has six components. First, a layered consent architecture that clearly separates regulatory-basis data collection from consent-basis processing, with a separate consent for each additional use case. Second, a purpose limitation registry that documents, for every data point collected, the purpose, legal basis, retention period, and deletion trigger. Third, data minimisation review — a periodic audit of what data is being collected against what is required for each stated purpose. Fourth, vendor data processing agreements that explicitly address all DPDP requirements for each processor in the data chain. Fifth, a data subject rights workflow — enabling customers to access, correct, and request deletion of their data, with a 30-day response SLA mandated by the Rules. Sixth, a breach response protocol — the DPDP Rules require notification to the Data Protection Board within 72 hours of becoming aware of a personal data breach.

DPDP Act Implementation Roadmap for Fintechs: Where to Start

With the DPDP Act compliance deadline of May 2027 approaching, fintechs and NBFCs that have not yet begun structured implementation planning face increasing time pressure. The scope of changes required — consent architecture redesign, data lifecycle management implementation, vendor contract restructuring, and data subject rights workflow creation — is not achievable in the final three months before the deadline. The organisations that will be compliant on time are those that have structured their implementation as a phased programme beginning now.

The implementation roadmap that most compliance teams are following has four phases. Phase one (months one to three) is data mapping: creating a comprehensive inventory of what personal data is collected, where it is stored, how long it is retained, with whom it is shared, and what the legal basis for each processing activity is. Without this foundation, subsequent compliance work is directionally blind.

Phase two (months three to six) is gap analysis: comparing the data map against DPDP Act requirements, identifying where the current processing activities do not meet the standard (purpose limitation violations, consent gaps, retention periods without deletion enforcement, vendor contracts without adequate data processor obligations).

Phase three (months six to fifteen) is remediation: implementing the changes identified in the gap analysis — restructuring consent flows, building data deletion automation, renegotiating vendor contracts, creating the data subject rights handling workflow, and establishing the breach notification process. Phase four (months fifteen to eighteen) is audit and validation: testing the implemented controls against the DPDP Rules requirements, conducting a mock Data Protection Board inspection, and confirming that the implemented changes are functioning as designed. Beginning this programme now is not premature — it is necessary.

Key Takeaways

• The DPDP Act creates a dual compliance mandate alongside RBI KYC requirements — the same KYC data flows now have both regulatory obligations and data protection obligations.
• Consent under DPDP must be free, specific, and revocable — bundled or pre-checked consents do not comply; KYC data used beyond the regulatory minimum requires separate, explicit consent.
• Purpose limitation restricts the use of KYC data to the stated purpose — using Aadhaar eKYC data for marketing or alternative scoring without specific consent is a DPDP violation.
• KYC data retention must align with RBI/PMLA minimum periods AND include automated deletion at the end of those periods — indefinite retention in data warehouses is non-compliant.
• Vendor and LSP contracts must explicitly address DPDP data processor obligations — ISO 27001 certification is necessary but not sufficient for DPDP compliance.

Frequently Asked Questions

Conclusion

The DPDP Act does not make compliance harder for fintechs that have already built thoughtful, minimal KYC workflows. It makes compliance harder for those that have historically collected more data than needed, retained it longer than required, and shared it more broadly than customers expected. The May 2027 deadline is close enough that the planning and implementation work needs to start now — particularly for data lifecycle management, vendor contract restructuring, and consent architecture redesign, which are not quick fixes.