DPDP for banks, NBFCs and lenders

Lending is identity, money and judgement about a person. To open an account or give a loan you collect KYC documents, income proofs, bank statements, bureau reports, employer details, property papers and, more and more, data pulled from apps and Account Aggregators. You then share it with credit bureaus, CKYC, co-lenders, insurers, collection agencies and regulators. Few sectors hold as much about a person, for as long, or pass it to as many hands.

The risk sits at the edges: the DSA with a WhatsApp group of customer PAN cards, the recovery agent who calls a borrower’s relatives, the cross-sell team that treats a loan file as a marketing list, and the branch cupboard of paper forms nobody has erased. This guide applies the Data Fiduciary playbook to banks and lenders.

Are you a Data Fiduciary, a processor, or both?

• Bank or NBFC lending in its own name: you are the Data Fiduciary for applicants, borrowers, depositors, guarantors, co-applicants and nominees. Your core banking vendor, cloud host, KYC and video KYC vendors, SMS and WhatsApp providers, call centres and document storage firms are your Data Processors.
• Co-lending: two regulated lenders who each decide how they use the borrower’s data are usually joint or separate fiduciaries. Write down who gives the notice, collects consent and answers rights requests.
• Digital lending with a loan service provider (LSP): the regulated entity (the bank or NBFC) is the Data Fiduciary for the loan. The LSP or app is usually its processor for onboarding and servicing. If the LSP also uses borrower data for its own purposes (its own marketing, other lenders, analytics products), it is a separate fiduciary for those uses and needs its own ground. See fintech and payments.
• DSAs and DSTs: normally your processors, collecting data on your behalf under a valid contract (section 8(2)). A DSA that keeps a customer’s documents to pitch other lenders is acting as a fiduciary without a ground.
• Recovery agencies: your processors. You stay responsible for what they do (section 8(1)).
• Credit bureaus, CKYC registry and Account Aggregators: these are separate entities. When you report to a bureau or upload to CKYC you are disclosing to another fiduciary. When you pull a report you become a fiduciary for that copy.
• When you act as a processor: a bank servicing loans for another lender, a cooperative bank sponsor running systems for smaller banks, or an NBFC collecting EMIs for a partner acts on someone else’s instructions for that work.

The data you hold

Data category	Where it usually lives	Typical purpose	Sensitivity	Typical retention
Identity and address (name, photo, PAN, masked Aadhaar, passport, voter ID)	Core banking, CKYC, KYC vendor, branch files	KYC, account opening	High	Law sets the minimum. The Act’s illustration: 10 years after account closure for bank identity records
Video KYC recordings, liveness checks, geotags	V-CIP vendor, storage	Customer identification	High (face, voice, location)	As the KYC rules require; restrict access
Account and transaction data	Core banking, data warehouse, payment switches	Running the account, statements, monitoring	High	As banking and PMLA rules require
Income proofs, salary slips, ITRs, Form 16, bank statements	Loan origination system, DSA uploads, email	Credit assessment	High	Loan life plus the period the law or your policy requires
Account Aggregator data (statements, GST, investments)	FIU systems, underwriting engine	Credit assessment, monitoring	High	Only as long as the consent artefact allows
Bureau reports and scores	Loan origination system, risk data mart	Credit decision, portfolio monitoring	High	Per CICRA and your credit policy
Property papers, valuation and legal reports	Branch, panel advocates, valuers, document vault	Mortgage, HFC loans	High (reveals home and family)	Loan life and until the security is released
Employer, references, co-applicants, guarantors	Loan file, CRM	Assessment, contact, recovery	Medium to high (third-party data)	Loan life
Microfinance group data (JLG members, household income, photos)	Field app, branch	Group lending, collections	High (low-income, often women borrowers)	Loan life plus legal minimums
Collection notes, call recordings, field visit photos	Collection system, agency apps, telephony vendor	Recovery	High	Until the dues close or a dispute ends
Nominee and legal heir details	Core banking, deposit forms	Nomination, claims settlement	Medium	While the account runs and the claim settles
Device, location and app permission data	Mobile app, fraud SDK, analytics	Fraud, security, analytics	Medium to high	Set short limits
Marketing and cross-sell lists	CRM, campaign tools, partner insurers and AMCs	Cross-sell	Medium	Until consent is withdrawn
Minors’ accounts and guardians	Core banking	Savings, education accounts	High	See section 9

