How Current Tech Stacks Expose BFSI Institutions Under DPDP Act?

ByAnjali Jain

July 10th . 5 min read

How Current Tech Stacks Expose BFSI Institutions Under DPDP Act

The Core Contradiction: Built to Remember, Forced to Forget

For more than a decade, India's BFSI sector including banks, NBFCs, and insurance companies has been engineered around a single guiding principle: collect everything. Every customer interaction, transaction, device signal, and behavioral pattern was captured, copied, and stored indefinitely. The implicit philosophy was that data is an appreciating asset - the more you had, the sharper your risk models and the more personalized your products.

The DPDP (Digital Personal Data Protection) Rules, notified in 2025, fundamentally challenge this logic. Under the new framework, data is no longer an unconditional asset. When the purpose for which it was collected has been fulfilled or when a customer withdraws consent, that data must be erased. Not archived. Not masked. Erased, completely and verifiably.

This is the structural gap that most institutions are not yet equipped to handle. To understand the depth of this shift, it’s important to first look at what the DPDP compliance for BFSI actually requires and why it has such far-reaching implications for BFSI.

What is the DPDP Act and Why It Matters for BFSI Compliance?

The Digital Personal Data Protection Act, 2023 (DPDP Act) is India’s first comprehensive law governing how organizations collect, process, and store personal data.

Financial institutions are among the largest processors of personal data in India. Every onboarding process, loan application, KYC verification, or payment transaction involves sensitive personal information.

Under the DPDP rules, organizations must ensure:

Consent-based data processing
Purpose limitation
Data minimization
User rights management
Accountability and auditability

For BFSI institutions that process millions of customer records daily, compliance requires deep integration across technology systems. The data privacy architecture in India requires a BFSI or any other financial institute to be more considerate about the DPDP act 2023.

From Retention to Responsibility - How DPDP Rules Redefine Data Ownership

The Legacy Mindset: Data as an Infinite Asset

Historically, financial institutions treated data as a long-term asset. Systems were designed to:

Capture every customer interaction
Store data indefinitely for analytics and personalization
Replicate data across departments for seamless access This approach improved business intelligence but ignored lifecycle control.

The DPDP Shift: Data as a Controlled Liability

Under DPDP, data must now:

Be collected for a specific purpose
Be stored only as long as necessary
Be deleted completely upon request This transforms data from an asset into a regulated responsibility.

Why is the Existing Tech Stack Structurally Incompatible with DPDP Rules?

The Replication Problem

In traditional core banking architecture, when a customer updates their address or identity credentials, that change is automatically propagated to dozens of internal systems - loan management, CRM, marketing automation, fraud analytics, and more. This design served a valid purpose: consistency across a fragmented enterprise.

However, the same redundancy that ensures seamless customer experience now makes the Right to Erasure implementation almost impossible to fulfil. When a Data Principal (the customer) requests deletion of their data, the Data Fiduciary (the institution) is legally required to remove that information from every system it has ever touched - not just the primary database. In legacy architectures, mapping that trail is rarely feasible.

The Ghost Data Problem

'Ghost Data' refers to personal information that resides in locations that are rarely monitored or governed. Examples in a typical financial institution include:

Analytics partitions in cloud data warehouses (e.g., Snowflake, BigQuery) used for credit modelling
Log files stored in object storage buckets (e.g., Amazon S3) for debugging purposes
Internal messaging threads where customer data was shared during issue resolution
Backup tapes or cold storage repositories with no automated purge schedule

The problem is architectural. Modern microservices move data faster than governance frameworks can track it. At a certain scale, the 'search and destroy' approach to deletion stops being a compliance strategy and becomes an unwinnable exercise.

The Selective Suppression Problem

Even when an institution can locate data, most core banking platforms cannot act on it selectively. These systems store customer information in large, undifferentiated databases with no segmentation by purpose or consent category, and they lack the APIs required to execute targeted, automated deletion workflows.

The practical consequence is immediate: a customer withdraws consent for marketing but remains an active loan account holder. The system must suppress that individual's data from the marketing engine while keeping it fully accessible to the loan management engine. In a monolithic architecture, this requires manual intervention every single time. That is neither auditable nor sustainable.

The AI Training Problem

The most consequential gap is one still emerging across the sector- training AI models on raw customer data. Unlike a database record, a trained model cannot have one person's contribution surgically removed. Once personal identifiers are used in training, that information is distributed across millions of model parameters. Retraining the entire model from scratch is the only way to remove it, and that is prohibitively expensive.

This makes training on raw personal data a one-way door. Any institution that has done so is in a state of structural non-compliance at the moment any of those individuals exercises their Right to Erasure - not as a future theoretical risk, but as an immediate operational liability sitting in production today.

