DPDP Act for Fintech and Payments Companies: A Compliance Guide
TL;DR
Fintech and payments companies face the DPDP Act on top of RBI rules, often inside partnerships where it is unclear who the Data Fiduciary is. Settle roles first, partnership by partnership. Then fix the areas where fintech is most exposed: app permissions and third-party SDKs, consent for cross-selling and credit data, account aggregator flows, localisation, and breach response. Large payment and lending platforms should prepare as likely Significant Data Fiduciaries.
Who this is for: founders, CTOs, product and compliance leaders at fintech, lending, payments, wealth and insurtech companies.
Fintech runs on personal data. Onboarding needs identity and KYC data, underwriting needs income and credit data, fraud prevention needs device and behavioural signals, and growth needs marketing and attribution data. Most of it flows through partners: banks, NBFCs, payment networks, bureaus, account aggregators and dozens of software vendors.
The DPDP Act does not replace the RBI rules that already govern fintech. It adds a layer on top of them: notices, consent, individual rights, retention limits and breach reporting to the Data Protection Board. This guide covers where that layer bites hardest for fintech. If you lend or partner with lenders, also read our guide to the DPDP Act for banks and NBFCs. For the general law, start with The DPDP Act, Explained.
Step one: settle who the Data Fiduciary is
Fintech business models make roles genuinely difficult. Under the Act, the Data Fiduciary decides the purpose and means of processing and carries the obligations. A Data Processor acts on someone else's instructions under a contract (Section 8(2)).
| Arrangement | Typical position |
| A fintech app serving its own customers | The fintech is the fiduciary |
| A lending service provider sourcing borrowers for a regulated lender | The lender is usually the fiduciary for the loan; the LSP is often a processor for that activity, but may be a fiduciary for its own marketing |
| Banking-as-a-service, where a fintech builds the front end on a bank's licence | Often split: the bank is fiduciary for the account, the fintech for its own app analytics and marketing |
| A payment aggregator processing card payments for merchants | Often a processor for the merchant's transaction data, and a fiduciary for its own merchant onboarding and risk data |
| An account aggregator | A consent-routing intermediary that cannot read the data it transfers; the receiving financial information user is a fiduciary for its own use |
These are typical patterns, not rules. Map roles activity by activity in your Record of Processing Activities, and write them into partnership contracts. Unclear roles lead to the most common fintech failure: each party assuming the other is responsible for notices, consent and rights.
App permissions and data minimisation
RBI's digital lending rules already restrict lending apps' access to phone resources such as contacts, media and call logs, and require need-based collection with explicit consent. The DPDP Act extends the same discipline to every fintech app:
- Necessity. Section 6(1) limits consent to the data necessary for the specified purpose. Access to a contact list "for better underwriting" will rarely meet that test.
- Itemised notice. Rule 3 requires an itemised description of each data item and its purpose, separately from your terms.
- Time-limited retention. Location or device data collected for onboarding or fraud checks must be erased once that purpose ends (Section 8(7)).
Audit every permission your app requests, and remove any you cannot justify against a specific purpose.
Third-party SDKs: the hidden processors
Analytics, attribution, crash reporting, customer messaging and advertising SDKs often collect device identifiers, usage data and sometimes more. If an SDK collects personal data from your users, you are responsible for that processing. Each one needs:
- a lawful basis, which for advertising and attribution will usually be consent
- disclosure in your notice
- a contract that meets Section 8(2) and the Rule 6 safeguards
- a way to stop collection when a user withdraws consent
Many fintech apps have never inventoried their SDKs. It is one of the fastest ways to reduce DPDP exposure. Our vendor risk guide covers how to tier and contract them.
Consent for cross-selling, credit data and partners
Fintechs frequently use data collected for one product to offer another: a payments app offering loans, or a lending app offering insurance. Under the DPDP Act, data voluntarily provided for one purpose (Section 7(a)) does not cover a new one. New purposes need valid consent, which must be specific, unbundled and as easy to withdraw as to give. See what makes consent valid under DPDP.
The same applies to sharing data with partners. Lead-sharing with lenders, insurers or brokers needs a clear lawful basis, an itemised notice naming the categories of recipients, and a record you can produce under Section 6(10).
Account aggregators
India's account aggregator framework, regulated by the RBI, already works on a consent-artefact model: individuals approve specific data, for a specific purpose and duration, before financial information flows from a provider to a user. It is one of the closest existing models to DPDP-standard consent.
But the framework governs the data transfer, not everything that happens afterwards. If you receive data as a financial information user, you are a Data Fiduciary for your own processing. Your notice, purpose limitation, retention and rights handling must meet the DPDP Act independently.
Localisation and cross-border transfers
Section 16 of the DPDP Act permits transfers outside India unless the government restricts a specific country. But Section 16(2) preserves stricter sector laws. RBI's 2018 direction on storage of payment system data, which requires that data to be stored only in India, therefore continues to apply, as do localisation requirements in the digital lending rules. Check every vendor's hosting and support locations, including those of SDKs.
Fraud prevention and collections
Fraud prevention is essential to fintech, and the Act recognises it: Section 17(1)(c) exempts processing for preventing, detecting or investigating offences from most obligations. But the exemption is partial. Security safeguards still apply, and the exemption covers genuine fraud processing, not marketing or profiling that happens to use the same data.
Collections practices deserve particular care. Using borrowers' contacts or social data to pressure repayment is already prohibited by RBI, and it would also fail the DPDP Act's necessity and purpose-limitation tests.
Minors
Some fintech products, such as prepaid cards, savings apps and investment education, are aimed at users under 18. Under Section 9, processing a child's data requires verifiable parental consent, and tracking, behavioural monitoring and targeted advertising directed at children are prohibited, with penalties up to ₹200 crore.
Breach response
A security incident at a fintech can trigger reporting to CERT-In within 6 hours, to the RBI or partner banks under their requirements, and under the DPDP Act to every affected customer and the Data Protection Board, with a detailed report within 72 hours. There is no materiality threshold. Our Rule 7 breach notification playbook sets out each step.
Significant Data Fiduciary designation
Large payment apps, lending platforms and wealth platforms process high volumes of sensitive financial data, which are the factors Section 10 uses to designate Significant Data Fiduciaries. SDFs must appoint a DPO based in India, an independent data auditor, and run an annual DPIA and audit (Rule 13), and must exercise due diligence over algorithmic software. Fintechs using automated credit decisioning should expect that to receive attention.
A fintech DPDP checklist
A fintech DPDP checklist
- Roles mapped per activity and written into every partnership contract
- App permissions audited and reduced to what each purpose needs
- Every SDK inventoried, justified, disclosed and contracted
- Itemised notices for onboarding, lending, payments and marketing journeys
- Unbundled consent for cross-selling and partner sharing
- Account aggregator data governed by your own purpose and retention rules
- Hosting locations checked against RBI localisation and Section 16
- Retention schedule reconciling RBI, PMLA and DPDP requirements
- Breach plan covering CERT-In, RBI and Rule 7 timelines
- SDF readiness assessed
How ConsentifyAI helps fintech teams
ConsentifyAI is built for fast-moving product teams. Consent is captured per purpose through APIs and SDKs in onboarding and in-app journeys, with versioned notices in the languages your users read. Withdrawals are pushed to downstream systems and partners as events, and the ROPA module records roles, SDKs, vendors and transfers per activity. Every consent and request is written to a tamper-evident audit trail you can share with partner banks and regulators.
Sources & references
- DPDP Act, 2023 — Section 6, 7(a)
- DPDP Act, 2023 — Section 8(1), 8(2), 8(6), 8(7)
- DPDP Act, 2023 — Section 9
- DPDP Act, 2023 — Section 10
- DPDP Act, 2023 — Section 16, 17
- DPDP Rules, 2025 — Rules 3, 6, 7, 8, 13
- RBI — Digital Lending Directions; Storage of Payment System Data (2018); NBFC-Account Aggregator Directions
Frequently asked questions
Does the DPDP Act apply to fintech startups?
Yes. There is no size threshold. A startup exemption is possible under Section 17(3), but none had been notified at the time of writing.
Is a fintech a Data Fiduciary or a Data Processor in a bank partnership?
It depends on who decides the purpose and means of processing. A fintech that builds a product for its own customers is usually a fiduciary. One that only processes data on a bank's instructions is a processor. Many arrangements involve both, activity by activity.
Do third-party SDKs in our app create DPDP risk?
Yes. If an analytics, attribution or advertising SDK collects personal data, you are responsible for that processing and need a lawful basis, a notice and a valid contract.
Does the account aggregator framework satisfy DPDP consent?
The account aggregator consent artefact is a strong model, but each financial information user still needs its own DPDP-compliant notice and purpose limitation for how it uses the data it receives.
Does the DPDP Act change payment data localisation?
No. Section 16(2) preserves sector laws that impose stricter transfer restrictions, so RBI's payment data storage requirements continue to apply.
Related reading
DPDP Act for Banks and NBFCs: A Compliance Guide
Banks and NBFCs face the DPDP Act on top of RBI, PMLA and credit information rules, not instead of them. Retention required by law survives the DPDP erasure duty (Section 8(7)), but everything else must be erased when its purpose ends. Cross-selling, bureau sharing and app permissions need clear notices and, where consent is the basis, unbundled consent. Large lenders should prepare as likely Significant Data Fiduciaries. Being RBI-compliant does not make a lender DPDP-compliant.
ReadValid Consent Under DPDP: Why Your Checkbox Isn't Enough
Under Section 6 of the DPDP Act, consent is valid only if it is free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and limited to the data necessary for the stated purpose. It must come with a standalone, itemised notice. It must be as easy to withdraw as to give. And the business, not the customer, must be able to prove all of this (Section 6(10)). A checkbox captures a click. It does not, by itself, meet any of these tests.
ReadThird-Party Vendor Risk Under DPDP: Your Vendor's Breach Is Your Breach
Under Section 8(1) of the DPDP Act, a Data Fiduciary is responsible for compliance even when a vendor does the processing. Processors may only be engaged under a valid contract (Section 8(2)), and Rule 6 requires security safeguards to be written into it. Withdrawals, erasure and breaches all have to flow through your vendors on time. Effective vendor risk management means knowing every vendor, tiering them by risk, contracting properly, and monitoring continuously, not just at onboarding.
Read