Risk hotspots

1. Video KYC and app onboarding. The Act’s own illustration under section 5 is a bank doing live video KYC through its app: the notice must accompany or precede the request and describe the data and purpose. Failure: the V-CIP screen starts recording before any notice, or the vendor keeps recordings for its own model training. Control: a notice screen before the call starts, itemising face, voice, documents and location; vendor contracts that forbid any reuse; recordings stored with you, encrypted and access-logged.
2. Aadhaar copies everywhere. Branch files, DSA phones and inboxes fill up with full Aadhaar copies. Failure: one leaked folder exposes thousands of people. Control: offline e-KYC, DigiLocker or masked Aadhaar wherever the KYC rules allow; redact the number at intake; never store Aadhaar images in the loan origination system unless a rule requires it.
3. DSAs and loan service providers. Sourcing partners collect documents on personal phones, share them on WhatsApp and keep them to pitch other lenders. Failure: processing by your processors outside your instructions, for which you are still responsible (section 8(1)). Control: collection only through your app or portal, no local storage, DPDP clauses in every DSA and LSP agreement, periodic audits and termination for misuse.
4. Recovery agents and the defaulter exemption. Section 17(1)(f) lets a financial institution process a defaulter’s data to ascertain her financial information, assets and liabilities. It does not authorise shaming, calling her employer, or messaging her contacts. Sections 8(1) and 8(5) still apply under any exemption. Failure: agents use contact lists and social media to pressure borrowers. Control: agents see only the borrower’s and named guarantors’ contacts, calls are recorded and reviewed, and contracts and scripts follow RBI’s recovery conduct rules.
5. Cross-selling insurance and investments. A loan file turns into a lead list for life cover or mutual funds. Failure: bundled consent (“offers from group companies”) and insurance forced with loans. Control: separate unticked consent per product line and partner, never a condition of the loan, with partners named in the notice.
6. Account Aggregator and bureau data reuse. Data fetched for one credit decision gets copied into a warehouse and reused for marketing or model training. Failure: processing beyond the purpose and duration in the consent artefact. Control: tag AA and bureau data at ingestion with purpose and expiry, purge on expiry, and do not let marketing touch it.
7. Branch paper and scanned files. The Act applies to data collected on paper and digitised later (section 3(a)(ii)). Failure: scanned account and loan forms on a branch PC with no access control. Control: scan only into a controlled document system, lock physical files, and review retention for both.
8. Bureau accuracy and disputed data. Section 8(3) requires completeness, accuracy and consistency where data is used to make a decision or disclosed to another fiduciary. Bureau reporting is both. Failure: a wrong DPD entry that blocks a person’s next loan. Control: data quality checks before each bureau submission, a fast dispute path, and corrections pushed to every bureau you reported to.
9. Insider access and data warehouses. Staff and analysts can see balances and statements across the book. Control: role-based access, masking of account numbers and PAN in non-production systems, access logs kept for at least one year (rule 6(1)(e)), and alerts for bulk exports.
10. Dormant account takeover. SIM swaps and insider-assisted takeovers are breaches if personal data is exposed or altered. Control: step-up checks on contact changes, cooling periods, and the breach run-book.

Legal basis, purpose by purpose

