DPDP for BFSI: The KYC Retention Problem

The request that breaks the onboarding story

A borrower forecloses a personal loan. Two weeks later he writes in: he withdraws consent and wants his data deleted, naming the DPDP Act. Your team does the sensible thing and refuses, because the KYC record has to be kept. Then someone pulls up the onboarding screen and reads what he actually agreed to. The consent checkbox says, in effect, I consent to the collection and processing of my personal data including KYC data for the purposes stated in the privacy policy.

That single sentence is the problem. You have just told the regulator, in writing, that your lawful basis for holding KYC data is his consent. He has withdrawn it. If consent was the basis, the obligation to stop and erase follows, and the fact that another law requires retention is now something you have to argue against your own notice rather than from it.

This is the most common structural defect we find in NBFC and fintech DPDP programmes. It is not a drafting nicety. It determines whether your refusal to delete is a confident statement of law or a defensive improvisation, and it determines which of two regulators you end up explaining yourself to. The rest of this paper is about fixing it and the four related problems that travel with it.

Consent is not your basis for KYC, and your notice should say so

DPDP is a consent-first statute, which has led a great many onboarding flows to put everything under one consent. But the Act also recognises processing that is necessary for compliance with a law in force, and that is what KYC is. You collect and retain identity records because anti-money-laundering law and the KYC direction applicable to your entity require it, not because the customer kindly agreed. If he had refused, you would have declined the relationship, which is itself proof that consent was never the operative basis.

Getting this right changes three things on the ground. The notice separates what is collected because the law compels it from what is collected because he chose to allow it. The consent artefact stops bundling the two. And when a withdrawal arrives, the answer is short: the processing he withdrew consent for has stopped, and the records held under statutory obligation remain for a stated period, which you can name.

The split, element by element, looks like this. Treat the right-hand column as the test: if withdrawal does nothing to an element, consent was never its basis and your notice should not have implied otherwise.

Data element	Operative basis in practice	What withdrawal of consent actually does
Identity and address proof, verification result, CKYC identifier	Compliance with anti-money-laundering law and the applicable KYC direction	Nothing. Retained for the statutory period. Say so plainly and give the expiry basis
Loan account, repayment and transaction records	Statutory record-keeping, books of account, credit information reporting obligations	Nothing while the obligation runs
Bank statement data pulled via an account aggregator for underwriting	Consent, under the AA consent artefact, for the stated purpose and data life	Revocation stops further fetches. The already-underwritten decision record stays; the raw statement feed should not be kept beyond the stated purpose
Device, SMS-header or app-usage signals used in underwriting	Consent, and only within what the digital lending framework permits you to collect at all	Stop collection. Erase the retained signal set unless it forms part of the credit decision record
Marketing consent, cross-sell eligibility flags, look-alike audiences	Consent	Erase and propagate suppression to every channel and partner
Call recordings from collections and service	Mixed: record-keeping expectations and dispute evidence	Quality and training use stops. Retention for the stated period continues; then it is deleted
Data used to train or tune credit, fraud or collections models	Consent, almost always, and almost always not asked for	Remove from the training corpus. Be honest about what a trained model cannot unlearn
Employee and DSA agent records	Employment and contractual purposes, statutory obligations	Little or nothing. These were never consent-based either

Two things you cannot undo, and should stop promising you can. A KYC record submitted to the central KYC records registry is not yours alone to delete, and credit information furnished to credit information companies lives under its own statutory regime. If your notice or your customer-service script implies a borrower can have his credit history erased by writing to you, fix the script this week. It is a promise you will break in public.

What your onboarding consent actually covered

Pull the exact consent text your production flow served nine months ago, not the version in the current policy document. Then read it against what the business is doing today. In most assessments we run, three uses turn out to be unsupported.

• Marketing and cross-sell. Consent taken to process an application does not cover promoting a second product, and burying it in a policy link does not make it specific or informed. Collections communication is a different animal, grounded in the contract, and should be separated from promotional messaging in both your systems and your notice.
• Model training. Underwriting, fraud and collections models are routinely trained on historical borrower data under a consent that spoke only about processing the application. This is the gap that will age worst, because the model outlives the relationship and the training set outlives the model.
• Sharing with group entities and partners. "We may share your data with our affiliates and partners" is not a purpose. Name the categories of recipient and what each does with it, or expect the sharing to be the finding.

