Fintech and Payments Under the DPDP Act: An Impact Study

Executive summary

Indian payments already treat data seriously. Payment data stays in India, merchants may not keep card numbers, non-bank operators report cyber incidents to the RBI within six hours, and UPI apps must offer a grievance channel.

The Digital Personal Data Protection Act, 2023 (the DPDP Act) asks a question these rules rarely ask: who answers to the individual for each use of her data. In one card or UPI payment, a merchant, an aggregator, a gateway, a network, two banks and an app may all handle it. Each must know whether it acts for itself or for someone else.

Headline impact rating: High. The three biggest changes are:

1. 1.Role mapping across the payment chain. Each participant must decide whether it is a data fiduciary or a data processor for each data set, and its notices, contracts and rights handling must follow from that decision.
2. 2.Transaction history needs its own ground. Using payment history for credit offers, marketing, investment nudges or partner campaigns needs a ground of its own. For most fintechs that means separate, withdrawable consent.
3. 3.A breach regime on top of the cyber regime. RBI and CERT-In six-hour reporting continues. The DPDP Rules add notice to every affected individual and a detailed report to the Data Protection Board within 72 hours, for any personal data breach, cyber or not.

The main obligations apply from 13 May 2027. Trayambic's article on digital lending apps covers the lending side of fintech; this study covers payments, wallets, UPI apps, neo-banks and wealth-tech.

Background

The businesses in scope

• Payment aggregators (PAs) onboard merchants and collect payments on their behalf, online, in person or across borders.
• Prepaid payment instrument (PPI) issuers run wallets and prepaid cards, from small minimum-detail wallets to full-KYC instruments.
• UPI third-party app providers (TPAPs) run consumer UPI apps through a partner payment service provider (PSP) bank.
• Neo-banks offer a banking front end on top of a licensed partner bank, which remains the regulated entity.
• Wealth-tech platforms distribute mutual funds, broke securities or give investment advice, usually under SEBI registration, and increasingly use account aggregators to pull financial data.

Who the data principals are

The DPDP Act calls the individual whose data is processed a data principal. The organisation that decides why and how data is processed is a data fiduciary; one that processes data on a fiduciary's behalf is a data processor.

Fintech data principals include payers and wallet holders, investors and their nominees, and also people fintechs tend to forget: sole proprietors and individual directors whose KYC is taken when a merchant is onboarded, payees named in transfers, and people whose phone numbers sit in a user's synced contact list.

What data flows where

The core data set is identity and KYC data, bank account and virtual payment address details, tokenised card references, transaction records, device identifiers, location and behavioural signals used for authentication and fraud scoring, and, for wealth-tech, holdings, income and risk profiles.

Data moves outward to partner banks, card networks, NPCI, KYC and video-KYC vendors, fraud-scoring providers, cloud hosts, messaging providers, customer support outsourcers and, through account aggregators, other financial institutions.

Legal framework

The DPDP Act and Rules

• Grounds (sections 4, 6, 7). Consent, or a legitimate use from a closed list. Section 7(a) covers data voluntarily provided for a specified purpose. There is no "legitimate interests" ground.
• Notice (section 5, Rule 3). An itemised notice with every consent request; for earlier consents, notice as soon as reasonably practicable (section 5(2)).
• Fiduciary duties (section 8). Responsibility for processors "irrespective of any agreement to the contrary"; processor contracts; security safeguards (Rule 6, logs kept a year); breach intimation (Rule 7); erasure when the purpose ends unless law requires retention.
• Children (section 9, Rule 10). Verifiable guardian consent under 18; no tracking, behavioural monitoring or targeted advertising.
• Significant Data Fiduciaries (section 10, Rule 13). A fiduciary the Centre designates for volume, sensitivity or risk (an SDF) needs an India-based Data Protection Officer (DPO), an independent data auditor and annual impact assessments.
• Rights (sections 11 to 14, Rule 14). Access includes the identities of fiduciaries and processors the data was shared with; grievances answered within 90 days.
• Cross-border (section 16, Rule 15). No country restricted under section 16(1); section 16(2) preserves stricter sector rules.
• Consent managers (section 6(7) to (9), Rule 4). Board-registered consent intermediaries, from 13 November 2026.

Sector instruments