Purpose	Basis	Notes
Account opening and KYC, including video KYC	Consent, or 7(a) where the customer voluntarily applies for the account	Section 5 illustration: give the notice before or with the KYC request. Collect only what the KYC rules require.
CKYC upload and download	7(a), backed by the KYC rules that require it	Name CKYC in the notice. Retention is required by law. Confirm the current requirement with counsel.
Running the account, payments, statements, service alerts	7(a)	Transactional only; no promotions in the same message without consent.
Credit assessment for a loan the customer applied for	7(a), or consent for data beyond what the customer supplied	Pulling a bureau report or AA data needs the customer’s specific authorisation under those regimes as well.
Reporting to credit bureaus	7(a) for the loan relationship, with the duty to report under CICRA	Tell the borrower in the notice. Accuracy duty under section 8(3). Confirm the current requirement with counsel.
AML and transaction monitoring, reports to FIU-IND	7(d) for disclosures to the State; 17(1)(c) for prevention and detection of offences	Section 11(2) limits what you disclose about sharing on a written request from an authority.
Fraud prevention and investigation	17(1)(c)	Document the use; do not reuse fraud signals for marketing.
Recovery from a defaulting borrower	17(1)(f) for ascertaining financial information, assets and liabilities; 17(1)(a) for enforcing a legal claim	Sections 8(1) and 8(5) still apply. Disclosure must follow other laws, such as RBI rules on recovery.
Retaining KYC and transaction records after closure	Retention required by law (section 8(7))	Section 8(7) illustration: 10 years after account closure for bank identity records. Stop all other use.
Responding to tax, court and regulator orders	7(d), 7(e)	Keep a log of each disclosure. 17(1)(b) covers the court or regulator’s own processing, not yours.
Cross-selling insurance, mutual funds, cards	Consent, per product line and partner	Never a condition of the loan or account.
Promotional SMS, WhatsApp, calls and email	Consent, per channel	Also follow TRAI’s TCCCPR.
Sharing data with co-lenders and insurers for credit-linked cover	Consent, or 7(a) where the customer asked for that product	Name the partner. Access rights include who you shared with (section 11(1)(b)).
Employee data (branch staff, relationship managers)	7(i)	See employers and HR.

Notices and consent: getting the screens right

Channel	Do	Don’t
Branch or counter	Give a one-page notice with the account form, in the customer’s language, with separate tick boxes for each optional purpose. Record the choice in the system the same day.	Put marketing consent inside the account opening declaration the customer signs.
Mobile app and internet banking	Show the notice before KYC starts; ask for OS permissions only when a feature needs them; put a “Privacy and consent” section in settings with one-tap withdrawal.	Ask for contacts, SMS or call logs at install.
Video KYC	Show a notice screen before the camera opens: what is recorded, why, who sees it, how long it is kept.	Start recording before the customer has seen the notice.
DSAs and field agents	Use your own app or link so the customer sees your notice and gives consent on their own phone.	Let the DSA collect documents on WhatsApp or keep copies.
Call centre and telesales	Read a short notice before recording; confirm the customer’s consent to any product pitch; record the choice.	Call people from purchased or inherited lists.
WhatsApp banking and SMS	Record the opt-in source and time; separate service messages from promotions; put “STOP” in every promotion.	Treat a service opt-in as consent to offers.
Paper loan forms and microfinance groups	Read the notice aloud in the local language at the group meeting, give a printed copy, and record each member’s choice individually.	Take one signature from the group leader for everyone.
Existing customers	Send a section 5(2) notice through the app, email or SMS link, with a page to review and change choices.	Assume decades-old account opening forms cover new purposes.

Every notice must stand on its own, itemise the data and the purposes, and give the link and other means to withdraw consent, exercise rights and complain to the Board (rule 3). Customers must be able to read it in English or any of the 22 Eighth Schedule languages (section 5(3)). For a bank with branches across states, this means translating first into the languages of every state you operate in, with all 22 available. Remember the section 6(2) principle: any clause in a form that waives a customer’s DPDP rights is invalid.

Other laws you must line up with

