Implementing DPDPA In Banking: From Legal Text To Live Systems

For the last year, Digital Personal Data Protection Act, 2023 ("DPDPA/Act") functioned largely as a conceptual privacy framework, important in principle but lacking operational specificity. Institutions observed it cautiously, debated theoretical interpretations, and waited for "clarity." That era is over.

The Indian financial sector has, over the last few years, seen multiple publicly reported incidents involving unauthorised access, data leakage and misuse of customer information. In several cases, these incidents have not stemmed from sophisticated external attacks alone, but from weaknesses in vendor access controls, legacy systems, misconfigured databases or excessive internal data access. These incidents have resulted in financial loss, customer harm, regulatory scrutiny and reputational damage.¹

Financial institutions like banks, non-banking financial companies ("NBFCs"), microfinance institutions and more, sit at the centre of this risk landscape. They process highly sensitive personal and financial data, operate across complex technology stacks, and rely extensively on outsourced service providers, fintech partners and analytics platforms. While the Reserve Bank of India ("RBI") has long treated data security and cyber resilience as prudential concerns, recent incidents have underscored that security controls alone do not fully address questions of purpose, proportionality and accountability in data use

With the notification of the DPDPA Rules, data protection has moved from a largely risk-management discussion to a rights-based compliance regime. As a result, financial institutions now face a clear expectation. Compliance must be implemented, not merely understood. This article explains what this transition means for the financial sector and how institutions can translate DPDPA's legal framework into operational reality.

WHAT DPDPA ACTUALLY CHANGES FOR FINANCIAL INSTITUTIONS

Many discussions around the Act focus on rights and penalties, but the real impact lies in how DPDPA interacts with existing banking workflows. Unlike e-commerce or social media platforms, financial institutions operate across interlinked systems including core banking, LOS/LMS, CRM, AML engines, fraud platforms, document repositories and data lakes.

These systems were built over decades for resilience and reporting, with limited consideration for purpose-level tagging, partial erasure, consent-based separation, traceability across processors or granular rights compliance. While the Act does not prescribe specific system framework, it effectively requires purpose-bound data design and more granular control over how personal data is stored, shared and retired.

The introduction of the Rules also warrants an actionable compliance plan. DPDPA requires institutions to be able to identify the purpose behind each category of personal data, determine whether that purpose continues to subsist, and demonstrate that statutory retention obligations such as those under PMLA, RBI's KYC norms and credit reporting rules are honoured while non-essential data is either deleted or anonymised.

Fintech partnerships add further complexity. Lending apps, account aggregators, KYC utilities, analytics vendors, etc., often hold partial or derived copies of customer data. Under DPDPA, financial institutions must be able to govern and audit these data flows with precision, ensuring that processing by third parties remains aligned with the original purpose, consent framework and retention limits.

In practice, many financial institutions cannot today state with confidence how many versions of a customer's data exist across their operational and analytical systems, or which system should be treated as the authoritative source when a data principal exercises access, correction or erasure rights. This visibility gap is where DPDPA implementation becomes most challenging.

Publicly available procurement records and limited disclosures indicate that banks are strengthening data-centric controls rather than relying solely on perimeter security. For example, certain banks have issued formal procurement requests for Data Loss Prevention solutions to monitor and restrict unauthorised internal movement of sensitive customer information. Some banks have publicly acknowledged deployment of specialised platforms for cyber-fraud monitoring and incident response, such as Punjab National Bank's implementation of Clari5's solutions for handling cybercrime complaints and fraud detection. Alongside these developments, industry advisories and banking-sector forums have increasingly emphasised the need for automated data discovery, classification and monitoring tools to address risks arising from legacy systems and outsourced processing.

HOW CUSTOMER RIGHTS TEST EXISTING SYSTEMS

Customer rights under DPDPA i.e. access, correction, erasure and consent withdrawal are simple in principle but demanding in execution. For instance, where a borrower requests deletion of a secondary phone number, the institution is obligated to remove it from the CRM workflows and marketing tools, while continuing to retain essential identifiers required under applicable law. If systems do not distinguish between mandatory and optional purposes, fulfilling such a request can become operationally difficult.

Microfinance, as an industry faces other challenges also. Many microfinance institutions use offline apps for customer onboarding, with data being synced later. The DPDPA places an obligation on all institutions to demonstrate lawful and secure processing, which in practice requires reliable audit trails across such assisted and offline workflows. Without proper logs or consistent metadata, institutions may not be able to demonstrate compliance, even if the underlying processing was legitimate. This creates evidentiary and governance risks that go beyond technical non-compliance.

