DPDP Act23 May 2026 7 min read

DPDP Act for Fintech: Data Protection in Financial Services

DPDP Act obligations for Indian fintech companies — consent for credit and payments data, RBI overlap, employee and customer data protection, and what SDF classification means for fintechs.

Key Takeaways

Fintech companies process some of the most sensitive personal data — payment history, credit scores, income, identity — making them high SDF candidates.
RBI's data localisation and security requirements interact with (but do not substitute for) DPDP Act obligations.
Consent for credit data processing is complex — NBFC and lending regulations create friction with DPDP Act consent standards.
Account Aggregator integration creates new data flow obligations that must be managed under both RBI and DPDP frameworks.
Fintech companies building DPDP compliance now are positioning for the enterprise and bank partnership deals that require it.

In this guide

The Fintech Data Landscape: What Data You Process
RBI Requirements and DPDP Act: How They Interact
Consent for Credit and Payment Data Processing
Account Aggregator and DPDP Act Compliance
Significant Data Fiduciary Risk for Fintechs
Lending Data: Credit Bureau Access and Consent
Priority Compliance Steps for Fintechs

The Fintech Data Landscape: What Data You Process

Fintech companies process some of the most sensitive and comprehensive personal data in the digital economy. A lending app knows your income, employer, bank account transactions, existing loans, and credit score. A payments app knows your spending patterns, merchant preferences, and financial relationships. A wealth management platform knows your investment portfolio, risk appetite, and long-term financial goals.

This data comprehensiveness — combined with the financial consequences of misuse — makes fintech companies particularly high-risk under the DPDP Act. Fraud using financial personal data can directly harm individuals' financial wellbeing in quantifiable, immediate ways. The Data Protection Board is likely to treat fintech data breaches with particular seriousness.

Fintech data processing also tends to involve multiple data sources: your own collected data, data from credit bureaus (CIBIL, Experian, Equifax, CRIF High Mark), data from the Account Aggregator framework, data from banking partners, and data from public sources (Aadhaar, PAN, GST records). Each data source has its own legal basis and consent requirements.

RBI Requirements and DPDP Act: How They Interact

RBI has issued extensive data-related guidelines for regulated entities: the 2018 data localisation circular (payment data stored only in India), the 2020 Digital Lending Guidelines (data minimisation and consent requirements for digital lenders), the 2021 Master Direction on Information Technology, and the Framework for Outsourcing of IT Services. These create a layered compliance environment for fintech companies.

The DPDP Act and RBI requirements are not mutually exclusive — you must comply with both. In areas of overlap, the more stringent requirement applies. RBI's data localisation for payment data (India-only storage) is more stringent than DPDP Act's whitelist approach; follow RBI's requirement. DPDP Act's consent standards may be more detailed than some RBI guidelines; follow DPDP Act.

RBI's 2020 Digital Lending Guidelines require lenders to disclose their data collection practices and obtain borrower consent before accessing device data (contacts, SMS, location). These requirements predate the DPDP Act but are broadly consistent with it. However, the DPDP Act's "specific consent" requirement may require unbundling consent currently collected in a single digital lending consent form.

Fintech lending creates consent complexity. A lender needs: identity verification consent (Aadhaar/PAN lookup); credit bureau inquiry consent (CIBIL, Experian); bank statement access consent (AA framework or manual upload); and ongoing loan management processing consent. Each of these is a distinct processing activity requiring separate, specific consent under Section 6.

The current industry practice — a long consent form signed at loan application that covers all downstream data use — may not satisfy DPDP Act's "specific" and "unbundled" consent requirements. Review your loan application consent architecture and consider implementing a step-by-step consent flow that clearly identifies each data access and its purpose.

Payment processing creates separate consent obligations. UPI apps, wallets, and payment gateways process transaction data for payment execution (a necessary processing for service delivery), fraud prevention (a potential Section 7 legitimate use), and analytics/product improvement (requires consent). Ensure your privacy notice clearly distinguishes these purposes and obtains consent where required.

Account Aggregator and DPDP Act Compliance

The RBI's Account Aggregator (AA) framework creates a consent-based financial data sharing ecosystem. Under the AA model, a Financial Information User (FIU) — such as a lender — requests financial data about a user from a Financial Information Provider (FIP) — such as the user's bank — through a licensed Account Aggregator. The user consents to each data sharing through the AA interface.

The AA framework and DPDP Act create complementary consent regimes for financial data. AA consent is purpose-specific, time-limited, and auditable — consistent with DPDP Act's consent requirements. However, AA consent covers data sharing between FIPs and FIUs; it does not cover the FIU's downstream use and retention of the shared data. That downstream processing requires DPDP Act-compliant consent.

