Fintech products sit directly on top of the data categories the DPDP Act is most concerned with. A savings app, a lending platform, a payments gateway, or a wealth management tool all collect layers of identity, financial, and behavioural data the moment a user signs up -long before a single transaction happens. Recognising all of it as personal data under the Act, rather than treating compliance as a checkbox for marketing cookies, is where a fintech DPDP programme actually starts -and it has to be built alongside RBI's existing rulebook, not instead of it.
1. The Data Fintech Holds
Every fintech onboarding flow collects identity data (PAN, masked Aadhaar reference, name, address, photograph), financial data (bank account and card details, income declarations, credit score and repayment history, loan and investment holdings), transaction data (amounts, counterparties, timestamps, merchant categories), and behavioural or device data (app usage patterns, device fingerprints, geolocation used for fraud scoring). Each of these is personal data on its own; combined into a single customer risk profile, as most underwriting and fraud engines do, they become a far more sensitive dataset than any individual field suggests. For the baseline definition the rest of this article relies on, see our guide to what counts as personal data under DPDP.
- Identity data -PAN, masked Aadhaar reference, name, address, photograph, signature
- Financial data -account and card details, income declarations, credit score, repayment history, holdings
- Transaction data -amounts, counterparties, timestamps, merchant category codes
- Behavioural and device data -app usage, device fingerprint, geolocation used in fraud and risk scoring
Personal data under DPDP is any data about an individual who is identifiable by or in relation to it. Financial identifiers, credit history and transaction metadata all qualify individually, and become more sensitive still once merged into one customer profile -exactly what most fintech risk-scoring engines are built to do.
2. Consent for Credit & KYC Data
Consent under DPDP must be free, specific, informed, unconditional and unambiguous, given through clear affirmative action, and itemised against the purpose it supports. For fintech, that standard collides with two habits the industry inherited from a pre-DPDP era: bundling every possible use into a single onboarding checkbox, and treating a KYC-time consent as blanket authorisation for every future credit pull. Neither survives scrutiny under the Act. For the mechanics of a compliant consent flow, see our piece on consent under the DPDP Act.
Credit and KYC data carry two consent obligations that are easy to under-build. First, each purpose needs its own itemised notice -assessing loan eligibility is not the same purpose as monitoring an account for cross-sell, even when both use the same bureau pull. Second, consent must be as easy to withdraw as it was to give, and withdrawal has to actually stop new bureau pulls and marketing-driven scoring, not just hide a toggle in a settings screen.
The Account Aggregator model is a useful template
RBI's Account Aggregator framework already requires participating fintechs to build granular, purpose-bound, time-bound and revocable consent artefacts before a single byte of financial data moves between a Financial Information Provider and a Financial Information User. Teams already living under that consent architecture should treat it as a design pattern for DPDP consent generally, not a separate obligation.
- Consent tied to a specific purpose and specific data types
- Consent has a defined validity period, not an indefinite one
- Consent is revocable by the data principal at any time
- Each consent artefact is logged and auditable
3. Bureaus, KYC Vendors & Sub-Processors
A typical fintech onboarding and underwriting flow routes personal data through several external parties in seconds: an eKYC or video-KYC API, a credit information company for a bureau pull, a fraud and risk-scoring engine, and often a core-banking-as-a-service partner underneath the product. Each of these is, in DPDP terms, either a Data Processor acting on your instructions or -in some data flows -a Data Fiduciary in its own right. Getting the classification right, per data flow rather than per vendor, determines whose contractual obligations apply where. For the general Fiduciary/Processor distinction, see our explainer on data principals, fiduciaries and processors.
| Vendor Type | Typical Role | Data Shared |
|---|---|---|
| Credit information companies | Processor (pull on your instruction) or independent Fiduciary (own database) | PAN, credit history, repayment behaviour |
| eKYC / video-KYC providers | Processor | Identity documents, photo match, address |
| Fraud & risk-scoring APIs | Processor | Device fingerprint, transaction history, behavioural signals |
| Payment gateway / switch | Processor | Card/account details, transaction metadata |
| Core banking / BaaS platform | Processor (sometimes joint Fiduciary) | Full account and transaction ledger |
| Collections / recovery agencies | Processor | Contact details, outstanding balance, repayment status |
Every vendor in that table needs a Data Processing Agreement stating its role, the categories of data in scope, the security standards it must maintain, whether it may appoint sub-processors and your approval rights over that, how it notifies you of a breach, and what happens to the data at the end of the relationship. Bureau and KYC contracts in particular are often legacy agreements written for a pre-DPDP world -audit them first, since they are the highest-volume pipes carrying your most sensitive data outward.
4. DPDP, RBI Localisation & Retention Conflicts
Fintechs answer to two regimes on the same data at once. DPDP governs consent, data principal rights and breach obligations, and leaves cross-border transfer open by default until the Central Government notifies a restricted list under Section 16 -we cover that mechanism in our piece on cross-border transfer under DPDP. Layered on top, RBI's payment-data localisation direction requires that data relating to payment systems be stored only in India, regardless of what DPDP eventually permits for other categories. Where the two overlap, the more stringent applicable rule controls -localisation for payment data is not optional just because a DPDP restricted list has not been published.
Retention creates the mirror-image conflict at the other end of the data lifecycle. A data principal's erasure request under DPDP is not absolute: fiduciaries may -and for KYC and transaction records tied to RBI and PMLA obligations, generally must -continue holding the data for whatever period the sectoral retention mandate requires, even after the account relationship ends. We walk through how erasure requests are actually handled, including this kind of statutory override, in our piece on DPDP erasure and deletion requests.
A retention schedule or transfer map that only satisfies DPDP will fail an RBI examination, and one that only satisfies RBI will not hold up against a data principal's erasure request. Build a single data lifecycle policy that documents both obligations per data category, and resolves the conflict in writing rather than leaving it to whichever team gets asked first.
5. Why Fintechs Often Become SDFs
Section 10 of the DPDP Act lets the Central Government designate any Data Fiduciary, or class of Data Fiduciary, as a Significant Data Fiduciary based on factors including the volume and sensitivity of personal data processed, risk of harm to data principals, potential impact on the sovereignty and integrity of India, and risk to electoral democracy. Fintech maps onto nearly every one of those factors at once: high user volumes, financial and KYC data among the most sensitive categories processed at consumer scale, and aggregate transaction visibility that carries systemic-risk implications if compromised. For the full obligations that come with designation, see our guide to Significant Data Fiduciary status.
The thresholds for designation have not been fully notified, which is exactly why fintechs should not wait for a notification to start preparing. SDF status adds a Data Protection Officer based in India, an independent data auditor, periodic data protection impact assessments, and additional restrictions on data transfer -obligations that take months to stand up properly, not weeks. Treat SDF readiness as a parallel workstream to core DPDP compliance rather than a problem for later.
6. Breach & Fraud Data
Section 8 of the DPDP Act obliges every Data Fiduciary to take reasonable security safeguards to prevent personal data breaches, and to notify both the Data Protection Board and affected data principals within the timelines set under the DPDP Rules. For fintech, breach exposure concentrates in exactly the systems covered earlier -bureau integrations, KYC vendors, payment gateways and fraud-scoring engines -because a compromise anywhere in that chain typically exposes financial identifiers and transaction history together, the combination attackers value most. Our piece on breach notification under DPDP covers the notification workflow in full.
Fraud and risk-scoring systems deserve a specific note: they process large volumes of behavioural and transaction data continuously, often without a fresh consent event for every scoring run. Document the lawful basis for that processing explicitly -whether it rests on the consent already captured for the underlying account relationship or a narrower legitimate use -rather than assuming fraud prevention is automatically exempt from DPDP's consent and purpose-limitation requirements.
7. Compliance Checklist
Where to start
- Map every data flow that touches a credit bureau, KYC vendor, payment gateway or BaaS partner, and classify each as Processor or Fiduciary
- Rebuild consent notices as itemised, purpose-specific artefacts modelled on the Account Aggregator pattern, not one onboarding checkbox
- Audit and refresh Data Processing Agreements with bureaus and KYC vendors, most of which predate DPDP
- Overlay your DPDP data map with RBI localisation and PMLA/KYC retention obligations, and resolve conflicts in a single documented policy
- Run an SDF readiness assessment even before designation thresholds are notified
- Build and test a breach notification runbook naming who notifies the Board, within what timeline, and who notifies affected data principals
Fintech does not get a lighter version of DPDP because it already answers to RBI -it gets a harder one, because two regulators are now reading the same data map. The programmes that hold up are the ones that treat DPDP consent, RBI localisation and PMLA retention as one connected data lifecycle policy, not three separate compliance projects competing for the same engineering time.
Need a DPDP programme built for two regulators?
SecComply designs consent architecture for credit and KYC data, audits your bureau and KYC vendor contracts, reconciles RBI localisation and retention rules with DPDP, and builds your SDF readiness plan before designation lands.
Book a fintech compliance review →FAQ
The DPDP Act does not create an explicit special category for financial data the way GDPR defines special categories of sensitive data. That does not make it low-risk -financial identifiers, credit history and transaction data are highly sensitive personal data in practice, they weigh heavily in Significant Data Fiduciary designation, and RBI's own guidance expects fiduciaries to apply heightened safeguards to it regardless of what DPDP labels it.
Both apply at the same time, and neither displaces the other. DPDP governs consent, data principal rights, cross-border transfer and breach notification; RBI's localisation direction separately requires payment system data to be stored in India. Where the two overlap, the more stringent applicable requirement controls -satisfying DPDP does not excuse you from RBI's localisation mandate, and vice versa.
Often yes, for a defined period. Erasure rights under DPDP are not absolute -fiduciaries may retain data to the extent necessary to comply with a legal obligation, and RBI/PMLA-driven KYC and transaction record retention requirements are exactly that kind of obligation. Inform the data principal that retention continues for the mandated period and erase the data once that obligation lapses.
Usually, when the bureau pulls or returns a credit report on your instruction and for your stated purpose -that makes them a Data Processor. Where a bureau independently determines the purpose and means of processing for its own database, it may itself be acting as a Data Fiduciary for that processing. The classification should be documented per data flow and reflected in the contract either way.
It depends on a Central Government designation under Section 10, based on factors like the volume and sensitivity of personal data you process, risk to data principals, and potential impact on sovereignty and electoral integrity. The specific thresholds have not been fully notified yet. Fintechs processing financial and KYC data at scale should assess their exposure and prepare -DPO appointment, DPIA readiness, independent audit -well before a designation is announced.