• RBI Master Direction on KYC and the PMLA 2002: these set what identity data you must collect, verify, keep and report. They override erasure requests for KYC and transaction records, but only for those records and only for the required period. Confirm the current requirement with counsel.
• Aadhaar Act 2016: limits who may do Aadhaar authentication and how Aadhaar numbers are stored. Use masked Aadhaar, offline verification or DigiLocker where the KYC rules allow, and keep any Aadhaar data in a vault.
• CICRA 2005 and the credit bureau rules: credit institutions must report to bureaus and correct disputed data. This overlaps with the DPDP accuracy duty and correction right.
• RBI digital lending rules: these restrict what lending apps may access on a phone, require disclosure of LSPs and lenders, and put data storage and sharing duties on the regulated entity. Read them alongside the DPDP consent rules. Confirm the current requirement with counsel.
• RBI Account Aggregator framework: AAs move financial data between FIPs and FIUs under a consent artefact. This is a parallel consent system you must honour in addition to DPDP.
• RBI rules on recovery agents and fair practices codes: these set conduct rules for collection, including limits on contacting third parties. They fit the conditions in section 17(1)(f).
• RBI storage of payment system data: payment data must be stored in India. Section 16(2) keeps this stricter rule in force even where DPDP would allow a transfer.
• RBI IT governance, outsourcing and cyber security directions, and RBI incident reporting: incident reporting to RBI runs on a separate, short clock alongside the DPDP 72 hours. Confirm the current requirement with counsel.
• IT Act 2000 and CERT-In Directions 2022: cyber incidents must be reported to CERT-In within short timelines and logs kept in India. Confirm the current requirement with counsel.
• Banking Regulation Act 1949, the bankers’ duty of confidentiality, and state cooperative societies Acts: confidentiality duties continue alongside DPDP.
• RBI Integrated Ombudsman Scheme: a parallel grievance route; link it to your DPDP grievance process but keep them distinct.
• SARFAESI Act and the IBC: enforcement and insolvency processes disclose borrower data; your side usually rests on 17(1)(a), 17(1)(f) or 7(e).
• TRAI TCCCPR, the Income-tax Act and GST: consent rules for commercial calls and SMS, and record-keeping that overrides erasure for those records only.

Retention and erasure

1. Section 8(7): erase personal data when consent is withdrawn or the purpose is no longer served, whichever is earlier, unless a law requires you to keep it. The Act’s own illustration is a bank: when a customer closes her savings account, the bank keeps her identity records for the ten years the law requires. Keep the KYC record; erase the marketing profile, the app analytics and the cross-sell flags.
2. Rule 8(3) minimum: keep personal data, associated traffic data and processing logs for at least one year from the date of processing, then erase them unless another law needs longer. Banking records almost always need longer; your logs and app data often do not.
3. Legal holds: a loan under recovery, a SARFAESI action, a fraud investigation, a court case or a regulator inquiry puts a hold on the relevant file. Record the hold, the reason and the review date, and lift it when the matter closes.
4. Rejected applications: applicants who never became customers are a common blind spot. Erase their documents, bureau reports and AA data once the purpose is over and any rule-based retention ends.
5. Account Aggregator data: erase data fetched through an AA when the consent artefact’s data life expires, even if the loan continues.
6. The Third Schedule three-year rule does not list banks or NBFCs. Your retention is driven by section 8(7) and sector law.
7. Processors and partners: make DSAs, LSPs, recovery agencies, KYC vendors, call centres and document storage firms erase data you gave them, and get written confirmation (section 8(7)(b)).
8. Backups and archives: document backup retention, protect archives with the same access controls, and make sure restores replay erasures. Paper archives need a destruction log too.

Rights requests and grievances

• Channels: the app, internet banking, a web form, branches, the phone banking line and an email address. Publish them with the identifier you need (rule 14(1)). Rule 14(5) expressly lists a customer identification file number, an application reference number and a mobile number as identifiers, so a CIF or loan account number works well.
• Identity: verify through internet banking login, an OTP to the registered mobile, or at the branch against KYC you already hold. Do not ask for new documents you do not already hold.
• Access (section 11): give a summary of the personal data you process and what you do with it, and list the fiduciaries and processors you shared it with: bureaus, CKYC, co-lenders, insurers, collection agencies, DSAs. Section 11(2) means you need not list sharing with an authority that asked in writing for the prevention, detection or investigation of offences.
• Correction (section 12): update addresses and contact details through the KYC update process. For bureau data, correct your records and push the correction to every bureau you reported to.
• Erasure (section 12(3)): refuse only what you must keep for the specified purpose (a running loan) or by law (KYC, PMLA, tax). Erase the rest, and tell the customer what you kept and why.
• Grievances: acknowledge quickly, and publish a resolution period inside the 90-day ceiling in rule 14(3); 15–30 days is good practice. Every reply must name your DPO or contact person (rule 9). A customer must use your grievance process before going to the Board (section 13(3)).
• Nomination (section 14): this is separate from the nomination for deposits, lockers and claims under banking law. Offer DPDP nomination as its own option so a nominee can exercise rights on the customer’s death or incapacity.
• Children and guardians: the parent or guardian acts for a minor; for persons with disability, check guardianship under rule 11.

