Consent management for Indian fintech and BFSI companies under DPDPA

Private banks are sitting on a privacy paradox. The customer data that powers personalization, risk management, and growth today was often collected at a time when privacy regulations looked very different. KYC records from years ago, loan applications, transaction histories, and behavioural data have all become valuable business assets. They are also now subject to a very different set of expectations around consent, transparency, and accountability.

What makes the situation even more complicated is that DPDPA is not the only regulation banks need to think about. The BFSI sector has spent years adapting to requirements from RBI, SEBI, IRDAI, and other regulators. Teams have built processes, systems, and controls around those obligations, often over long periods of time.

Now DPDPA enters the picture and raises a new set of questions. How do you honour a customer's right to withdraw consent when certain records must be retained for regulatory reasons? How do you introduce new privacy controls without disrupting existing compliance processes?

That is why DPDPA For BFSI feels different from other sectors. The challenge is not simply complying with another regulation. It is finding a way to fit new privacy obligations into an ecosystem that is already heavily regulated, highly interconnected, and difficult to change overnight. and this applies as much to fast-moving fintechs and NBFCs as it does to traditional banks. DPDPA compliance for fintech players, in fact, often carries even less institutional buffer than legacy banks have. 

The Scale of the Problem Is Unlike Any Other Sector

A mid-sized private bank with 10 million customers might hold KYC documents, income verification records, credit scores and bureau data, full transaction histories going back years, insurance policy details, investment portfolios and behavioural data from mobile banking apps tracking every tap and session.

A bank doesn't need one consent from a customer. It needs a separate one for every purpose it uses that customer's data for like marketing, analytics, partner sharing, personalisation. Under DPDPA, every processing activity across all these categories requires a valid legal basis, explicitly documented. For most banks, mapping what they actually have and establishing what basis applies to each activity is a six-month exercise before they even start building consent infrastructure.

NBFCs face the same exposure, often with even less compliance infrastructure in place. And lending NBFCs that use alternative data like device signals, app usage, or location history to make credit decisions are sitting in one of the highest-risk zones under the Act. 

For a broader look at how these obligations apply regardless of sector, see key obligations every data fiduciary must know under the DPDP Rules 2025

What are the three compliance Gaps banks need to fix first.

Marketing consent is the most immediate gap. Most banks have been sending product promotion emails, SMS campaigns, and push notifications for years. Some of this was opt-in. Most of it was default behaviour that customers never explicitly agreed to. Under DPDPA, marketing communications require explicit, per-purpose consent which should be separate from the consent given when a customer opened their account. Separate specifically from consent for core banking services.

This is not a minor adjustment. It means your marketing database needs to be audited for consent provenance. Every contact who was added to a marketing list without a DPDPA-compliant consent event needs to be either re-consented or suppressed before the next campaign.

KYC data has boundaries that banks frequently cross. KYC data collected under RBI's Know Your Customer guidelines has a legitimate use basis under Section 7 of the DPDPA but only for the regulatory purpose it was collected for. Using that same KYC data to feed a cross-sell analytics model, or to power a personalisation engine, or to train an AI credit scoring system, requires separate consent. The regulatory basis does not extend beyond the regulatory purpose.

This is a distinction many banks have not yet drawn clearly in their systems. The same customer record is often used simultaneously for compliance purposes and commercial ones, with no technical boundary between them.

Third-party data sharing is systematically under documented. Banks routinely share customer data with insurance partners, investment platforms, credit bureaus, analytics vendors, and co-lending partners. Under DPDPA, each of these arrangements requires either explicit customer consent for the data transfer, or a clearly contracted and documented basis. Most current partner agreements were not written with DPDPA in mind. A systematic review of every data sharing arrangement, mapping what data goes where and under what basis, is a foundational compliance task.

Cookie Consent  The Digital Banking Blind Spot
Cookie consent is one of the most overlooked pieces of DPDP compliance for banks and one of the easiest to get wrong in plain sight. Net banking portals, investment platforms, insurance comparison tools, and mobile banking apps all rely on analytics cookies, session tracking, and often third-party advertising pixels to measure engagement and retarget customers.

Under DPDPA, non-essential cookies anything beyond what's strictly necessary to run the transaction or session require genuine opt-in consent before they fire. A banner that simply notifies users cookies are in use, without letting them decline analytics or marketing cookies independently, does not meet the standard. Most BFSI websites currently run this way.

The stakes are higher here than in general e-commerce: a cookie or SDK on a banking platform can capture device fingerprints, session behaviour, and location data alongside financial context, which raises both the sensitivity and the regulatory scrutiny. A cookie and SDK audit covering web properties, mobile apps, and any embedded partner widgets (like a co-branded insurance quote tool)  should sit alongside the KYC and marketing consent work as a parallel workstream, not an afterthought.