• Payment and Settlement Systems Act, 2007. Section 22 bars a system provider from disclosing information from system participants except with consent, under the Act, on a court order or by statutory authority; section 26(4) punishes breach with up to six months' imprisonment, a fine, or both.
• Storage of Payment System Data, RBI circular, 6 April 2018. Issued under sections 10(2) and 18 of the PSS Act: all payment system data stored only in India. RBI's FAQs of 26 June 2019 permit processing abroad if the data is deleted there and returned within one business day or 24 hours, whichever is earlier. Covered data includes name, mobile number, email, Aadhaar and PAN, and the rule reaches vendors and gateways.
• RBI (Regulation of Payment Aggregators) Directions, 2025 (15 September 2025), repealing the 2020 guidelines. Para 9: PCI-DSS, a board-approved security policy, the 2018 storage rule and an annual audit by a CERT-In empanelled auditor. Para 13: merchant due diligence and FIU-India registration for non-bank PAs. Annex 1 para 2.1: merchants may not store card credentials.
• Card-on-file tokenisation, RBI circular, 7 September 2021. From 1 January 2022 only issuers and networks store card data; others keep only the last four digits and issuer name. Tokenisation needs explicit consent validated by an additional authentication factor.
• Master Directions on Prepaid Payment Instruments (27 August 2021, updated 30 September 2026). Para 6.3: transaction logs for at least ten years. Para 9.1: small PPIs on minimum details including an OTP-verified mobile. Para 15.7: cyber incidents reported immediately to the RBI and CERT-In. A draft replacement was issued for comment on 22 April 2026; the 2021 directions remain in force.
• RBI Master Directions on Cyber Resilience and Digital Payment Security Controls for non-bank PSOs (30 July 2024). Compliance from 1 April 2025 for large operators (including PAs), 2026 for medium and 2028 for small. Para 20: encryption and leak prevention. Para 22.4: unusual incidents to the RBI within six hours of detection; cyber incidents to CERT-In. Para 5: extend controls to gateways and vendors.
• Bank-side controls. The 2021 Digital Payment Security Controls Master Direction covered commercial banks, small finance banks, payments banks and credit card NBFCs; replacement directions for commercial banks and small finance banks issued on 31 July 2026. Neo-banks inherit these through their partner bank.
• RBI (Authentication mechanisms for digital payment transactions) Directions, 2025 (effective 1 April 2026). Two distinct factors (para 6(a)); risk checks may use location, behaviour and device attributes (para 8); issuers must adhere to the DPDP Act (para 9(3)).
• NPCI. TPAPs and PSP banks must store payments data only in India, give the RBI and NPCI access and offer in-app grievances; PSP banks must ensure TPAP systems are audited.
• RBI (NBFC – Account Aggregator) Directions, 2025. No financial data held by the aggregator (para 14(7)); a consent artefact naming purpose, recipients and expiry (para 17); revocation (para 20); users must be financial-sector regulated (para 8(12)).
• SEBI Cybersecurity and Cyber Resilience Framework (20 August 2024). Applies to brokers, portfolio managers, non-individual investment advisers and research analysts, among others; regulatory data kept within India.
• Other. PMLA section 12 (five-year records); the Reserve Bank – Integrated Ombudsman Scheme, 2026, covering non-bank PPI issuers since 1 July 2026; CERT-In's six-hour reporting and 180-day logs.

How the layers fit

Section 38(1) makes the DPDP Act additional to these instruments; section 38(2) makes it prevail in a conflict; section 16(2) keeps India-storage rules alive. In practice: storage from the RBI and NPCI, consent and rights from the DPDP Act, and the shortest reporting clock from whichever regime sets it.

Analysis

The Trayambic DPDP Impact Scorecard

Overall impact: High

Who is the fiduciary? Mapping the payment chain

No regulator has published a role map for the DPDP Act, so each business must reason it out. In Trayambic's view, the starting points are:

• The merchant is usually the fiduciary for its own customers' order and contact data.
• The payment aggregator is a fiduciary for the merchant onboarding data it collects to meet its own KYC duties, including sole proprietors' identity documents. For payer data it handles to complete payments, it acts largely for the merchant, but its independent fraud-monitoring and record-keeping duties make it a fiduciary for those purposes too.
• The UPI app is a fiduciary for its user relationship: profile, device, contacts and in-app behaviour. The PSP bank remains responsible to NPCI for the payment rails.
• The neo-bank is usually a fiduciary for its app, onboarding funnel and marketing, while the partner bank is the fiduciary for the account. Their contract must say who answers access, correction and erasure requests.
• The wealth-tech platform is a fiduciary for its investors' profiles and advice records, and a financial information user when it pulls data through an account aggregator.

Two errors are common. Labelling everyone a processor fails because a processor cannot use data for its own purposes, such as its own analytics. Labelling everyone a fiduciary multiplies notices and penalty exposure. The map should drive three documents: each party's notice, the section 8(2) contract, and the recipient list given in answer to section 11 requests.

Transaction history: what the payment does not license

Payment history is the most valuable data a fintech holds. It shows income, spending, savings habits and sometimes health or religious affiliation. Under the DPDP Act, its use for anything beyond executing the payment needs a ground.

Section 7(a) helps only so far. A user who enters a payee's UPI ID provides it for that payment. She has not provided her spending history for a credit score, an insurance offer or a merchant campaign. Those need consent that is specific and separable, and that she can withdraw without losing the payment service. The test of "unconditional" consent in section 6(1) makes it risky to make wallet or UPI access depend on accepting marketing.

Contact syncing deserves separate attention. Many apps upload a user's phone book to show which contacts are on the platform. The people in that phone book have not consented and have not provided their data. Apps should minimise this, process hashed numbers where possible and delete non-users' data promptly. RBI's digital lending rules already ban contact-list access for lending apps; payments apps should not assume they are in a safer position.

