DPDP for fintech, payments and investment apps

Fintech apps sit on a phone that knows everything about a person: their contacts, messages, location, photos and the other apps they use. On top of that, they handle the most sensitive records a person has: payments, balances, credit, investments and KYC. A UPI app, a wallet or a trading app sees a person’s financial life in real time, and often shares it with a sponsor bank, an NBFC partner, an exchange, an insurer and a dozen SDKs.

The risk sits in three places: app permissions that read far more than the service needs, unclear roles between the app and the regulated partner, and data from one product quietly feeding another (payments data driving loan offers, trading data driving insurance pitches). This guide applies the Data Fiduciary playbook to fintech, payments and investment platforms.

Are you a Data Fiduciary, a processor, or both?

• Payment aggregator or gateway: you are a Data Fiduciary for your merchants’ contacts and for the customer data you use for your own purposes (fraud models, risk scoring, your own consumer products). For processing payments on a merchant’s behalf, you often act more like a processor, but RBI places direct duties on you. Write the split into your merchant terms.
• UPI third-party app (TPAP): you are a Data Fiduciary for your app users, their app activity and their device data. The sponsor PSP bank and NPCI have their own roles in the transaction. Treat the transaction data you see as held for the payment only, unless the user separately agrees to more.
• Wallet or PPI issuer: you are the Data Fiduciary for wallet holders. Your KYC vendor, cloud host and messaging providers are processors.
• BNPL or lending app working with a bank or NBFC: the regulated lender is the fiduciary for the loan; you are usually its loan service provider and processor. Where you use the same data for your own app, marketing or other lenders, you are a fiduciary for that use. See banks, NBFCs and lenders.
• Neo-bank: the partner bank holds the account and is the fiduciary for banking purposes. You are typically a fiduciary for your app, budgeting features and marketing, and a processor for onboarding and servicing on the bank’s behalf.
• Broker, wealthtech or investment platform: you are the fiduciary for clients. KYC registration agencies, depositories, exchanges and AMCs are separate fiduciaries you disclose to. A robo-advisor using a third-party engine makes the engine provider a processor.
• Insurtech distributor (broker, web aggregator, corporate agent): you are a fiduciary for leads and customers you collect; insurers are separate fiduciaries once data is passed to them. See insurance.
• API and infrastructure providers (KYC APIs, payment orchestration, ledgers): usually processors for your clients. See SaaS, IT and BPO processors.

The data you hold

Data category	Where it usually lives	Typical purpose	Sensitivity	Typical retention
Name, mobile, email, device binding	User DB, auth service	Account, login, device binding	Medium	While the account is active, then legal minimums
KYC (PAN, masked Aadhaar, photo, video KYC, address)	KYC vendor, KYC registration agency, user DB	KYC under RBI, SEBI or PMLA rules	High	As the KYC and PMLA rules require
UPI IDs, linked bank accounts, VPA handles	TPAP backend, PSP bank	Payments	High	As payment system rules require
Payment transactions (payer, payee, amount, merchant, time)	Switch, ledger, data warehouse	Payment, reconciliation, disputes	High (reveals habits, health, religion)	As RBI and PMLA rules require; stored in India
Card data	Card network token vault, issuer	Card payments	High	Never store full card data; use tokens
Wallet balances and PPI ledgers	Wallet ledger	Stored value	High	Until balance is used or refunded, plus legal minimums
Credit data (bureau reports, AA data, bank statements)	Lending partner, underwriting engine	Credit decision	High	Only as the lender’s purpose and consent allow
Device data: SMS, contacts, call logs, location, installed apps	App SDKs, risk engine	Fraud, credit models (often unnecessary)	High	Minimise; most should never be collected
Trading and holdings data, demat account, bank mandates	Back office, depository, exchange systems	Trades, settlement, statements	High	As SEBI and exchange rules require
Risk profiles and suitability answers	Advisory engine, CRM	Investment advice, suitability	Medium to high	Advisory relationship plus legal minimums
Insurance leads and health declarations	Distribution app, insurer APIs	Quotes and policy purchase	High (health)	Until the quote or policy purpose ends
Merchant owner KYC and settlement accounts	Merchant onboarding system	Merchant onboarding, settlement	High	Merchant relationship plus legal minimums
Support chats, call recordings, dispute evidence	Helpdesk, telephony vendor	Support, disputes, chargebacks	Medium to high	Until the dispute closes, plus legal minimums
Marketing, referral and rewards data	CRM, campaign tools, attribution SDKs	Offers, cashback, referrals	Medium	Until consent is withdrawn