It is also understood that digital lenders using behavioural signals or device metadata while evaluating loan applications must consider whether such inputs require consent, and how their systems will function if consent is withdrawn. In many cases, redesigning the model may become necessary.

These examples reflect a single reality, which is that the DPDPA exposes architectural gaps that previously appeared to be routine operational practices, but now carry direct compliance risks. Under the DPDPA, failure to comply can attract penalties of up to INR 250 crore, loss of business as well as reputation. As a result, incidents that were earlier addressed through remediation or regulatory correspondence may now trigger parallel enforcement under a statutory penalty regime.

ROLES OF FIDUCIARIES, PROCESSORS & BLIND SPOTS IN THE FINANCIAL ECOSYSTEM

In the financial sector, most entities are almost always the Data Fiduciaries. They design products, define onboarding flows, set eligibility rules, determine KYC mechanisms and decide data retention frameworks. Vendors providing cloud infrastructure, document management, underwriting engines or analytics typically act as Data Processors but remain contractually and operationally tied to the Fiduciary's obligations.

Fintech partners, however, often operate in dual capacities. When collecting data strictly under a bank's instructions, they behave as Processors. For their own value-added services or separate financial products, they may independently qualify as Fiduciaries. DPDPA evaluates this at an activity level, and institutions must map these distinctions clearly to ensure compliance under DPDPA.

Larger banks and systemically important NBFCs are also likely candidates for classification as Significant Data Fiduciaries, which brings additional responsibilities such as mandatory Data Protection Officers, independent audits, periodic impact assessments and enhanced documentation expectations.

THE SECTOR'S MOST COMPLEX CHALLENGE - 'LEGACY DATA'

DPDPA applies to all digital personal data, including historical KYC archives, old loan files, call logs, transaction records, bureau data, and analytics datasets accumulated over years. Some of this information, particularly identity and transaction records, is protected by statutory retention requirements. But much of the data sitting in repositories, data lakes and test environments falls into the category of "business memory" retained because it might be useful, rather than because it is necessary. In many institutions, these legacy datasets were never consciously retained and are simply accumulated as systems evolved and storage became cheaper.

Under DPDPA, retention without justification constitutes a compliance risk. Institutions must therefore transition from broad, open-ended retention to strictly purpose-bound retention. Any data not supported by statutory obligations, contractual necessity or valid customer consent must be evaluated for deletion or robust anonymisation.

This is one of the most operationally challenging parts of implementation. It requires collaboration between legal, compliance, IT, cybersecurity and product teams.

WHAT IN-HOUSE LEGAL TEAMS SHOULD PRIORITISE NOW

In-house legal teams in the financial sector now play a central role in operationalising DPDPA. They must lead on defining fiduciary and processor boundaries, overseeing purpose–retention mapping, revising onboarding notices, updating outsourcing contracts to incorporate DPDPA-grade controls, testing rights requests to identify architectural weaknesses and assessing high-impact models through formal Data Protection Impact Assessments.

Implementation is not a legal exercise alone as it is a collaborative governance effort that must align technology, risk, compliance and data teams.

FROM STATUTE TO STRATEGY

As banking regulation continues to evolve, institutions should expect greater scrutiny including potential statutory penalties, for failures in controlling and governing data flows across systems and third parties. This will require a use-specific approach. Retaining data where the law requires it, limiting processing where discretion exists, and being able to explain those distinctions clearly to both regulators and customers.

Viewed in this light, DPDPA may not always conflict with the existing banking regulations. Instead, it provides a common lens through which data practices can be assessed. Financial institutions that align their operational design with both RBI requirements and DPDPA principles will be better placed to navigate regulatory changes and reduce friction across overlapping regimes.

Footnote

1 Data breach exposes 2.73 lakh bank records: https://economictimes.indiatimes.com/tech/technology/data-breach-exposes-2-73-lakh-bank-records/articleshow/124184985.cms?from=mdr

3.2 million debit cards compromised; SBI, HDFC Bank, ICICI, YES Bank and Axis worst hit: https://economictimes.indiatimes.com/industry/banking/finance/banking/3-2-million-debit-cards-compromised-sbi-hdfc-bank-icici-yes-bank-and-axis-worst-hit/articleshow/54945561.cms?from=mdr

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.