Account aggregators show the model the DPDP Act expects: a consent record naming purpose, recipient and expiry, and revocable at any time. Fintechs that already act as financial information users have a template for their own consents.

Breach: wider triggers, more audiences

A large non-bank PSP already reports unusual cyber incidents to the RBI within six hours under para 22.4 of the 2024 directions, and to CERT-In. A PPI issuer reports cyber incidents immediately under para 15.7 of the PPI directions.

From 13 May 2027, any personal data breach also requires notice without delay to every affected individual, an initial intimation to the Board and a detailed report within 72 hours. The trigger is any unauthorised processing, disclosure or loss of personal data, not only a cyber attack. A support agent screen-sharing a customer's KYC with the wrong caller, or a mis-configured analytics export, is enough.

Merge the playbooks into one decision tree, pre-approve notice templates, and make partners report fast enough to meet every clock.

Retention: ten years of logs, and what to delete

The PPI directions require a ten-year transaction log. PMLA requires five years of identity and transaction records. Section 8(7) of the DPDP Act allows retention where another law requires it, so these records stay.

What does not stay: abandoned-onboarding KYC, device fingerprints after closure, marketing segments, non-users' contacts and unneeded support recordings. Publish a schedule naming the law behind each period, and run deletion jobs, including at processors under section 8(7)(b).

Worked example: a payment aggregator with a foreign parent

A mid-size online payment aggregator, authorised by the RBI, belongs to a group headquartered outside India. It onboards several thousand merchants, many of them sole proprietors, and processes card, UPI and wallet payments.

The group runs a single fraud model on cloud servers outside India. Every transaction is sent abroad for scoring and the score comes back in seconds. The group also wants to use Indian merchants' sales data to sell them working-capital loans through a partner NBFC.

How the rules apply:

• Processing abroad is allowed, storage is not. Under the RBI's 2019 FAQs, the transaction data must be deleted abroad and returned within one business day or 24 hours. The PA should keep evidence that the deletion job runs, because its annual CERT-In empanelled audit will test storage compliance.
• The DPDP Act does not block the transfer today. No country is restricted under section 16(1). But section 16(2) keeps the RBI rule in force, and any requirement the Centre sets under Rule 15 would apply on top.
• The group entity is a processor for fraud scoring. It needs a section 8(2) contract limiting use to scoring, with security, deletion and breach-reporting terms. If the group uses Indian data to train models for other markets, it becomes a fiduciary for that purpose and needs its own ground.
• The loan offer needs consent. Sole proprietors are individuals, so their sales data is personal data. Sharing it with the NBFC for loan offers needs specific consent with an itemised notice, separate from the merchant agreement.
• A breach at the group cloud is the PA's breach. The PA must notify the RBI and CERT-In within six hours, and from May 2027 also the Board and every affected merchant and payer.

Compliance framework

Checklist

Roadmap to 13 May 2027

Now to December 2026. Appoint a DPO. Complete the inventory and role map. Decide on consent manager integration after 13 November 2026. Review contact syncing and offshore processing.

January to March 2027. Rebuild consent journeys and notices. Add guardian controls for teen products. Merge breach playbooks and run a tabletop exercise that involves a partner bank or gateway.

April to May 2027. Sign amended contracts. Launch notices to existing users. Switch on rights workflows and the retention schedule.

Ongoing. Track the final PPI Master Direction, any SDF designations and any Rule 15 requirements on transfers abroad. Re-test breach plans every six months.

Recommendations

1. 1.Write the role map before anything else. Every notice, contract and rights answer depends on it.
2. 2.Decouple the payment from the pitch. Never make a payment, wallet or UPI service depend on accepting marketing or data sharing.
3. 3.Treat merchants as people where they are people. Sole proprietors' KYC and sales data is personal data.
4. 4.Fix contact syncing now. It is the processing least likely to have a lawful ground.
5. 5.Put partners on your breach clock. Contracts should require partner reporting within hours, not days.
6. 6.Prove deletion, not just policy. Auditors and the Board will want logs showing that offshore copies, abandoned onboarding data and marketing segments were actually erased.
7. 7.Use the account aggregator model for your own consents. Purpose, recipient and expiry, revocable at any time.

Key takeaways

• Fintech's DPDP impact is High because many parties touch each payment, and each must decide whether it is a fiduciary or a processor for each data set.
• Using transaction history for credit, marketing or partner offers needs separate, withdrawable consent; section 7(a) covers executing the payment, not monetising it.
• RBI and NPCI India-storage rules continue under section 16(2); processing abroad must still return data within one business day or 24 hours.
• Breaches now need notice to every affected individual and a 72-hour Board report on top of six-hour RBI and CERT-In reporting.
• Ten-year PPI logs and PMLA records stay, but abandoned onboarding data, non-users' contacts and marketing segments must be deleted.