DPDP Compliance for BFSI and NBFCs

Where DPDP and sectoral rules pull against each other

Three tensions come up in every BFSI programme, and none of them resolve by choosing one regulator over the other.

• Retention versus erasure. KYC and transaction records carry statutory retention periods. A data principal's erasure request cannot override a legal retention obligation, but you must be able to explain, per record, which basis applies and for how long.
• Consent versus legal obligation. Much BFSI processing is not consent-based at all. Recording the correct lawful basis matters more here than anywhere else, because treating a legal-obligation activity as consent-based creates a withdrawal right that you then cannot honour.
• Localisation versus vendor sprawl. Existing localisation directions constrain where data may sit; DPDP adds an obligation to know where it has gone. The two need one map, not two.

Where the personal data actually is

BFSI data estates are old, and the risk concentrates in the parts nobody inventoried.

• Core banking or lending systems, plus every reporting replica taken from them.
• KYC and onboarding stores, including scanned documents and video-KYC recordings.
• Collections and recovery systems, which frequently hold contact data on third parties.
• Call-centre recordings and CRM notes — usually the least governed store holding the most sensitive free text.
• DSA, agent and aggregator channels, where personal data is collected by someone else on your behalf.

What to do first

Start with the purpose register rather than with consent screens. Until each processing activity has a stated purpose and a recorded lawful basis, consent UX built on top of it will encode the wrong model and have to be rebuilt.

Then map the agent and aggregator channels. That is where personal data enters without passing your own front door, and it is the part of the estate most often missing from a first inventory.