Breach readiness

Likely scenarios:

• a DSA or LSP leaking a folder of KYC documents and bank statements
• a misconfigured storage bucket of loan files or video KYC recordings
• a call centre insider selling account and balance data
• a recovery agency’s app exposing borrower contacts
• ransomware on a cooperative bank’s outsourced core banking

Run-book:

1. Contain within hours: revoke credentials and API keys, suspend the partner’s access, take exposed storage offline, and preserve logs.
2. Assess: which data, how many people, and which consequences: identity fraud, account takeover, loan fraud, phishing, physical risk where addresses are exposed.
3. Notify affected customers without delay through the app, SMS or registered email, covering every point in rule 7(1): what happened, when and how far it went, the consequences for them, what you are doing, what they should do (block cards, watch for fake bank calls, never share OTPs), and a contact person.
4. Notify the Board without delay with a description of the breach, then send the detailed report within 72 hours (rule 7(2)): updated facts, causes, mitigation, findings about who caused it, remedial steps, and a report on the notices sent to customers.
5. Report to CERT-In and RBI under their directions, on their own clocks. Inform bureaus, NPCI or card networks if their data or systems are involved.
6. Learn: fix the root cause and update partner contracts.

The checklist

Phase 1: discover (days 0–30)

• [Leadership] Name the DPO or accountable DPDP owner, reporting to the board, and set up a working group across retail, credit, operations, IT, risk, compliance and collections.
• [DPO] Map every collection point: branch forms, app, internet banking, video KYC, DSAs, LSPs, call centre, WhatsApp banking, microfinance group meetings.
• [Eng] Inventory every system holding customer data: core banking, loan origination, CRM, data warehouse, collection system, document management, email archives, backups.
• [Ops] List all processors and partners: KYC and V-CIP vendors, DSAs, LSPs, recovery agencies, call centres, cloud, SMS and WhatsApp providers, valuers and panel advocates.
• [Legal] List all fiduciaries you share with: bureaus, CKYC, co-lenders, insurers, AMCs, AAs.
• [Compliance] Write down every legal retention requirement (KYC, PMLA, tax, bureau, banking) by record type, with the source.
• [Branch] Count paper and scanned files at branches and archives, and who can open them.
• [Credit] Trace where AA and bureau data goes after the credit decision.
• [Ops] Find every place full Aadhaar numbers or images are stored.
• [Leadership] Assess the likelihood of SDF status and budget for a DPIA and annual audit.

Phase 2: design and build (days 31–90)