Fintech companies using the AA framework should: document the AA consent as evidence of lawful data access; separately obtain DPDP Act consent for downstream processing (credit scoring, product decisions, further sharing); and implement data retention policies aligned with the purpose for which AA-shared data was obtained.

Significant Data Fiduciary Risk for Fintechs

Large fintech companies — major UPI apps with hundreds of millions of users, large NBFC lenders, established digital wallets — are strong candidates for SDF classification. They process high volumes of sensitive financial data, have national reach, and their systemic importance to the financial system could make them "critical to the sovereignty and integrity of India" — one of the Section 10 classification factors.

If classified as SDFs, these fintechs will need to: appoint an India-based DPO; conduct DPIAs for high-risk processing (AI-based credit scoring, behavioural profiling for fraud); undergo annual independent data audits; and comply with potentially stricter data localisation requirements for financial personal data.

Fintech companies approaching the scale likely to trigger SDF classification should begin preparing their SDF compliance layer now: identify a DPO candidate, initiate DPIA processes for high-risk analytics, and ensure your data audit infrastructure is ready. The 6-12 month window between SDF classification and compliance deadline is very tight for companies that have done no preparation.

Lending Data: Credit Bureau Access and Consent

Accessing a borrower's credit report requires consent under the DPDP Act and under CIBIL's own membership requirements. The consent must specifically identify that you will access credit bureau data and for what purpose (credit assessment). Generic consent for "accessing financial information" is insufficiently specific.

Credit bureau data retention creates compliance challenges. After a loan is repaid, how long do you retain the credit report? The DPDP Act requires erasure when the processing purpose is served. For a repaid loan, the credit decision purpose is served — but you may have legitimate grounds (legal obligation, audit requirements) to retain certain data for a defined period. Document your retention policy with specific legal bases for each retention period.

Negative credit data — missed payments, defaults, collection actions — is particularly sensitive. Ensure your handling of this data complies with both the Credit Information Companies Regulation Act 2005 and the DPDP Act. Inaccurate negative data can cause significant harm to Data Principals; the correction right under Section 12 is particularly important in this context.

Priority Compliance Steps for Fintechs

Priority 1: Audit your consent architecture. Map every consent currently collected in your customer journey against DPDP Act requirements — is it specific, unbundled, and truly informed? Identify consents that need redesigning and build a re-consent roadmap.

Priority 2: Review your data retention schedule for financial data. Credit reports, bank statements, transaction records, and identity verification records all have complex retention requirements driven by RBI, Income Tax, PMLA, and DPDP Act. Document each retention period with its legal basis and implement automated deletion or archiving.

Priority 3: Prepare for SDF classification if you operate at scale. Identify your DPO candidate, initiate DPIA processes for AI/ML-based credit and fraud models, and build your annual audit readiness programme. Use AuditPath to track DPDP compliance controls alongside your existing RBI compliance programme.

Frequently Asked Questions

Does PMLA (Prevention of Money Laundering Act) data retention override DPDP Act erasure requests?

Yes. PMLA requires KYC records and transaction records to be retained for 5 years after the business relationship ends. A Data Principal's erasure request cannot override this legal obligation. When you decline an erasure request due to PMLA retention requirements, explain the legal basis clearly to the Data Principal and erase the data once the PMLA retention period expires.

Does RBI's 2018 data localisation requirement for payment data satisfy DPDP Act cross-border transfer rules?

RBI's requirement is that payment data be stored in India — a localisation requirement that is stricter than the DPDP Act's whitelist approach. Full compliance with RBI's localisation requirement means payment data is not transferred cross-border at all, which by definition satisfies DPDP Act cross-border transfer restrictions for that data category. However, non-payment personal data still needs to be assessed against the DPDP Act whitelist.

Our lending app uses a credit score algorithm trained on historical borrower data. Is this DPDP Act-compliant?

The use of historical data to train AI models raises DPDP Act questions around purpose limitation and lawful basis. If the historical data was collected for credit assessment (lending decisions), using it to train models for the same purpose may be consistent with the original purpose. However, if the model output is used in ways not covered by the original consent, re-consent may be required. Conduct a DPIA for your credit model training and document the lawful basis carefully.

We collect location data for fraud prevention. Is this permitted under DPDP Act?

Fraud prevention may fall within Section 7(f)'s legitimate use (verification/fraud prevention — subject to Rules). Until the Rules clarify the scope of Section 7(f), obtain specific consent for location data collection and state the fraud prevention purpose clearly in your consent request and privacy notice. Location data is particularly sensitive and deserves careful handling.

Our app is used by customers under 18 for UPI payments. How do we handle this?

Section 9 requires verifiable parental consent for under-18 users. UPI payments by minors are permitted under RBI guidelines but DPDP Act compliance requires age verification and parental consent for any personal data processing. Implement age verification in your onboarding flow and obtain verifiable parental consent for minor users before processing their financial data.