DPDP for fintech

Regulators decide what to keep; the Act decides how to handle it

The DPDP Act sits alongside the KYC, record-keeping and data-localisation rules of the Reserve Bank, SEBI and IRDAI. Data may be kept where another law requires it (s. 8(7)), and for transfers outside India a stricter law, such as the requirement to store payment system data only in India, continues to apply (s. 16(2)). Where the Act and another law genuinely conflict, the Act generally prevails (s. 38(2)). Under legal review: How s. 38(2) interacts with specific RBI, SEBI and IRDAI directions should be confirmed for each product.

Most fintech gaps appear where the two meet. A regulator may require a KYC record to be kept for a set period. The Act then expects that record to be protected for that period, used for that purpose only, and erased when the period ends. Keeping it in case it is useful later is not a purpose.

The roles also need writing down. In digital lending the app is often run by a lending service provider acting for a regulated entity that makes the loan. Who is the Data Fiduciary for each piece of data depends on that arrangement, and it decides who answers the customer’s requests and who reports a breach.

The Reserve Bank’s digital lending directions also limit which phone resources a lending app may read, such as contacts, files and call logs. Treat those limits and the Act’s data-minimisation duty as one requirement when you review app permissions. Under legal review: The current RBI digital lending directions and their exact limits on access to phone resources should be confirmed from rbi.org.in.

The regulator decides

Which KYC documents to collect, how long to keep them, where some data must be stored, what goes to credit bureaus.

The Act decides

What the customer is told, what consent covers, who may see the data, how a breach is reported, when the rest is erased.

The facts decide

Which of you, the app or the regulated entity, decides why and how each dataset is used. Write that split into the agreement, and make sure practice matches it.

The three roles, in a worked case

The Act gives three roles. The Data Principal is the person the data is about. The Data Fiduciary decides why and how it is used, and carries the duties. A Data Processor handles it on the fiduciary’s behalf, under a contract. The same business can be a fiduciary for some data and a processor for other data.

The case

Priya applies for a personal loan in an app run by a lending service provider. The loan is made by a partner NBFC. A video-KYC firm verifies her, the app fetches six months of bank statements through an account aggregator, and a collection agency is engaged after a missed instalment.

Write the split into the agreement between the app and the NBFC. If the app later uses Priya’s bank statements to offer her a credit card from another partner, it has decided a new purpose and needs her consent for it.

What a fintech holds, and where it goes

Where it comes in

Each is a point where consent may be asked for; where it is, a notice must come with it or before it (s. 5).

• App sign-up and mobile-number verification
• Video-KYC and document upload
• Account aggregator and credit bureau pulls
• Phone permissions requested by the app
• Partner and agent onboarding (DSAs, merchants, branches)
• Support and collection calls

Where it goes

Where fintechs are most exposed

Severity follows the same rules as the assessment; your own result sets it from your answers. How severity is set.

Who else handles the data

You answer for what your processors do with the data (s. 8(1)), and you need a valid contract with each (s. 8(2)). Some vendors are fiduciaries in their own right; the table says where that is common.

43 controls written for fintechs, on top of 66 common ones

Alongside the common controls, the fintech assessment asks about the places where financial data is most exposed: KYC storage, app permissions, the split of roles with partner lenders and insurers, partner APIs, bureau and aggregator consents, card and account data, credit decisions, collections, regulator and CERT-In reporting, and where data is hosted.

Each control is weighted by how critical it is and tied to the section of the Act or rule behind it. How results work.

Six of the questions you will be asked

Questions ask what you actually do, not whether you have a policy. Each answer maps to one control.

1. FIN-08 High

   For each product you run with a bank, NBFC or insurer, have you agreed in writing who is the Data Fiduciary for which customer data?

   Answers: Yes, Partly, No, Not sure · “Yes” means: A written split exists for every partner product.

   Why it is asked: Where a regulated entity owns the customer relationship, it is usually the Data Fiduciary and you act for it. Where you also use the data for your own purposes, you are a fiduciary for that. Each side owes different duties.

2. FIN-03 High

   Does your app ask only for the phone permissions (contacts, SMS, location, photos) that the stated purpose actually needs?

   Answers: Yes, Partly, No, Not sure · “Yes” means: Each permission is justified by a stated purpose.

   Why it is asked: Consent covers only the data necessary for the purpose. Permissions beyond that, such as reading the contact list, have no lawful basis and have been misused in recovery.

3. FIN-06 High

   Before fetching data through an account aggregator or a credit bureau, do you record a consent that names that specific purpose?

   Answers: Yes, Partly, No, Not sure · “Yes” means: A purpose-specific consent is recorded for every pull.

   Why it is asked: Consent must be specific to the purpose and you must be able to prove it.