• [Legal] Assign a legal basis to each purpose using the table above, and stop purposes without one.
• [Legal] Write itemised notices for account opening, video KYC, each loan product, the app, call recording and cross-sell.
• [Product] Translate the notices into the languages of every state you operate in, and make all 22 Eighth Schedule languages available.
• [Product] Put the notice screen before the video KYC camera opens.
• [Product] Split account opening and loan forms: required declarations on one side, optional purposes as separate unticked boxes.
• [Product] Remove contacts, SMS and call log permissions from lending apps unless a specific feature needs them and the rules allow it.
• [Eng] Move to offline e-KYC, DigiLocker or masked Aadhaar where the KYC rules allow; redact Aadhaar numbers at intake.
• [Eng] Tag AA and bureau data with purpose and expiry at ingestion and purge it on expiry.
• [Eng] Check consent before every cross-sell campaign, partner share and promotional message.
• [Eng] Feed withdrawals in real time to CRM, campaign tools, call centre dialers and partner feeds.
• [Credit] Run data quality checks before each bureau submission and build a dispute workflow that corrects every bureau.
• [Legal] Add DPDP clauses to DSA, LSP, recovery, KYC, call centre and cloud contracts: purpose limits, security, breach notice to you, erasure on instruction, one-year logs, sub-processors, audit.
• [Collections] Restrict recovery agents to borrower and named guarantor contacts, record all calls, and update scripts to RBI conduct rules.
• [Collections] Write the 17(1)(f) procedure: what data may be processed for defaulters, by whom, and what may be disclosed.
• [Marketing] Rebuild cross-sell journeys with separate consent per product line and partner; remove insurance tie-ins from loan approval.
• [Ops] Move DSA document collection to your own app or portal and ban WhatsApp transfers.
• [Security] Mask PAN, account numbers and Aadhaar in non-production systems and analytics.
• [Security] Add MFA and IP restrictions to admin, partner and agency portals; alert on bulk exports.
• [Eng] Keep access and processing logs for at least one year, and longer where RBI or CERT-In rules say so.
• [Eng] Build retention jobs per record type, including rejected applications, closed accounts and expired AA data, with legal holds.
• [Branch] Set up a locked store and a destruction log for paper forms; scan only into the controlled document system.
• [Product] Publish the privacy page: DPO or contact person, rights channels, identifiers (CIF or loan account number), grievance timeline.
• [CX] Set up the rights and grievance workflow with verification, owners and deadlines, linked to the banking grievance desk.
• [Product] Offer DPDP nomination separately from deposit and locker nomination.
• [Product] For minors’ accounts, record verifiable consent from the parent or guardian and switch off targeted offers to the child.
• [Product] Send the section 5(2) notice to existing customers with a link to review and change choices.
• [Security] Write the breach run-book covering the Board, CERT-In and RBI, with named decision-makers.

Phase 3: operate (ongoing)

• [DPO] Review new products, partners, apps and campaigns before launch.
• [Compliance] Audit a sample of DSAs, LSPs and recovery agencies every quarter for data handling.
• [Collections] Review a sample of recovery call recordings every month for third-party contact and harassment.
• [Credit] Track bureau disputes and correction times every month.
• [Security] Run a penetration test every year on the app, internet banking, APIs and partner portals.
• [Security] Run a breach drill every year (for example, a DSA folder leak) against the 72-hour clock.
• [CX] Review rights and grievance timelines every month and investigate overdue cases.
• [Branch] Check paper file storage and destruction logs at a sample of branches every quarter.
• [Legal] Review partner contracts and renewal dates every quarter.
• [DPO] Keep evidence: notices, consent records, withdrawal handling, erasure confirmations, training records.
• [DPO] If notified as an SDF, run the DPIA and audit every 12 months and send the report of significant observations to the Board (rule 13).
• [HR] Train branch staff, relationship managers, call centre staff and agents every year, with tests.

Where myconsentapp comes in

You need to	With myconsentapp	You still own
Ask consent per purpose for cross-sell, partner sharing and marketing	Define purposes (insurance offers, mutual fund offers, WhatsApp promotions, partner sharing) once, each tagged consent or legitimate use. The hosted consent page, widget or SDKs show each as a separate toggle, off by default.	Deciding which purposes need consent and where they appear in your journey.
Prove notice and consent (section 6(10))	Every choice is signed and hash-chained against the exact notice version, with a receipt for the customer and an evidence pack for you.	Keeping the KYC and loan records themselves.
Record consent taken at the branch, by phone or by a DSA	Record consent captured elsewhere with its source, marked as not verified by the customer.	Collecting the paper form or call recording.
Check consent before every campaign or partner share	Call the verify API; it returns not permitted immediately after a withdrawal.	Wiring it into your CRM, dialer and campaign tools.
Make DSAs, LSPs and agencies stop too	The processor registry links each partner to purposes and data items, flags contract expiry, and sends signed webhooks. Partners confirm withdrawals and erasures; erasure stays open until they do.	Signing and enforcing the contracts.
Show what you keep by law	Retention obligations (legal holds) such as KYC records are shown in the notice, and the retention job ends access per purpose when its period ends.	Deleting rows in core banking and loan systems.
Offer notices across states	Notices in English and all 22 Eighth Schedule languages, with machine-translation drafts flagged for review.	Reviewing the translations.
Handle access, correction, erasure and grievances	A rights inbox with SLA timers; erasure closes with a structured proof; nomination and nominee claims are built in.	The answers and the core system changes.
Handle minors’ and guardians’ accounts	An age gate, guardian verification through DigiLocker, and lawful-guardian links for persons with disability, with operator review.	Your account-opening rules for minors.
Manage a breach	A breach register with the 72-hour clock, Rule 7 notices to affected customers, and Board intimation and report documents.	Detection, investigation, and CERT-In and RBI reporting.