The remediation is mechanical but it has to be done properly. Version every notice and consent artefact, store the version identifier against the customer record, and be able to produce, for one named borrower, the exact text he saw and the timestamp. Then build granular consent for the uses that are genuinely optional, with the ability to decline each one without being blocked from the product. Finally, re-consent where a current use is not covered. Re-consent campaigns have poor response rates and the honest consequence is that you stop the uncovered use for non-responders. Teams that plan for that outcome in advance handle it calmly; teams that discover it mid-campaign usually quietly keep processing, which is the worse outcome.

The data flows nobody has papered

Lending and payments businesses distribute their data footprint far more widely than their vendor register suggests. The entities below handle borrower personal data on your behalf or alongside you, and in each case the DPDP processor relationship, the RBI outsourcing expectations and the digital lending restrictions all apply at once.

Counterparty	What they typically hold	The gap we usually find
DSAs, connectors and sourcing agents	Lead data, documents captured on personal devices, local spreadsheets	No deletion trigger, no audit right, no inventory of what they retained after the lead went cold
Lending service providers and app partners	Application data and whatever the app collected	Storing more than the framework permits an LSP to store, and data not flowing through the lender as required
Co-lending partners	Full borrower file for the co-lent portion	Both parties behave as fiduciary; neither agreement says who answers a rights request or who erases what and when
Collections agencies and telecalling vendors	Contact data, call recordings, field-visit notes, often on their own dialler	Suppression flags never propagate; recordings retained on the vendor's schedule, not yours
Payment processors, PA/PGs and card networks	Transaction and instrument data	Their retention is contractual and long; your notice never mentioned it
Cloud, CRM, analytics and communication platforms	Copies of almost everything	Sub-processing and cross-border transfer terms unreviewed; no deletion-on-termination clause
AI and model vendors	Prompts, documents, call transcripts, fine-tuning sets	Not in the vendor register at all, because procurement treated it as a software tool

What to do about it, in the order that reduces risk fastest. First, build a third-party flow register with one row per counterparty and per data flow, recording the elements shared, the purpose, where the data physically sits, whether sub-processing is permitted, what the deletion trigger is, and whether you have an audit or inspection right. Second, prioritise remediation by exposure rather than by contract value: a small telecalling agency with ten thousand borrower numbers on a personal laptop outranks a large cloud contract with mature terms. Third, add the three clauses that are almost always missing — deletion on termination with a confirmation artefact, a flow-down obligation to notify you of a breach within a window that lets you meet your own notification duty, and an express right to inspect or to receive an independent assurance report.

On co-lending specifically: decide and document who is the fiduciary for which elements, and who answers a rights request. The borrower will write to whoever's brand is on the app. If your agreement is silent, you will discover the answer during the request, and so will your partner.

Where RBI expectations and DPDP erasure rights actually collide

The collision is narrower than it is usually described, and naming it narrowly is what lets you act. RBI's record-keeping expectations and the Act's erasure right do not contradict each other on identity and transaction records, because the Act accommodates retention required by law in force. They collide in three real places.

The rejected applicant. You verified identity, ran a bureau pull, and declined. No relationship exists. Some record of the decision and the checks performed is defensible. The full document set, the device signals, the lead record in the CRM and the copy sitting with the DSA are a different matter, and in most stacks they are all still there two years later. This is the single highest-volume erasure exposure in a lending book and the one almost nobody has addressed.

The expired clock. Statutory retention periods end. Very few lenders have a job that deletes KYC and transaction records when they do. If your register says a period and your systems hold data beyond it, the register is not a defence — it is the evidence.

Secondary use dressed as compliance. A record retained for an anti-money-laundering obligation is routinely also feeding analytics, cross-sell models and portfolio dashboards. Retention being lawful does not make every use of the retained record lawful. Ring-fencing has to be technically real: restricted to a named role, excluded from BI, analytics, model training and campaign selection, reads logged, and an automatic expiry date set. If a ring-fenced record still appears in a cross-sell extract, it is merely flagged.