The Only Sustainable Fix for DPDP Compliance: What Leading BFSI Institutions Are Doing?

Once it becomes clear that the 'search and destroy' approach to data deletion is unscalable, a more fundamental rethink is required. The answer is not to improve the deletion process. It is to eliminate the conditions that make deletion difficult in the first place.

1. Shifting from Copy-Based to Reference-Based Architecture

In a copy-based architecture, raw personal identifiers - Aadhaar numbers, email addresses, mobile numbers - travel freely across every system that needs them. In a reference-based architecture, these identifiers never leave the central vault. Instead, downstream systems receive tokens: format-preserving, function-preserving references that carry no personal information on their own.

When a customer exercises their Right to Erasure, the institution deletes the record from the central Data Privacy Vault. Every token across every downstream system immediately becomes meaningless. The organization achieves complete, provable erasure through a single action.

2. Cryptographic Safeguards and Key Management

For institutions processing sensitive identity and financial data, 'reasonable security safeguards' under the Act translates to a formal cryptographic governance framework, including:

Hardware Security Modules (HSMs): Tamper-resistant hardware devices that generate and protect cryptographic keys
Hierarchical Key Management: Separation of Root, Master, and Operational keys with enforced rotation schedules
End-to-End Encryption: Protection for data at rest, in transit, and in active use across all processing environments

3. Privacy-Safe AI Development

A Data Privacy Vault also provides a path to compliant AI development. By training models on tokenized data rather than raw identifiers, institutions retain the statistical utility required for credit modelling and personalization while ensuring that no personal data is directly embedded in model weights.

When a user requests to erasure, their vault record is removed, and the model can no longer reference that individual's identity. This resolves what would otherwise be a permanent compliance of liability.

A Practical 90-Day DPDP Compliance Roadmap

Full architectural transformation takes time (typically 12 to 18 months) for large institutions. However, the first 90 days are critical for establishing a documented understanding of the data environment and demonstrating good-faith efforts to the regulator.

Phase 1: Discovery (Days 1–30)

The objective of this phase is to build an accurate, organization-wide data inventory.

Scan all systems - core banking, CRM, cloud platforms, and offline repositories - to identify where personal data currently resides
Map data flows: visualize how personal data moves between internal systems and third-party processors
Conduct a gap assessment comparing current practices against DPDP obligations, with focus on consent architecture, data minimization, and security controls

Phase 2: Governance (Days 31–60)

The objective of this phase is to establish the legal and operational framework for compliance.

Update Privacy Policy, Consent Management Policy, and Data Retention and Erasure Policy
Revise customer-facing consent notices to be standalone, specific, and written in plain language
Identify all third-party vendors processing personal data and initiate DPDP-aligned Data Processing Agreement negotiations

Phase 3: Operationalization (Days 61–90)

The objective of this phase is to reduce immediate risk exposure and prepare for early Rights requests.

Implement Multi-Factor Authentication on critical systems and begin encrypting sensitive data at rest
Establish documented workflows and response templates for handling Access, Correction, and Erasure requests
Draft a 72-hour breach notification protocol and run a tabletop exercise with the cross-functional compliance task force

If you are using a legacy system, you can easily opt for Cloud modernization for compliance as it will help you with the modern infrastructure required to simplify the implementation of DPDP act.

Conclusion: From Compliance Burden to Competitive Advantage

The DPDP Act represents a structural shift in how personal data is governed in India. For the first time, individuals have enforceable rights over their financial data. This shift is irreversible, and institutions that recognize it early will be far better positioned than those waiting for enforcement to force action.

Those that move first toward privacy-by-design architectures will do more than avoid penalties- they will establish something increasingly rare in the digital economy: genuine trust in how they handle personal data.

At HabileLabs, we work with BFSI institutions to design, modernize, and secure cloud and data architectures aligned with DPDP requirements—helping them move from fragmented legacy systems to privacy-first, scalable platforms.

With that said, for BFSI leadership, the question is no longer “how much data can we collect?” but “how responsibly can we use it and how confidently can we delete it on demand?” Answering this well is now both a regulatory requirement and a competitive advantage.

Frequently Asked Questions

How do legacy tech stacks expose BFSI institutions to DPDP Act violations?

Legacy core banking systems, monolithic architectures, and siloed databases were built before modern data privacy frameworks existed. They often lack built-in consent management, granular access controls, and data lifecycle enforcement — making it structurally difficult to honour data principal rights (access, correction, erasure) mandated by the DPDP Act. Retrofitting these systems is costly, and gaps in consent logging or data-flow visibility can directly result in regulatory penalties of up to ₹250 crore.

What specific DPDP Act obligations apply to BFSI data fiduciaries?