Risk hotspots

1. Unnecessary permissions, the section 6(1) test. The Act’s own illustration is a telemedicine app that asks for consent to its service and to the phone’s contact list. Because the contact list is not necessary for the service, the consent is limited to the service. Apply the same test to every finance app: a UPI app does not need the contact list to send money to a scanned QR code; a wallet does not need call logs. Failure: consent to unnecessary access is not valid consent, so the processing has no ground. Control: a permission register mapping each permission to a feature, runtime prompts only when the feature is used, and a working app when the user says no.
2. SMS reading and contact lists in lending apps. Lending apps have read SMS to estimate income and scraped contacts to pressure borrowers. RBI’s digital lending rules restrict this, and DPDP makes it a consent and purpose problem as well. Failure: third-party contacts’ data processed with no ground at all, and harassment of people who never dealt with you. Control: no contacts or call log access, no bulk SMS reading, and AA data or bank statements uploaded by the user instead.
3. Blurred roles with the regulated partner. The app collects data; the bank, NBFC or AMC is the regulated entity. Failure: nobody gives the notice, both sides use the data for their own marketing, and rights requests bounce between them. Control: a written role split per purpose, one combined notice that names both, and a shared rights and breach process.
4. Payment data turned into profiling. Transaction data reveals pharmacy visits, places of worship, alcohol purchases and income. Failure: using it for credit offers, ad targeting or sale to partners without consent. Control: consent for each secondary use, aggregation or pseudonymisation for analytics, and no transaction-level data in marketing tools.
5. SDKs and analytics. Attribution, crash reporting, session replay and fraud SDKs can capture screens with balances, UPI IDs or OTPs. Failure: disclosure to third parties without notice or consent, and possible storage outside India. Control: an SDK register, no session replay on payment, KYC or portfolio screens, field-level masking, and processor contracts for each SDK vendor.
6. Card and payment data storage. Card-on-file data must be tokenised and payment system data stored in India. Failure: full card numbers in logs or a support tool, or payment data mirrored to a foreign analytics tool. Control: token-only storage, log scrubbing, and a data residency check for each vendor.
7. Credit offers at checkout and BNPL. Merchants and apps pre-qualify users silently by sharing data with lenders. Failure: disclosure to another fiduciary without the user asking. Control: the lender’s consent screen is shown when the user asks for credit; nothing is shared before that.
8. Account takeover and fraud. SIM swaps, device binding bypasses and social engineering lead to drained wallets and exposed data. Control: device binding, step-up checks on contact and device changes, rate limits, and the breach run-book.
9. Broker and advisory data. Holdings, trades and risk profiles are passed to research, insurance or lending partners. Control: separate consent for each partner and product line, and nothing shared as a condition of opening a trading account.
10. Merchant data at payment aggregators. Small merchants are individuals or proprietorships, so their KYC and bank details are personal data. Control: the same notice, retention and rights duties as for consumers.

Legal basis, purpose by purpose

Purpose	Basis	Notes
Account creation, login, device binding	7(a), or consent at sign-up	Keep the data set minimal.
KYC for a wallet, account, trading account or loan	Consent, or 7(a) where the user applies for the product	Give the notice before or with the request, as the Act’s section 5 illustration shows for video KYC.
Processing a payment, UPI transfer or trade	7(a)	Transactional messages only; no promotions without consent.
Card tokenisation and payment data storage	7(a), with RBI rules on how data is stored	Store payment data in India (section 16(2) keeps stricter rules in force).
Fraud and AML monitoring, reports to FIU-IND	17(1)(c); 7(d) for disclosures to the State	Do not reuse fraud signals for marketing.
Credit decisions for a loan the user applied for	Consent, collected by or for the regulated lender	Name the lender. Only data the decision needs.
Reading SMS, contacts or call logs	Consent, and only if necessary for a feature the user asked for	Section 6(1): consent beyond what the purpose needs is invalid. Most finance apps should not collect these.
Investment advice and suitability	7(a)	Keep the advice records the regulator requires.
Retaining KYC, transaction and trade records	Retention required by law (section 8(7))	Stop all other use of the retained records.
Responding to regulators, courts and tax authorities	7(d), 7(e)	Keep a disclosure log. 17(1)(b) covers the regulator or court’s own processing, not yours.
Promotional push, SMS, WhatsApp and email	Consent, per channel	Also follow TRAI’s TCCCPR.
Cross-selling loans, insurance or investments	Consent, per product line and partner	Never a condition of the core service.
Personalised offers based on transaction data	Consent	The highest-risk secondary use.
Referral programmes	Consent of the referrer; a notice to the referred person when you first contact them	Do not upload the referrer’s contact list.
Analytics for running the app (aggregate)	7(a) if strictly necessary, otherwise consent	Prefer aggregated, pseudonymous analytics.