Our working position, and we will tell you it is a position rather than settled law: a narrow, documented, time-bounded retention exception with non-mandated use genuinely stopped is defensible to both the sectoral regulator and the Data Protection Board. A blanket "we keep everything because RBI might ask" is defensible to neither, and it is the posture most lending books are currently in.

The register that answers both regulators

You cannot answer both with two documents, because they will diverge within a quarter. You answer both from one register, read from different ends. The inspection team reads the retention columns. The rights desk reads the basis and withdrawal columns. Same rows.

Build it at the level of the data element, not the system. Systems hold elements with wholly different obligations, so a single retention setting per system is wrong for most of what it contains. The columns that matter for a lending or payments book:

Column	Example value	Which regulator's question it answers
Element ID and name	KYC-DOC-POI / Proof of identity document image	Both
Product and collection point	Personal loan, app onboarding step 2	Both
Operative lawful basis	Compliance with law in force	Board: is consent being relied on where it should not be
Notice version shown	PL-NOTICE-v4.2	Board: prove what the borrower saw
Consent artefact reference	Granular consent record ID, where consent applies	Board
System of record and downstream copies	LOS; plus LMS, warehouse, DSA portal, vendor OCR service	RBI: outsourcing and data localisation. Board: is erasure complete
Retention obligation and named source	Mandatory; AML record-keeping and the applicable KYC direction, read and confirmed by named counsel on a date	RBI: why you hold it. Board: why you refused erasure
Clock-start event and expiry date	End of business relationship; computed date	Both. This is the column that is usually missing
On withdrawal	Ring-fence; stop analytics, model training, cross-sell, quality review	Board
Erasure method	Hard delete; crypto-shred for the WORM archive	Board
Third-party flows	Co-lender X, collections agency Y, bureau reporting	RBI: outsourcing. Board: processor accountability
Element owner and last review date	Named business owner, dated	Both. First thing an auditor checks

A mid-sized NBFC lands between 300 and 700 rows across its products. Do not try to complete it before using it. Cover your highest-volume product and the elements that appear in real customer requests first, then extend. A register covering four collection points in week three is worth more than a perfect one in month nine.

The response your team sends, and the clock on it

Withdrawal is a fan-out, not a single action, and each branch has a different realistic latency. Publish the ones you can hit. The Rules require you to state the period within which you will respond, and you will be held to your own published figure rather than to an industry norm, so pick a number your weakest system can support in your busiest month.

1. Within hours: marketing and cross-sell suppression set and propagated to every channel, dialler and partner audience. This is the branch the borrower can observe. A promotional SMS after withdrawal undoes everything else you did.
2. Within two business days: identity verified. Unverified requests are the main cause of delay, and the main cause of accidental disclosure to the wrong person.
3. Within the published window: a written reply that names which processing has stopped, which elements are retained, the obligation requiring retention, and the date the retention clock expires. Not a template saying the request has been processed.
4. Days to weeks: unmandated elements erased from the system of record and from every downstream copy in the register, including the DSA portal and the vendor copies.
5. On expiry: ring-fenced elements deleted automatically by a monitored job with a named owner.

Keep refusals as structured records rather than prose in a ticket. Each one should name the elements by ID, the instrument relied on, the person who confirmed the reading, the expiry date, the processing that stopped, and the explanation actually sent. You want to answer "show me every erasure you refused this year and the grounds" in one query, because that question is coming from one regulator or the other.

What we are not telling you

There are no section numbers, penalty figures or retention periods stated as fact in this paper, and that is deliberate. Periods differ by entity type, product and licence, and they move. A paper that gets one wrong does more damage to the reader than one that stays general, so every retention row above has to be confirmed against the current instrument by someone who has read it, and that reading has to be recorded with a name and a date.

The DPDP Rules have been notified with a phased commencement, and which obligations are live for your entity on a given date, along with whether you fall into any class attracting additional duties, is a threshold question for your counsel rather than something to infer from a vendor deck. We will tell you where we are inferring rather than citing, and where we think the answer is genuinely unsettled.

We also do not publish invented case studies or success percentages for this work. What we do is read your live consent flow, build the element register and the third-party flow register, restate the basis in your notice, fix suppression propagation, and then run real requests through the process while we are still in the room. If what you need is a legal opinion on a specific retention instrument, that sits with your counsel, and if the problem you have is outside our scope we will tell you on the call.