Navigating the RBI-DPDPA Intersection

The RBI's Customer Data Protection Advisory issued in 2025 aligns with DPDPA on many principles but adds bank-specific requirements that sit alongside the Act rather than within it. Both frameworks require transparency, consent, security safeguards, and breach notification. RBI and DPDPA don't always demand the same thing. When they diverge, the stricter standard is the one you follow. No exceptions.

One area where this matters practically: data retention. RBI mandates KYC records be retained for five years after account closure. DPDPA's general principle is that data should not be held beyond the period necessary for its stated purpose. For this specific data category, the RBI requirement applies and provides the legal basis for retention. But that legal basis does not extend to using that retained data for any purpose other than the regulatory one.

Banks designated as Significant Data Fiduciaries under DPDPA will face additional obligations like mandatory DPO appointment, annual Data Protection Impact Assessments, independent audits on top of whatever RBI compliance infrastructure already exists. Running these as parallel programmes is inefficient and creates the risk of contradictory guidance on the same data questions. A unified governance framework that maps each processing activity against both frameworks simultaneously is the right architecture. this is the same principle behind building governance that scales with trust. 

Offline Data Collection The Compliance Gap Nobody Has Fixed Yet

Branch banking generates an enormous volume of personal data that most DPDPA compliance discussions overlook. A national bank with 1,500 branches processing 300 account opening forms per day is bringing roughly 450,000 new personal data records into digital systems every day, each containing multiple sensitive data categories.

All of it is covered by DPDPA. Offline collection is not an exemption.

Current branch forms typically contain a blanket consent clause in small print that covers "use of data for banking purposes and related activities." This doesn't meet DPDPA's specificity requirement. Forms need to be redesigned to present consent items clearly, separately, and in plain language. One for core banking, one for marketing communications, one for data analytics, one for partner sharing.

Branch staff also need training. They are now DPDPA compliance actors. When a customer declines to consent to marketing use of their data at account opening, that decision needs to be recorded in the consent management system at that moment and not handled through a manual workaround that gets resolved later.

Handling sensitive categories consistently across channels is a challenge shared with other regulated sectors see DPDPA for healthcare: sensitive personal data, patient consent, and DSAR rights for a parallel view from a different high-sensitivity domain. 

The Legacy Data Problem Is Acute in BFSI

Most banks have customer relationships that predate DPDPA by decades. The one-time notice requirement for legacy data means sending a compliant notice to your entire existing customer base and at BFSI scale, that means millions of customers across current accounts, savings accounts, loans, insurance policies, and investment products.

This is not a marketing campaign. It requires a verified contact database, a consent management system that records responses in real time, immediate enforcement when a customer withdraws consent for any purpose, and an audit trail proving that every customer was notified.

The technical complexity is significant. The legal exposure for not doing it is larger.

What a DPDPA-Ready BFSI Data Stack Actually Looks Like

The compliance architecture that BFSI organisations need is not a new system built alongside existing infrastructure. It needs to be embedded into the core customer data layer.

A consent management platform that captures per-purpose consent at every customer touchpoint like digital, physical, and assisted channels. A real-time enforcement cache that queries consent status before any processing operation executes. An immutable audit log that records every consent event with timestamps, notice versions, and channel information. Integration with your CRM and marketing platforms to enforce consent status in campaign execution.

The audit log architecture is especially important for BFSI. The Data Protection Board may ask for evidence of consent events from years in the past. A mutable database record that can be edited doesn't qualify as compliance evidence. Append-only, tamper-proof consent records are the infrastructure standard that BFSI organisations need to build to.

OneConsent provides the consent management infrastructure that BFSI organisations need to capture per purpose consent across digital and offline channels, real-time enforcement, and the immutable audit trail required for both DPDPA and RBI regulatory review.

This Cannot Be a Separate Workstream

The instinct in large organisations is to create a DPDPA compliance workstream. A project team, a timeline, a deliverables list that runs parallel to the business. That approach will fail for BFSI.

DPDPA compliance is not a project. It is a change to how your organisation processes personal data. It needs to be embedded into account opening workflows, campaign execution systems, KYC processes, partner data sharing agreements, and branch operations. That level of integration requires buy-in from technology, legal, operations, marketing, and the Board. Not just a compliance team working in isolation.

Organisations that delay will face something harder than proactive compliance: retroactive compliance under active regulatory scrutiny, with the Data Protection Board already watching.