Notices and consent: getting the screens right

Channel	Do	Don’t
App install and onboarding	Show a short notice listing the data and purposes; ask for each OS permission only when the feature needs it, with a one-line reason.	Ask for contacts, SMS, call logs or storage at first launch.
KYC and video KYC	Show the notice before the camera or document upload opens. Prefer DigiLocker or offline e-KYC.	Collect full Aadhaar images when masked Aadhaar or offline e-KYC would do.
Payment and checkout screens	Keep the payment flow free of consent asks; ask for marketing consent afterwards.	Bundle “offers from partners” into the payment confirmation.
Credit and BNPL offers	Show the lender’s notice and consent when the user taps to apply.	Share data with lenders to pre-approve users who never asked.
Web and merchant dashboards	Itemise merchant owner data and its use; load non-essential tags only after consent.	Fire ad pixels on payment pages.
Call centre and support chat	Read a short notice before recording; verify identity through the app; never ask for OTPs or PINs.	Use support transcripts to train models without a ground.
WhatsApp and SMS	Record the opt-in source and time; separate transaction alerts from promotions; put “STOP” in every promotion.	Message people from purchased lists or referral uploads.
Field agents and merchant onboarding	Use your own app so the merchant sees your notice and consents on their own phone.	Let agents collect KYC on personal phones.
Existing users	Send a section 5(2) notice in-app or by email with a link to review and change choices.	Assume old blanket consent covers new purposes.

Each notice must stand on its own, itemise the data and purposes, and give the link and other means to withdraw consent, exercise rights and complain to the Board (rule 3). Users must be able to read it in English or any of the 22 Eighth Schedule languages. Start with Hindi and the languages of your largest user regions, and offer the rest on request.

Other laws you must line up with

• Payment and Settlement Systems Act 2007 and RBI directions on payment aggregators and gateways: these set merchant onboarding, data storage and security duties. They overlap with DPDP security and processor duties.
• RBI card-on-file tokenisation rules: merchants and aggregators may not store full card data. This is a stricter rule that sits alongside DPDP.
• RBI storage of payment system data: payment data must be stored in India. Section 16(2) keeps this in force whatever the general DPDP transfer rules say.
• RBI master direction on prepaid payment instruments: KYC levels, wallet limits and record-keeping for PPI issuers.
• NPCI UPI rules for TPAPs and PSP banks: limits on data sharing, storage and use of UPI data by apps. Confirm the current requirement with counsel.
• RBI digital lending rules: restrictions on app access to phone resources, disclosure of LSPs and lenders, and duties on data storage and sharing. These match the section 6(1) test closely. Confirm the current requirement with counsel.
• RBI KYC Master Direction and PMLA 2002: what identity data you must collect, keep and report. They override erasure requests for those records only.
• SEBI regulations for stock brokers, investment advisers, research analysts and KYC registration agencies, and SEBI cyber security frameworks: client data, record-keeping and incident reporting duties. Confirm the current requirement with counsel.
• IRDAI regulations on intermediaries and web aggregators: apply to insurtech distribution. See insurance.
• Aadhaar Act 2016: limits on Aadhaar authentication and storage of Aadhaar numbers.
• IT Act 2000 and CERT-In Directions 2022: short incident reporting timelines and log retention in India. Confirm the current requirement with counsel.
• Consumer Protection Act 2019 and the guidelines on dark patterns: pre-ticked boxes, drip pricing and forced action can breach both consumer law and DPDP section 6.
• TRAI TCCCPR: consent and registration for commercial SMS and calls.
• Income-tax Act and GST: record-keeping that overrides erasure for those records only.

