A customer repays a loan, closes the account and asks you to delete their data. Customer support wants to honour the request. Compliance says some records must stay. The growth team still has the customer in a campaign audience.
All three teams are looking at the same person, but they are making different decisions about different uses of data. The answer needs to identify what processing stops, what must be retained, who holds each copy and what the customer should be told.
For Indian fintechs, DPDP and financial-sector requirements need to be mapped together at the activity and record level. KYC retention is not automatically a conflict with DPDP: Sections 8(7) and 12(3) expressly recognise retention necessary for compliance with law. The difficult work is applying that exception accurately without using it to justify keeping everything active forever.
Updated 3 October 2026. The main DPDP business obligations discussed here are scheduled to commence in May 2027 under the government's notification. Existing RBI and anti-money-laundering requirements operate on their own timelines.
Identify the regulated entity before choosing the rulebook
“Fintech” describes a market, not one regulatory status. A bank, an NBFC lender, a lending service provider, a payment business and a software vendor may have different direct obligations even when they participate in the same customer journey.
RBI now maintains entity-specific consolidated directions. For example, commercial banks should refer to the applicable Credit Facilities Directions, including the digital-lending provisions, and Know Your Customer Directions. Other regulated entities need the directions for their category. Check the current version and applicable amendments when recording a requirement.
Map the entities before mapping the controls:
| Participant | What to establish |
|---|---|
| Regulated lender | Its category, applicable RBI directions, lending decisions, required records and reporting duties |
| Lending service provider (LSP) | The services performed for the lender, permitted data access and storage, contractual duties and any independent processing |
| Account Aggregator or other data-sharing participant | Its role in the actual arrangement, the authorised data flow and what the recipient may do afterward |
| KYC, cloud, analytics or support provider | Which records it receives, whose instructions it follows, its security controls and any independent purpose |
| Group company or commercial partner | Whether it is a processor, a separate fiduciary or participates in determining the purpose and means |
The DPDP role assessment runs alongside the regulatory map. A contract calling a company an LSP does not settle every Data Fiduciary question. Establish who decides the purpose and means of each processing activity. Our Data Fiduciary guide works through that test.
In the conversations with more than a dozen Indian fintech compliance leads that informed the original version of this guide, the recurring difficulty was knowing where the frameworks meet. The most useful starting point is a shared data-flow map that names the entity responsible at every handoff.
Onboarding: connect each data request to a purpose
Consider an illustrative lending journey. The customer supplies contact details, completes identity checks, authorises access to financial information and receives an offer. An analytics SDK also records activity along the way.
Those steps should not disappear into one “I agree” event. For each, establish the data needed, the purpose, the applicable legal requirement or basis, the recipient and the evidence of the customer's choice where consent is required.
Sections 5 and 6 of the DPDP Act set the notice and consent framework. Rule 3 of the final Rules requires a clear notice with an itemised description of the personal data and the specified purposes, alongside the relevant routes for withdrawal and rights.
An Account Aggregator consent artefact can be important evidence for a particular financial-data sharing arrangement. Assess whether the entire customer experience also satisfies the applicable DPDP requirements. It should not be treated as blanket permission for unrelated advertising, profiling or sharing with another business.
The same applies to KYC. A legal duty to obtain or retain particular identification information does not justify adding optional product analytics to that purpose. If the business needs the additional use, assess it separately and explain it accurately.
Inspect what the lending app actually collects
The digital-lending provisions in RBI's commercial-bank Credit Facilities Directions address need-based collection with prior explicit consent and an audit trail. They restrict access to phone resources such as contact lists and call logs, with a limited route for one-time access to facilities necessary for onboarding or KYC with explicit consent. They also address borrower choices, third-party sharing and limits on LSP storage.
Apply the provisions relevant to your regulated entity and arrangement. The product review should inspect actual permissions and payloads, not stop at the privacy-policy wording.
For example:
- Does the app request a permission when the relevant feature is used, or at first launch before the purpose is clear?
- Does an SDK receive document images, account identifiers or financial details that it does not need?
- Does declining an optional choice prevent an otherwise available service without a justified reason?
- Can the team identify which notice and consent record supported a particular data transfer?
- Does the LSP retain a copy beyond the data and purpose permitted by the arrangement?
A mobile permission prompt and a privacy notice perform different jobs. A user tapping “Allow camera” does not explain every later use of the image.
Keep this review connected to engineering. Inspect a successful application, an abandoned application and a declined permission path. They may produce different records and different downstream copies.
KYC retention: use the right record and the right clock
For reporting entities, Section 12 of the Prevention of Money-laundering Act distinguishes between transaction records and records evidencing client or beneficial-owner identity, account files and business correspondence.
| Record covered by Section 12 | Statutory retention trigger |
|---|---|
| Transaction records under Section 12(1)(a) | Five years from the transaction date under Section 12(3) |
| Identity records, account files and business correspondence under Section 12(1)(e) | Five years after the business relationship ends or the account closes, whichever is later, under Section 12(4) |
Check the applicable RBI directions, other requirements and any valid preservation obligation as well. The important distinction is that the clocks do not necessarily start at the same time.
Suppose a transaction occurs in 2026 and the customer relationship ends in 2029. Using the transaction date for every record could erase identification records too early. Keeping all data indefinitely because “KYC needs five years” has the opposite problem: it loses the connection between the record, the requirement and its end point.
DPDP's legal-retention exception accommodates necessary retention. The final DPDP Rules also introduce their own requirements, including Rule 8(3)'s minimum one-year retention for the covered processing data and logs for the Seventh Schedule purposes. Account for each applicable provision rather than choosing whichever single period looks longest and applying it to the whole customer profile.
A practical retention register should identify the entity holding the record, record category, legal basis, start event, period, access restrictions, review or erasure date and responsible owner. An LSP should not assume the lender's obligation gives it an unrestricted right to keep duplicate customer files.
Account closure is where the design gets tested
Return to the customer who has repaid the loan and requested deletion. First verify the request and determine which processing activities and records it covers. Then make separate decisions.
| Data or use | Decision to assess | Evidence to keep |
|---|---|---|
| Active marketing profile | Stop the relevant consent-dependent use and assess erasure | Suppression or removal result and the systems reached |
| Required KYC archive | Retain the legally required subset for the applicable period with restricted use | Provision, trigger date, retention end or review date and access policy |
| Loan and transaction records | Apply the relevant transaction, account and other retention rules | Category-level decision and owner |
| LSP working copies | Apply the service limits, instructions and any independent legal duties | Processor action or documented retention reason |
| Support attachments and analytics copies | Review purpose, necessity, retention and deletion across the actual systems | Completed tasks or justified exceptions |
This is a decision aid, not a direction to erase a particular record without checking the facts.
The response should explain what has stopped, what has been erased and what remains for a stated reason. Avoid “all data deleted” if the regulated lender must keep an archive. Equally, avoid rejecting the entire request just because one category has to be retained.
Test whether a retained archive can still feed the marketing system. Restrictions on use need to exist in access permissions and integrations, not only in the retention policy. Our DSR portal guide explains how to track partial outcomes and processor completion.
Storage location needs its own assessment
Section 16 of the DPDP Act provides for restrictions on transfers outside India and preserves laws that provide a higher degree of protection or restriction. DPDP should not be described as a universal requirement to host every kind of personal data only in India.
Financial-sector requirements can be more specific. The commercial-bank digital-lending provisions, for example, address storage in India and the handling of data processed abroad. Payment systems and other regulated activities need their own applicable-rule review.
Create a location map that includes the main application, backups, logs, analytics, support tools and vendor access. Selecting an India region for the production database does not establish the location of every copy in the service.
For each provider, ask where the relevant data is stored and processed, what the applicable rule permits and how the arrangement is evidenced. Keep the answers specific to the data flow rather than relying on a broad “India compliant” description.
Incident reporting: prepare separate routes from one incident record
A fintech incident can involve several notification duties. Build one factual incident record and map each reporting obligation to it.
Under Rule 7 of the DPDP Rules, affected individuals and the Board must receive the applicable initial intimations without delay. The detailed Board update follows within 72 hours of awareness, unless longer is permitted on a written request.
The CERT-In Directions separately require covered entities to report the specified Annexure I incident categories within six hours of noticing or being informed. Assess RBI reporting against the direction for your entity and incident. There is no single RBI deadline that this article can responsibly assign to every business called a fintech.
Your reporting matrix should contain the trigger, recipient, start event, deadline, submission route and authorised owner. Include the lender and service provider's contractual notification duties so the party holding the first evidence knows whom to contact.
Test a case where the LSP discovers the incident outside business hours and the lender initially has incomplete information. Waiting for a final root-cause report can be incompatible with an earlier notification obligation.
Frequently asked questions
The main DPDP business duties discussed below are scheduled to commence in May 2027 under the government's commencement notification. Existing sectoral and cybersecurity requirements operate on their own timelines.
Does consent for KYC also cover marketing or product analytics?
Permission or a legal requirement to process KYC information does not create blanket permission for marketing or product analytics. Those uses have different purposes and need their own assessment. Identify what the lender, LSP and each SDK receive, and separate mandatory collection from optional uses. An Account Aggregator consent artefact likewise needs to be assessed against its authorised data flow, rather than treated as permission for unrelated reuse.
Sources: DPDP Act, Sections 4 to 7; RBI Commercial Banks Credit Facilities Directions.
Must a lender delete all customer data when a loan is repaid?
Repaying a loan does not automatically end every retention obligation. A reporting entity may need to retain KYC and transaction records under anti-money-laundering requirements, with additional duties under the applicable RBI directions. Review the request by record and purpose: preserve the required archive, assess erasure of other copies and stop processing that no longer has a valid basis. Explain any retained categories instead of claiming that all data has been deleted.
Sources: PMLA, Section 12; DPDP Act, Sections 8(7) and 12.
When does the five-year KYC retention period start?
For the records covered by PMLA Section 12, the five-year clocks differ. Transaction records are retained for five years from the transaction date. Identity records, account files and business correspondence are retained for five years after the business relationship ends or the account closes, whichever is later. Check additional applicable requirements before disposal. Five years from signup is not a reliable rule for every record.
Sources: PMLA, Sections 12(3) and 12(4).
Can an LSP keep its own KYC archive because the lender must retain one?
An LSP should not assume that the lender's KYC retention duty authorises its own duplicate archive. Establish which records the LSP may store under the applicable RBI directions, the service arrangement and any independent legal duty. The commercial-bank digital-lending provisions include limits on LSP storage. Record the permitted subset and retention reason, and check that backups, support attachments and exports follow the same decision.
Can a digital-lending app access a borrower's phone contacts if they agree?
A borrower's consent does not override the applicable RBI digital-lending restrictions on phone resources such as contact lists and call logs. The commercial-bank provisions distinguish those resources from limited, one-time access to facilities needed for onboarding or KYC, with explicit consent. Check the directions for the lender's category and inspect the permissions requested by the app and its SDKs. An operating-system permission prompt does not settle regulatory compliance.
Can a fintech use an overseas cloud provider for Indian customer data?
An overseas provider's name does not decide whether a fintech's data arrangement is permitted. Assess the relevant regulated entity, activity and data locations against the applicable RBI requirements and DPDP transfer framework. The commercial-bank digital-lending provisions include India-storage requirements and conditions for processing abroad. Include backups, logs, analytics and support access in the location map. Hosting the main database in India does not establish where every copy is processed.
Sources: RBI Commercial Banks Credit Facilities Directions; DPDP Act, Section 16.
A useful review for the next product release
Bring product, engineering and compliance together around one customer journey. Use these questions as the agenda:
- Can we name the regulated entity and the fiduciary or processor for each activity?
- Can we trace each collected field to a purpose, recipient and applicable requirement?
- Can a customer decline or withdraw an optional choice, with the expected effect downstream?
- Do retention jobs use the correct event for each record category?
- Can we show what an LSP stores and why it is permitted to store it?
- Does account closure stop inappropriate reuse while preserving required records?
- Can we identify where the data and its copies are stored and processed?
- Can the incident team meet each applicable reporting obligation with the information likely to be available?
The output should be a set of decisions, fixes and named owners. This gives you something concrete to revisit at the next release, when a new SDK or partnership changes the data flow.
For the broader comparison, see DPDP compliance by industry. ComplyZero is a DPDP compliance platform for Indian businesses, built by data protection lawyers and cybersecurity experts. Book a walkthrough to discuss how these decisions can connect to your controls, privacy work and evidence.
This article is for informational purposes and reflects the DPDP Act 2023 and DPDP Rules 2025 as understood at the time of writing. For guidance specific to your business, we recommend consulting a qualified data protection professional.
