Compliance
DPDP Compliance for Banks: Myths, Reality, and How to Get SDF-Ready Fast
By Charanjeet Singh, Co-Founder, IndiaConsent
DPDP Compliance for Banks: Myths, Reality, and How to Get SDF-Ready Fast
A bank's DPDP exposure isn't the same shape as an insurer's or an e-commerce company's, and treating it as a generic "financial sector" compliance checklist is exactly how banks end up under-prepared. Banks carry decades of customer data across legacy core banking systems, collect KYC on paper at thousands of branches long before any of it touches a server, and route data through a wider web of DSAs, business correspondents, and cross-sell partners than almost any other regulated sector. This post covers what makes banking's DPDP problem structurally different, the specific myths we hear most often from bank compliance teams, and the fastest realistic path to readiness given that most banks will almost certainly be classified Significant Data Fiduciaries (SDFs) once that classification mechanism is used.
Why banking's DPDP exposure looks different from other sectors
Four things make a bank's compliance problem genuinely distinct, not just a bigger version of the same problem every regulated business faces.
Decades of data with no clean purpose trail. A core banking system that's been running for 20-30 years holds personal data collected under processes, forms, and consent language that predate DPDP by a generation. Retrofitting a defensible legal basis onto data collected in 2004 is a different exercise than building consent architecture into a five-year-old fintech app.
Physical branches still generate a huge share of new personal data. Account-opening forms, loan applications, and locker agreements are still filled out on paper at branch counters across the country before anyone digitises them — and DPDP's scope doesn't stop at the point of digitisation, which is a genuinely important, easy-to-miss fact covered below.
The data-sharing web is wider than banks usually account for. Direct Selling Agents, Business Correspondents, recovery and collection agents, credit bureaus, and cross-sell partners for insurance and mutual funds all touch the same customer data — each one is a distinct processing or sharing relationship a bank needs to account for, not a single "internal system."
Employee data at a scale most sectors don't match. Large public and private banks run workforces in the tens of thousands to hundreds of thousands, and HR/payroll/performance data at that scale carries its own DPDP surface, separate from the customer-facing side entirely.
Myths vs. reality
| Myth banks commonly believe | The reality under the DPDP Act |
|---|---|
| "We already meet RBI's KYC requirements, so we're DPDP compliant." | RBI's KYC framework and DPDP's consent regime are separate and independently enforceable. DPDP consent must meet Section 6's six conditions — free, specific, informed, unconditional, unambiguous, and withdrawable — which RBI's KYC due-diligence process was never designed to satisfy on its own. |
| "Customer data we collected years ago, before DPDP existed, isn't covered." | Section 5(2) specifically addresses this: for consent obtained before the Act's commencement, the Data Fiduciary must still give the Data Principal a compliant notice "as soon as it is reasonably practicable." Legacy data doesn't get a pass — it gets a catch-up obligation. |
| "We're a public sector bank, so government entities are exempt anyway." | Section 17(2) only exempts a specific state instrumentality that the Central Government has expressly notified, for defined purposes like sovereignty, security of the state, or research/statistical work — there is no blanket exemption for government ownership, and ordinary commercial banking activity by a PSU bank doesn't qualify. |
| "The account-opening terms-and-conditions checkbox is our DPDP consent." | Section 6 requires consent through "clear affirmative action," not silence, inaction, or a pre-checked box, and requires it to be specific to a stated purpose rather than bundled into general T&Cs. A single omnibus checkbox covering account opening, marketing, and data sharing all at once is very unlikely to hold up as "specific" consent. |
| "We don't sell customer data, so our third-party exposure is low." | Every DSA, business correspondent, recovery agent, or cross-sell partner a bank engages to process personal data on its behalf needs a valid contract under Section 8(2) — sharing doesn't have to mean selling to create an obligation, and most banks have more of these relationships than their compliance inventory currently reflects. |
| "Paper KYC forms at branches are outside DPDP's scope since it only covers 'digital' data." | Section 3(a) applies the Act to personal data collected "in digital form" or "in non-digital form and digitised subsequently" — a paper KYC form is squarely in scope the moment it's entered into the core banking system, which for most banks is almost immediately. |
| "Employee data is HR's problem, not a DPDP one." | Employee data is still personal data under the Act; Section 7(i) gives employment-related processing an easier legitimate-use basis than full consent, but that's a lighter compliance path, not an exemption from the Act altogether. |
How a bank gets SDF-ready fast
Banks aren't formally designated Significant Data Fiduciaries yet — that classification under Section 10(1) hasn't been notified for any entity as of this writing — but the volume and sensitivity of banking data make it a near-certainty, and Section 10's obligations commence on 13 May 2027 alongside the rest of Chapter II. The realistic path to readiness isn't "do everything at once"; it's sequencing the few things that are both high-effort and hard to retrofit later.
Start with the data map that actually matters
Don't start with a generic enterprise-wide data inventory. Start with the two highest-volume, highest-risk flows specifically: core banking system data (the 20-year accumulation problem) and the DSA/BC/cross-sell sharing network (the third-party exposure problem). Everything else can be mapped in parallel, but these two are where the real retrofitting work is, and they take the longest to get right.
Fix the consent notice where it generates the most volume
Account opening is the single highest-volume consent event a bank runs. Rebuilding that one notice and consent flow to meet Section 5's notice requirements and Section 6's six conditions — unbundled from general T&Cs, specific per purpose, with a withdrawal mechanism as easy to use as the original consent — fixes the largest share of a bank's consent exposure with one project, rather than fixing dozens of smaller consent touchpoints first.
Get the board and DPO structure ready before it's mandatory
Section 10(2)(a)(iii) will require an India-based DPO responsible to the Board of Directors once SDF obligations commence. Building that reporting line now, ahead of the May 2027 deadline, means the bank isn't standing up governance and its first Data Protection Impact Assessment in the same quarter that penalties become enforceable.
Build the breach playbook now
Section 8(5)'s security-safeguards duty and Section 8(6)'s breach-notification duty both commence on the same date as SDF obligations, and Section 8(5) carries the highest penalty ceiling in the Act's Schedule — up to ₹250 crore. A tested breach-response runbook is far cheaper to build calmly in 2026 than to improvise during an actual incident after May 2027.
Compliance timeline
- Now: Sections 5, 6, and 8(2) (notice, consent conditions, processor contracts) are not yet in force — they commence alongside the rest of Chapter II on 13 May 2027 — but the retrofitting work they require (rebuilding consent flows, mapping processor relationships) takes long enough that starting now, not in April 2027, is the only realistic way to be ready.
- 13 November 2026: Rule 4 (Consent Manager registration) comes into force.
- 13 May 2027: Sections 3–10 and 11–17 of the DPDP Act, and the corresponding Rules, come into force — this is when SDF obligations, consent conditions, and security-safeguard duties all become enforceable together.
Frequently Asked Questions
Does RBI's KYC compliance also satisfy DPDP Act requirements for banks?
No — RBI's KYC framework and the DPDP Act's consent regime are separate, independently enforceable requirements, and meeting one does not automatically satisfy the other.
Is personal data collected by a bank before the DPDP Act existed exempt from it?
No — Section 5(2) requires a Data Fiduciary to give a DPDP-compliant notice for pre-Act consents "as soon as it is reasonably practicable," so legacy data carries a catch-up obligation rather than an exemption.
Are public sector banks exempt from the DPDP Act because they're government-owned?
No — Section 17(2) only exempts a specific state instrumentality that the Central Government has expressly notified for defined purposes such as sovereignty or security of the state, not government ownership in general.
Does the DPDP Act apply to paper KYC forms collected at a bank branch?
Yes — Section 3(a) applies the Act to personal data collected in non-digital form and subsequently digitised, so a paper KYC form is in scope once it's entered into the bank's systems.
Do banks need a contract with every third party that touches customer data, like DSAs or recovery agents?
Yes — Section 8(2) requires a valid contract wherever a Data Fiduciary engages a Data Processor to process personal data on its behalf, which covers DSAs, business correspondents, and recovery agents handling customer data for the bank.
Related Articles & Internal Resources
- Navigating DPDP Compliance in India's Banking Sector
- Implementing Consent Management Under DPDP Act 2023
- DPDP Compliance Checklist for Enterprises
- DPDP Compliance in Financial Services