BFSI organisations processing personal data must: obtain explicit, purpose-specific consent before using data for marketing, analytics, or cross-selling; respond to Data Subject Access Requests (DSARs) within 30 days; notify the Data Protection Board of breaches within 72 hours; appoint a Data Protection Officer (DPO) if classified as a Significant Data Fiduciary (SDF); and conduct annual Data Protection Impact Assessments (DPIAs). Large banks, insurers, and payment aggregators are likely to be designated SDFs.

Which tech stack components most commonly create DPDP compliance gaps in BFSI?

The highest-risk components include: third-party analytics and marketing SDKs that capture user data without granular consent, API gateways lacking purpose-limitation enforcement, cloud storage buckets without data residency controls, AI/ML pipelines for credit scoring that process sensitive PII without DPIAs, and core banking systems that don't support real-time data erasure. Unmanaged vendor integrations for UPI, Account Aggregator data, and KYC services also create shadow data flows that are difficult to audit.

Does the DPDP Act conflict with existing RBI, SEBI, and IRDAI data regulations?

Not in conflict, but overlapping. The DPDP Act serves as an overarching privacy framework while RBI, SEBI, and IRDAI provide sector-specific rules. For example, RBI's KYC and AML mandates use a 'legitimate use' basis (no fresh consent needed), while DPDP adds a consent dimension for any non-mandatory data use like marketing. BFSI firms must maintain dual compliance aligning DPDP obligations with existing sectoral frameworks and their tech stacks must be capable of segregating data processing bases.

What penalties can BFSI firms face for DPDP non-compliance?

The Data Protection Board can impose penalties of up to ₹250 crore per violation. Enforcement has already begun at the sectoral level: the RBI levied ₹56 crore in fines across 304 compliance cases in 2024, many tied to data protection and cybersecurity lapses. Beyond financial penalties, non-compliance risks reputational damage, loss of customer trust, and mandatory corrective action including technology audits or system changes directed by regulators.

How does data localisation under the DPDP Act affect BFSI cloud architectures?

The DPDP Act, combined with RBI payment system data rules, requires that sensitive personal and payment data be stored within India. BFSI firms using global cloud providers (AWS, Azure, GCP) must ensure data residency configurations are enforced at the storage layer, not just the application layer. Multi-cloud or hybrid architectures need geo-fencing controls, and cross-border data transfer to processors outside India requires explicit consent or contractual safeguards both of which must be embedded in the tech stack.

How should BFSI firms handle consent management technically under the DPDP Act?

Consent must be specific, informed, and easily withdrawable. Technically, this requires deploying a Consent Management Platform (CMP) that: captures itemised, purpose-specific consent at onboarding; maintains audit-ready logs for each consent action; propagates consent signals in real time to downstream systems (CRM, analytics, marketing automation); and supports withdrawal workflows that halt processing within reasonable timeframes. The DPDP Act prohibits bundling consent for data sharing with third-party recovery agents or analytics vendors unless explicitly stated.

What is a Significant Data Fiduciary (SDF) and how does it affect BFSI tech requirements?

An SDF is an organisation that processes large volumes of sensitive personal data or data that carries high risk to individuals' rights. Large banks, insurance companies, payment aggregators, and leading fintechs are expected to be designated SDFs. SDFs face additional obligations beyond standard compliance: appointing an India-based DPO, conducting annual DPIAs, undergoing independent data audits, implementing AI governance mechanisms, and maintaining strict processing logs. This classification demands a more robust and auditable tech infrastructure.

How does AI and machine learning usage in BFSI (credit scoring, fraud detection) create DPDP risk?

AI-driven models used for credit scoring, fraud analytics, customer profiling, and robo-advisory services process sensitive PII at scale and automate consequential decisions. Under the DPDP Act, these use cases require DPIAs before deployment, data minimisation in model training pipelines, and for SEBI-regulated wealth management data principal rights to explanation for automated decisions. AI pipelines that ingest composite financial data (Account Aggregator, UPI, GST) without clear purpose limitation are among the highest-risk components in BFSI tech stacks.

What steps should BFSI firms take now to reduce DPDP-related tech stack exposure?

Start with six foundational actions: (1) Conduct a DPDP gap assessment and data-flow mapping across all systems; (2) Identify and categorise all personal data processed, including third-party processor data; (3) Deploy or upgrade a consent management platform; (4) Implement 72-hour breach notification workflows integrated with RBI incident reporting; (5) Establish data lifecycle policies with enforced retention, erasure, and archival automation; and (6) Engage third-party data processors under updated Data Processing Agreements (DPAs) aligned with DPDP obligations. Shift from annual audits to continuous compliance monitoring.