DPDP Compliance for Fintech: RBI Overlap, Payment Data, and Consent Rules
How the DPDP Act 2023 intersects with RBI data localisation mandates, payment data protection, and consent requirements for fintech companies operating in India.
Fintech Operates Under Two Data Regimes
Every fintech company operating in India now sits at the intersection of two regulatory frameworks that govern personal data. The DPDP Act 2023 establishes the baseline data protection obligation for all organisations processing personal data of Indian residents. The Reserve Bank of India’s data localisation circulars, issued from April 2018 onward, impose additional storage and processing requirements specific to payment system data.
Neither framework exempts the other. A fintech company that achieves full compliance with RBI’s data localisation mandate is not, by that fact alone, compliant with the DPDP Act. The reverse is equally true. These are independent regulatory regimes with distinct enforcement authorities, separate penalty structures, and overlapping (but not identical) obligations.
This dual burden makes fintech one of the most exposed sectors under the DPDP Act. Payment companies, lending platforms, insurance aggregators, and investment apps all collect categories of personal data that attract scrutiny from both the Data Protection Board and the RBI. Financial data is inherently sensitive, processing volumes are high, and the consequences of non-compliance are compounding.
The operational question is not whether these regulations apply to your fintech business. They do. The question is how to build a compliance architecture that satisfies both regulators simultaneously, without duplicating effort or creating contradictory policies.
RBI Data Localisation and DPDP: Where They Overlap
In April 2018, the RBI issued a circular (RBI/2017-18/153) directing all payment system operators to store the complete end-to-end transaction data relating to payment systems operated by them in India. The directive applied to all system providers authorised or approved by the RBI, including card networks, payment gateways, payment aggregators, and wallets. The compliance deadline was October 2018, later extended informally as the industry negotiated implementation details.
The DPDP Act 2023 introduces its own cross-border data transfer framework. Section 16 empowers the Central Government to restrict transfers of personal data to certain countries or territories through notification. Until such notifications are issued, personal data may be transferred outside India, subject to the general obligations of the Act. However, the DPDP Act does not override sector-specific localisation requirements. The RBI circular remains independently enforceable.
Where fintech companies must pay close attention is the gap between these two regimes:
| Dimension | RBI Data Localisation (2018) | DPDP Act 2023 |
|---|---|---|
| Scope | Payment system data (transaction data, card data, payment credentials) | All personal data of Data Principals in India |
| Storage requirement | Full end-to-end data must be stored in India | No blanket localisation; transfer restrictions by government notification |
| Cross-border transfer | Processing abroad permitted if data is deleted from foreign systems after processing and brought back to India | Permitted unless restricted by government notification under Section 16 |
| Enforcement authority | Reserve Bank of India | Data Protection Board of India |
| Penalty structure | Licence revocation, directions, monetary penalties under Payment and Settlement Systems Act 2007 | Up to Rs 250 crore per violation |
| Consent framework | RBI-specific consent guidelines (Account Aggregator, UPI) | Free, specific, informed, unconditional consent per Section 6 |
The practical consequence: a fintech company must maintain payment transaction data exclusively in India to satisfy RBI, while also ensuring that all personal data processing (including non-payment data such as KYC records, user profiles, and behavioural analytics) meets the DPDP Act’s standards for lawful processing, purpose limitation, and data minimisation.
If your cloud infrastructure routes data through servers outside India, even transiently, you may be in violation of one or both regimes. Architecture decisions about data residency are compliance decisions.
Consent Requirements for Financial Data
The DPDP Act’s consent framework requires that consent be free, specific, informed, unconditional, and captured through a clear affirmative action. For fintech companies, this standard intersects with multiple existing consent frameworks already mandated by financial regulators.
RBI’s Account Aggregator Framework
The Account Aggregator (AA) ecosystem, governed by RBI’s Master Direction on Account Aggregators (September 2016, amended), establishes its own consent artefact. When a Financial Information User requests data from a Financial Information Provider through an Account Aggregator, the customer must provide consent specifying the data requested, the purpose, the duration, and the frequency of access. This consent artefact is granular by design.
The DPDP Act does not replace this framework. Instead, it adds a parallel obligation. The consent captured through the AA flow satisfies RBI’s requirements, but may not satisfy the DPDP Act’s requirements if the broader data processing activities of the fintech company (marketing, analytics, profiling) are not covered by separate, purpose-specific consent.
UPI and Payment Consent
UPI transactions involve implicit consent at the point of transaction initiation. The user authorises a specific payment by entering a PIN. This transactional consent is narrow: it covers the payment itself, not the downstream processing of the transaction data for analytics, credit scoring, or cross-selling.
If your fintech product uses UPI transaction data to build credit profiles, recommend products, or generate risk scores, each of those secondary purposes requires its own consent capture under the DPDP Act. Relying on the payment authorisation as blanket consent for all downstream processing is a compliance failure.
Purpose Limitation in Practice
Section 5 of the DPDP Act requires that personal data be processed only for the purpose for which consent was obtained. For fintech, this creates specific constraints:
- Lending platforms: Collecting income data for loan underwriting does not permit using that data for marketing partner products. Separate consent is required.
- Insurance aggregators: Collecting health data for premium calculation does not permit sharing that data with reinsurers for unrelated analytics. The processing purpose must be stated at the point of consent.
- Investment apps: Collecting PAN and bank details for account opening does not authorise behavioural profiling for targeted advertising.
Each data processing purpose must be individually disclosed and individually consented to. Bundled consent (one checkbox covering multiple unrelated purposes) does not meet the standard set by Section 6 of the Act.
Data Principal Rights in a Financial Context
The DPDP Act grants Data Principal rights that apply to all personal data, including financial records. These rights include the right to access information about processing activities, the right to correction and erasure of personal data, and the right to nominate another individual to exercise these rights.
For fintech, the tension arises between these rights and the record-keeping mandates imposed by financial regulators.
The Retention Conflict
RBI regulations require financial institutions to retain transaction records for specified periods. The Prevention of Money Laundering Act (PMLA) 2002 mandates retention of customer identification records and transaction records for five years after the business relationship ends. The Income Tax Act requires retention of financial records for specified assessment periods.
The DPDP Act, by contrast, requires erasure of personal data when the purpose for which it was collected has been fulfilled, or when consent is withdrawn. Section 8(7) states that the Data Fiduciary must erase personal data upon withdrawal of consent, unless retention is required under any law for the time being in force.
This carve-out is the operational key. Fintech companies may retain personal data beyond the DPDP Act’s default erasure obligation if retention is mandated by another law (RBI circulars, PMLA, Income Tax Act). However, the burden is on the Data Fiduciary to document which specific legal provision requires the retention and for how long. A vague claim of “regulatory requirements” without identifying the specific law and the specific retention period does not satisfy the Act.
Responding to Erasure Requests
When a Data Principal exercises the right to erasure:
- Identify all personal data held about the individual across systems (payment records, KYC documents, communication logs, behavioural data)
- Classify each data category by its retention basis (consent, statutory obligation, contractual necessity)
- Erase all data held solely on the basis of consent
- Retain data required by law, documenting the specific statutory basis
- Communicate to the Data Principal what was erased and what was retained, including the legal basis for retention
This process must be systematised. Handling erasure requests manually, on a case-by-case basis, will not scale for a fintech company processing thousands or millions of customer records.
Breach Notification: DPDP Board and RBI Both Want to Know
A personal data breach in a fintech company triggers notification obligations under multiple regimes simultaneously.
The DPDP Act’s breach notification requirements mandate prompt notification to the Data Protection Board of India and every affected Data Principal. The specifics of timing and format will be defined through rules, but the obligation is absolute: every breach involving personal data must be reported.
Separately, the Indian Computer Emergency Response Team (CERT-In), operating under the Ministry of Electronics and IT, requires reporting of cybersecurity incidents within six hours of detection (CERT-In Direction of April 2022). This applies to all organisations, including fintech companies.
RBI’s own cybersecurity framework (RBI Circular on Cyber Security Framework, June 2016) requires banks and certain regulated entities to report cybersecurity incidents to RBI. While this originally targeted banks, subsequent guidance has extended reporting expectations to payment system operators and NBFCs.
| Reporting Obligation | Authority | Timeline | Scope |
|---|---|---|---|
| DPDP Act breach notification | Data Protection Board of India | Prompt (rules pending) | Personal data breaches |
| CERT-In incident reporting | CERT-In (MeitY) | 6 hours from detection | Cybersecurity incidents |
| RBI cyber incident reporting | Reserve Bank of India | As per applicable circular | Cyber incidents at regulated entities |
A single data breach event may require three separate notifications to three different authorities, each with its own reporting format and timeline. The six-hour CERT-In deadline is the most aggressive and will typically drive your incident response timeline.
Practical Approach
Build a single incident response workflow that satisfies the strictest deadline first (CERT-In at six hours), then cascades to the other reporting obligations. Maintain pre-drafted notification templates for each authority. Assign clear ownership: one individual or team must be responsible for triggering all three notifications from a single incident detection event.
Do not treat these as sequential obligations. A breach that is reported to CERT-In but not to the Data Protection Board is still a DPDP Act violation. Parallel reporting is the operational requirement.
Building DPDP Compliance into Your Fintech Stack
Compliance is an infrastructure problem, not a policy document problem. For fintech companies, the following components are non-negotiable.
Data Inventory for Payment Flows
Map every data element collected, processed, and stored across your payment and financial product flows. For each element, document:
- What personal data is collected (name, PAN, bank account, UPI ID, transaction history)
- Where it is stored (which database, which cloud region, which third-party processor)
- Why it is collected (the specific lawful basis: consent, statutory obligation, or legitimate use)
- How long it is retained (the specific retention period and the legal basis for that period)
- Who has access (internal teams, third-party processors, partner organisations)
Without this inventory, compliance with either the DPDP Act or RBI’s data localisation directive cannot be verified.
Consent Management for Financial Products
Your consent infrastructure must support:
- Purpose-specific consent capture for each data processing activity (underwriting, credit scoring, marketing, analytics)
- Withdrawal mechanisms that are as simple as the original consent flow
- Consent records with tamper-proof timestamps, linked to the specific notice version the Data Principal agreed to
- Integration with the Account Aggregator consent artefact where applicable, ensuring AA consent is tracked alongside DPDP consent
A single consent management layer that serves both regulatory requirements is more efficient than maintaining parallel systems. This is where a registered Consent Manager can provide infrastructure that is pre-built for the Indian regulatory environment.
Security Controls That Satisfy Both Regulators
RBI mandates specific security controls for payment data (encryption standards, access controls, audit trails). The DPDP Act requires Data Fiduciaries to implement “reasonable security safeguards” to prevent personal data breaches. The penalty for inadequate safeguards under the DPDP Act reaches Rs 250 crore.
The security controls that satisfy RBI’s requirements will, in most cases, satisfy the DPDP Act’s reasonable safeguards standard as well. Encryption at rest and in transit, role-based access controls, audit logging, vulnerability management, and incident response procedures serve both purposes.
The gap is typically in non-payment data. Fintech companies that apply rigorous security to payment data but leave marketing databases, analytics pipelines, or internal communication logs inadequately protected are exposed under the DPDP Act, even if their payment data security satisfies RBI.
Apply the same security standard to all personal data, not just regulated financial data.
Assess Your Compliance Position
The dual regulatory burden on fintech is not a future concern. RBI’s data localisation directive has been enforceable since 2018. The DPDP Act’s enforcement is on a defined timeline. Fintech companies that have not mapped the overlap between these regimes are carrying unquantified regulatory risk.
The first step is to understand where your current posture falls short. Run your free DPDP Gap Assessment to identify the specific areas where your fintech operation requires remediation. The assessment covers consent management, data storage practices, breach readiness, and Data Principal rights infrastructure.
For a complete view of DPDP obligations specific to the fintech sector, see our Fintech Industry Guide. To estimate your financial exposure, use the Penalty Calculator.