Retention and erasure

1. Section 8(7): erase personal data when consent is withdrawn or the purpose is over, whichever is earlier, unless a law requires you to keep it. A closed wallet or trading account still has KYC and transaction records you must keep; it does not need its marketing profile, device data or referral history.
2. Rule 8(3) minimum: keep personal data, associated traffic data and processing logs for at least one year from the date of processing, then erase them unless another law needs longer. Payment and securities rules often do.
3. Legal holds: chargebacks, disputes, fraud investigations and regulator inquiries put a hold on the relevant records. Record the hold, the reason and a review date.
4. Device data: if you collected SMS, contacts or location in the past, erase what is no longer necessary now, not at account closure.
5. The Third Schedule three-year rule applies if your platform is also an e-commerce entity with 2 crore or more registered users in India (for example, a super-app with a marketplace). Then you must erase a user’s data three years after they last engaged, with a 48-hour warning before erasure (rule 8(2)). Data needed to access the account and virtual tokens that can be used to get money, goods or services (wallet balances, reward points) are excluded. Pure payment apps are not listed in the Schedule.
6. Processors and partners: make KYC vendors, SDK providers, messaging tools and support BPOs erase data you gave them, and get written confirmation. Agree with partner banks and NBFCs who erases what.
7. Backups: document backup retention and make sure restored backups replay erasures.

Rights requests and grievances

• Channels: an in-app “Privacy” section, a web form, support chat and an email address. Publish them with the identifier you need (rule 14(1)), usually the registered mobile, a client code or an account ID.
• Identity: use in-app authentication or an OTP to the registered mobile. Do not ask for new documents you do not already hold.
• Access (section 11): give a summary of the data you process and what you do with it, and list the fiduciaries and processors you shared it with: partner banks and NBFCs, PSP banks, exchanges, depositories, KYC agencies, insurers, SDK vendors.
• Correction (section 12): let users update contact details in-app; route KYC corrections through the KYC update process.
• Erasure (section 12(3)): refuse only what you must keep for a running service or by law (KYC, PMLA, transaction and trade records, tax). Erase the rest and tell the user what you kept and why.
• Grievances: acknowledge quickly and publish a resolution period inside the 90-day ceiling in rule 14(3); 15–30 days is good practice. Name your DPO or contact person in every reply (rule 9). Link DPDP grievances to your RBI, SEBI or IRDAI grievance channels, but keep them distinct.
• Nomination (section 14): offer DPDP nomination in-app, separate from nomination for demat accounts, mutual funds or wallets under sector rules.

Breach readiness

Likely scenarios:

• an exposed API leaking UPI IDs, linked accounts or KYC images
• SDK or analytics vendor capturing screens with balances or OTPs
• account takeover at scale through SIM swaps or device binding bypass
• a merchant dashboard leaking customer payment data
• a lending partner’s collection app exposing borrower data
• a misconfigured log store holding card or token data

Run-book:

1. Contain within hours: revoke keys and tokens, block affected devices, disable the leaking API or SDK, and preserve logs.
2. Assess: which data, how many people, and which consequences: money loss, account takeover, phishing, identity fraud.
3. Notify affected users without delay in-app, by SMS or email, covering every point in rule 7(1): what happened, when and how far it went, the consequences for them, what you are doing, what they should do (reset UPI PIN, re-bind device, beware of fake support calls), and a contact person.
4. Notify the Board without delay, then send the detailed report within 72 hours (rule 7(2)).
5. Report to CERT-In, RBI or SEBI under their directions, and inform your partner banks, NPCI, card networks and exchanges as your contracts and their rules require.
6. Learn: fix the root cause, update SDK and partner contracts, and review the permission register.

The checklist

Phase 1: discover (days 0–30)

• [Leadership] Name a DPDP owner and a working group across product, engineering, risk, compliance, security, CX and partnerships.
• [Product] List every OS permission the app asks for, the feature it serves, and when the prompt appears.
• [Eng] List every SDK in the app and web, what it collects, and where it sends data.
• [Eng] Inventory all systems: user DB, ledger, switch, data warehouse, risk engine, logs, helpdesk, backups.
• [Legal] List every partner (sponsor and PSP banks, NBFCs, AMCs, insurers, exchanges, depositories, KYC agencies) and the role each plays per purpose.
• [Legal] List all processors (cloud, KYC APIs, messaging, support BPO, analytics) and collect their contracts.
• [Security] Check where card data, tokens and payment data are stored, and confirm payment data stays in India.
• [Risk] Find every place SMS, contacts, call logs, installed apps or location feed a risk or credit model.
• [DPO] Check whether any part of the business is an e-commerce entity with 2 crore or more registered users.