4. FIN-21 Critical

   Are the APIs that expose customer data, including the ones your own app calls, authenticated for every caller, limited to the fields each caller needs, rate-limited and logged?

   Answers: Yes, Partly, No, Not sure · “Yes” means: All four controls are in place.

   Why it is asked: An API is a door to customer data. Weak or broad APIs are a common cause of large leaks.

5. FIN-01 Critical

   Are KYC documents (PAN, Aadhaar, address proofs, photographs, video-KYC recordings) stored with access limited to the staff who need them, and kept only as long as the KYC rules require?

   Answers: Yes, Partly, No, Not sure · “Yes” means: KYC store is restricted, logged and on a retention rule.

   Why it is asked: Identity documents are the most valuable data in a fintech breach. Security safeguards carry the highest penalty ceiling.

6. FIN-36 High

   Before data is used in a credit decision, do you check it is complete and accurate, and can a customer correct it and ask for the decision to be looked at again?

   Answers: Yes, Partly, No, Not sure · “Yes” means: Checked before use, with a correction route.

   Why it is asked: Data used to make a decision about a person must be complete, accurate and consistent.

All 43 questions written for fintechs

1. FIN-08 For each product you run with a bank, NBFC or insurer, have you agreed in writing who is the Data Fiduciary for which customer data? Organisation and role mapping
2. FIN-09 Do you identify the co-applicants, guarantors, nominees, references and emergency contacts whose details you collect, and give them a notice where you rely on their consent? Data inventory and purpose
3. FIN-03 Does your app ask only for the phone permissions (contacts, SMS, location, photos) that the stated purpose actually needs? Data inventory and purpose
4. FIN-44 When you analyse bank statements or SMS for underwriting or budgeting, do you extract only the fields you need and delete the raw files after analysis? Data inventory and purpose
5. FIN-10 Do you find and delete data from rejected applications, abandoned sign-ups and old lead lists that you no longer need? Data inventory and purpose
6. FIN-20 Is data collected for fraud and risk checks (device fingerprints, location, behaviour signals) used only for those checks, and not for marketing or profiling for sales? Data inventory and purpose
7. FIN-43 When agents, DSAs or partners onboard customers, does the customer receive your notice directly (SMS, app or paper), not only the agent's explanation? Notice and transparency
8. FIN-30 Are customers told at the start of support and collection calls that the call is recorded, and why? Notice and transparency
9. FIN-35 Is consent to offers of other products (insurance, cards, other loans) asked for separately from the consent needed to open and run the account? Consent and lawful basis
10. FIN-29 Before support staff disclose or change account details, do they verify the caller against details only the customer would know or a registered device? Data Principal rights
11. FIN-46 Can customers see and download their own profile, statements and consents in the app, without having to write in? Data Principal rights
12. FIN-11 Does each kind of customer record (KYC, transactions, call recordings, application data) have a retention period, with the regulatory reason where one applies, and is it deleted when the period ends? Retention and deletion
13. FIN-31 When a customer closes their account or withdraws consent, do you stop using their data, tell partner lenders and vendors, and keep only what a law requires? Retention and deletion
14. FIN-32 Are phones and laptops used by field agents, collection staff and support teams wiped before they are reissued, returned or disposed of? Retention and deletion
15. FIN-01 Are KYC documents (PAN, Aadhaar, address proofs, photographs, video-KYC recordings) stored with access limited to the staff who need them, and kept only as long as the KYC rules require? Security safeguards
16. FIN-02 Do you avoid storing or displaying full Aadhaar numbers where the Aadhaar rules do not allow it, for example by masking all but the last four digits? Security safeguards
17. FIN-12 Is account and transaction data encrypted at rest, and are account numbers masked in screens, reports, exports and logs? Security safeguards
18. FIN-34 Do you avoid storing card numbers yourself, keeping only tokens or the last four digits? Security safeguards
19. FIN-45 Are the cloud accounts that hold customer data protected: production access restricted, encryption keys managed, public storage blocked, and configuration reviewed? Security safeguards
20. FIN-39 Are development and test environments kept free of real customer data, or use masked copies only? Security safeguards
21. FIN-33 Does your breach plan also cover the reports your regulators and CERT-In expect, with one owner coordinating them and the DPDP reports? Breach response
22. FIN-47 When accounts are taken over or fraud exposes customer data, do you assess whether it is a personal data breach that must be reported? Breach response
23. FIN-22 Do written agreements with every vendor that handles customer data (KYC and video-KYC providers, cloud, SMS, collection agencies, call centres) cover purpose, security safeguards, breach notice to you, and return or deletion at the end? Processors and vendors
24. FIN-23 Before a vendor or partner gets customer data, and at least yearly after, do you check its security, where it stores data and who can access it? Processors and vendors
25. FIN-04 Is customer data shared with partner lenders, insurers or co-lending partners only under written terms, and are the kinds of partner named in your privacy notice? Data sharing and disclosure
26. FIN-25 Do you keep a record of which partners, bureaus and authorities received each customer's data? Data sharing and disclosure
27. FIN-26 Are requests for customer data from police, tax authorities or regulators checked by a named person, answered in writing and logged? Data sharing and disclosure
28. FIN-24 Do you know where each system and vendor stores customer data, including SaaS tools, backups and analytics? Transfer and storage location
29. FIN-07 Do you know which sector rules require payment or customer data to be stored in India, and does your hosting meet them? Transfer and storage location
30. FIN-27 Can you show, for any customer, which notice version they saw and which consents they gave, through app and assisted channels? Records and evidence
31. FIN-14 Is staff and support access to customer financial data limited by role, protected by two-step sign-in, and logged? Access control
32. FIN-13 Do customer logins use device binding or a second factor for sensitive actions, with alerts for new devices and unusual activity? Access control
33. FIN-18 When staff, agents or outsourced call-centre staff leave or change role, is their access removed or changed the same day? Access control
34. FIN-19 Do you review every quarter who can access the KYC store, production databases and admin consoles, and remove what is not needed? Incident testing
35. FIN-28 Is there a written policy on handling customer financial data, covering collections conduct, call recordings, screenshots and sharing on messaging apps? Policy and training
36. FIN-48 Are collection agents and support staff, including those of agencies, trained on what customer data they may use and disclose, and to whom? Policy and training
37. FIN-36 Before data is used in a credit decision, do you check it is complete and accurate, and can a customer correct it and ask for the decision to be looked at again? Data quality
38. FIN-37 Is data you report to credit bureaus checked before reporting, and are disputes corrected and passed on promptly? Data quality
39. FIN-41 Where you act for a regulated lender, is data collected through your app passed only to that lender and used and deleted as it instructs? Data sharing and disclosure
40. FIN-05 Are collection agents limited to the data they need for a given account, and barred from contacting people other than the borrower? Data sharing and disclosure
41. FIN-06 Before fetching data through an account aggregator or a credit bureau, do you record a consent that names that specific purpose? Consent and lawful basis
42. FIN-21 Are the APIs that expose customer data, including the ones your own app calls, authenticated for every caller, limited to the fields each caller needs, rate-limited and logged? Access control
43. FIN-42 Before a third-party app receives a customer's data through your API, has the customer agreed to that specific app and purpose, with a way to revoke it? Consent and lawful basis