myconsentapp is a proposed Consent Manager. It records and proves consent; it does not move financial data between FIPs and FIUs the way an Account Aggregator does, it does not integrate with core banking out of the box (you connect it through the API and webhooks), and it does not include data discovery, a security programme, a DPIA workflow (only a template) or legal advice.

Common mistakes

• Treating the account opening declaration as consent for insurance and investment offers.
• Starting the video KYC recording before the customer has seen a notice.
• Letting DSAs collect documents on WhatsApp and personal phones.
• Reading section 17(1)(f) as permission to contact a defaulter’s family, friends or employer.
• Keeping rejected applicants’ documents and bureau reports forever.
• Storing full Aadhaar images in the loan origination system and in email.
• Erasing a closed customer’s KYC record, which the law requires you to keep, while keeping their marketing profile, which it does not.

Frequently asked questions

Do we need consent for KYC when the law requires it? The Act’s own illustration treats video KYC for a bank account as a request that needs a notice describing the data and the purpose. In practice, KYC for an account the customer applied for rests on consent or on section 7(a). Either way, give the notice first, collect only what the KYC rules require, and keep the records for the period the law sets.

A customer closed her account and asked us to erase everything. What do we do? Keep what the law requires, such as identity records for ten years after closure in the Act’s own example, and stop using them for anything else. Erase the rest: marketing data, app analytics, cross-sell flags. Tell her what you kept and why.

How do Account Aggregators fit with DPDP Consent Managers? Account Aggregators are licensed by RBI and move financial data between institutions under a consent artefact, without reading it. A DPDP Consent Manager is registered with the Data Protection Board and lets people give, manage, review and withdraw consent. The Rules’ own Consent Manager illustration, a person routing consent from one bank to another, is close to the AA model. Honour both: AA consent governs the data pull; DPDP governs your notice, purpose, retention and rights once you hold the data.

Does the defaulter exemption mean DPDP does not apply to collections? No. Section 17(1)(f) lifts most of Chapter II and Chapter III only for processing to ascertain a defaulter’s financial information, assets and liabilities, and only where disclosure follows other laws. Your accountability for processors (section 8(1)) and security (section 8(5)) remain. It does not cover borrowers who are not in default, or harassment of third parties.

Are NBFCs and cooperative banks “financial institutions” for section 17(1)(f)? The Act borrows the meaning from section 3(14) of the Insolvency and Bankruptcy Code. Scheduled banks are clearly included. Whether your NBFC, HFC or cooperative bank falls within it depends on that definition. Confirm the current requirement with counsel.

Can we share a borrower’s data with our group insurer for credit-linked cover? If the borrower asks for the cover, sharing what the insurer needs to issue it can rest on 7(a) or consent. Using the loan file to market other insurance products needs separate consent, and the cover must not be a condition of the loan unless the product requires it and the customer is told.

Are we likely to be a Significant Data Fiduciary? Large banks and lenders process high volumes of sensitive financial data, which is the kind of factor section 10(1) names. No SDF list has been published yet. Plan as if you will be notified: a DPO based in India, an independent data auditor, and a DPIA and audit every 12 months under rule 13.