Phase 2: design and build (days 31–90)

• [Legal] Assign a legal basis to each purpose using the table above, and stop purposes without one.
• [Product] Remove contacts, call logs, bulk SMS and installed-app access unless a feature strictly needs them; make the app work when a permission is refused.
• [Product] Move permission prompts to the moment a feature is used, with a one-line reason.
• [Risk] Rebuild credit and fraud models without contacts and SMS scraping; use AA data or user-uploaded statements instead.
• [Legal] Write the role split with each partner into the contract: who gives the notice, who collects consent, who handles rights and breaches.
• [Legal] Write itemised notices for onboarding, KYC, payments, credit, investments, insurance and marketing, naming partners.
• [Product] Translate notices into Hindi and the top regional languages; make all 22 Eighth Schedule languages available.
• [Product] Put separate, unticked consent toggles for marketing, cross-sell and partner sharing outside the payment flow.
• [Product] Show the lender’s consent screen only when the user asks for credit; stop silent pre-qualification.
• [Eng] Check consent before every campaign, partner share and personalised offer, through a central service.
• [Eng] Feed withdrawals in real time to CRM, campaign tools, partner feeds and ad-audience syncs.
• [Eng] Block session replay and screenshots on payment, KYC and portfolio screens; mask fields in all SDKs.
• [Eng] Scrub card numbers, UPI PINs, OTPs and full Aadhaar numbers from logs and support tools.
• [Eng] Move to DigiLocker, offline e-KYC or masked Aadhaar where the KYC rules allow.
• [Security] Encrypt KYC and payment data at rest, and use tokens wherever possible.
• [Security] Add device binding, step-up checks on contact and device changes, and rate limits.
• [Eng] Keep access and processing logs for at least one year, and longer where RBI, SEBI or CERT-In rules say so.
• [Legal] Add DPDP clauses to processor and SDK contracts: purpose limits, security, breach notice, erasure on instruction, one-year logs, sub-processors, audit, data location.
• [Eng] Build retention jobs per record type, with legal holds for disputes and investigations.
• [Eng] Erase previously collected SMS, contacts and location data that is no longer necessary.
• [Product] Publish the privacy page: DPO or contact person, rights channels, identifier, grievance timeline.
• [CX] Set up the rights and grievance workflow with in-app verification, owners and deadlines, linked to regulator grievance channels.
• [Product] Offer DPDP nomination in-app, separate from sector nominations.
• [Product] Add an age check where minors may sign up (teen cards, pocket-money wallets), get verifiable parental consent, and switch off targeted offers to children.
• [Product] Send the section 5(2) notice to existing users with a link to review and change choices.
• [Security] Write the breach run-book covering the Board, CERT-In, RBI or SEBI and partner banks.

Phase 3: operate (ongoing)

• [DPO] Review every new feature, permission, SDK, partner and campaign before launch.
• [Eng] Re-scan the app’s permissions and SDKs at every release and remove anything unowned.
• [Security] Run a penetration test every year on the app, APIs and merchant dashboards.
• [Security] Run a breach drill every year (for example, an API leaking UPI IDs) against the 72-hour clock.
• [CX] Review rights and grievance timelines every month and investigate overdue cases.
• [Legal] Review partner and processor contracts and renewal dates every quarter.
• [Compliance] Check every quarter that payment data residency and tokenisation still hold for new vendors.
• [DPO] Keep evidence: notices, consent records, withdrawal handling, erasure confirmations, training records.
• [Risk] Review credit and fraud models every quarter for new data inputs that fail the section 6(1) necessity test.
• [Partnerships] Audit a sample of lending, insurance and investment partners every year for how they use the data you pass them.
• [HR] Train support, risk and field staff every year on OTP safety, identity checks and rights requests.
• [Leadership] Re-assess the likelihood of SDF status as the user base and data volume grow.