Evidence that may be asked for

A “yes” is self-declared until something shows it. These are the documents and records that usually do. Your own result lists what each control needs.

• Privacy notice in the app, shown before data is collected, naming purposes and partners
• The agreement with each regulated entity, showing who is the fiduciary for which data
• App permission list with the purpose of each permission, and the screens that request them
• Stored consent records for an account aggregator or bureau fetch, for a sample customer
• API documentation showing per-partner keys and the fields each partner receives
• Access list for KYC storage and an extract of its access log
• Retention schedule linked to the regulators’ record-keeping periods, with the last erasure run
• Breach plan covering the Data Protection Board, customers, CERT-In and your regulator, with one owner

What makes evidence good enough · How the Evidence Room keeps it

First actions, in the order they usually make sense

1. Remove phone permissions the stated purpose does not need

   Now

2. Restrict KYC storage to named roles and switch on access logging

   Now

3. Write down, with each partner lender and insurer, who is the fiduciary for which data

   Now

4. Issue per-partner API keys and trim responses to the fields each partner needs

   Before 13 May 2027

5. Separate marketing and cross-sell consent from loan or account consent

   Before 13 May 2027

6. Set a retention schedule per record type and an erasure routine

   Before 13 May 2027

7. Rehearse a breach: Board and customers, CERT-In and your regulator, on one timeline

   Ongoing, yearly

Your own result orders these by your answers and the law’s dates. How to plan remediation.

The reports a fintech usually needs

Fintechs are usually asked about data protection by the regulated entities they work with, before a partnership and at every review.

Every report states whether the result is Self-Assessed, Evidence-Supported or Expert-Verified. None is a certificate or a statement of compliance. All six reports.