Where myconsentapp comes in

You need to	With myconsentapp	You still own
Ask consent per purpose for marketing, cross-sell and partner sharing	Define purposes once, each tagged consent or legitimate use, with sensitivity and retention. The SDKs (TypeScript, Python, Java, Go), widget or hosted consent page show each as a separate toggle, off by default.	Choosing the moment in your journey.
Show partners in the notice	Versioned notices list data items and purposes; the rights, withdrawal and Board-complaint block and DPO contacts are added automatically.	Agreeing the role split with partners.
Prove consent if a user complains	Every choice is signed and hash-chained against the exact notice version, with a receipt (JSON or PDF with QR) and an evidence pack. Anyone can check a receipt on the public verifier.
Check consent before every offer or partner share	Call the verify API; it returns not permitted immediately after a withdrawal.	Wiring it into your offer engine and partner APIs.
Make partners and vendors stop too	The processor registry links each vendor to purposes and data items; signed webhooks tell them of withdrawals; erasure stays open until they confirm.	Signing and enforcing the contracts.
Offer notices in Indian languages	Notices in English and all 22 Eighth Schedule languages, with machine-translation drafts flagged for review.	Reviewing the translations.
Run retention	Set retention per purpose; the retention job ends access and alerts linked processors; erase-on-withdrawal opens erasure automatically; legal holds show in the notice.	Deleting rows in your own systems.
Handle access, erasure and grievances	A rights inbox with SLA timers; users are notified in-app and by email; erasure closes with a structured proof; nomination is built in.	The answers.
Handle minors	An age gate with guardian verification through DigiLocker; tracking and ad purposes can never be marked child-safe.	Deciding which products minors may use.
Manage a breach	A breach register with the 72-hour clock, Rule 7 notices to affected users, and Board intimation and report documents.	Detection, investigation, and CERT-In, RBI or SEBI reporting.

myconsentapp is a proposed Consent Manager. It does not scan your app’s permissions or SDKs, does not discover data in your systems, does not tokenise cards or move payment data, and is not a security programme or legal advice. Integration with your ledger and partner systems is through the API and webhooks.

Common mistakes

• Asking for contacts and SMS access at install “for a better experience”.
• Treating the regulated partner’s notice as covering the app’s own marketing.
• Using payment data for personalised offers without consent.
• Session replay SDKs recording balance and portfolio screens.
• Card numbers or OTPs sitting in application logs or support tickets.
• Pre-qualifying users for loans by sharing data with lenders before they ask.
• Uploading a referrer’s contact list to send invites.
• Erasing KYC or trade records on request that the law requires you to keep.

Frequently asked questions

Can our lending app read SMS to assess income if the user consents? Consent is valid only for data necessary for the specified purpose (section 6(1)). Bulk SMS reading collects far more than income signals, including other people’s messages and OTPs, and RBI’s digital lending rules restrict phone access too. Use AA data or user-uploaded statements instead.

The bank partner is the regulated entity. Are we off the hook? No. If you decide why or how data is used for your own app features, marketing or analytics, you are a Data Fiduciary for that. Where you work on the bank’s behalf, you are its processor and the bank will hold you to its contract. Write the split down, purpose by purpose.

Do we need consent to process a UPI payment? No. Section 7(a) covers data the user voluntarily provides to make a payment, as long as they have not objected. Using that payment data for other purposes needs its own ground, usually consent.

Can we store payment data with a foreign cloud provider? DPDP itself allows transfers abroad subject to government requirements (rule 15), but section 16(2) keeps RBI’s stricter rule that payment system data be stored in India. Check the residency of every vendor that sees payment data.

Is a broker’s KYC shared with a KYC registration agency a disclosure we must list? Yes. In an access request under section 11(1)(b), list the other fiduciaries and processors you shared data with, including KYC agencies, depositories and exchanges.

We run a wallet with cashback points. Does the three-year rule apply? Only if you are an e-commerce entity, online gaming intermediary or social media intermediary over the Third Schedule thresholds. If you are, wallet balances and points that can be used to get money, goods or services are excluded from erasure.

Do we need a Data Protection Officer? Only Significant Data Fiduciaries must appoint one. Every fiduciary must publish a contact person who can answer questions about processing (section 8(9), rule 9). Large payment and broking platforms should prepare for SDF status.