DPDP Compliance for Fintech and Payment Companies: Consent, KYC and Transaction Data

DPDP compliance for fintech companies starts with an inventory, field by field, of what each product collects, why, and which database or vendor tool holds it. Existing RBI directions continue to apply, and the Digital Personal Data Protection Act, 2023 (DPDP Act) adds a second set of rules on how individuals' personal data is handled. Two dates anchor the plan: 13 November 2026, when Rule 4 of the DPDP Rules, 2025 starts, and 13 May 2027, when most other operating duties begin.

A lending app collects identity documents and income proof during onboarding; bank details follow at disbursal, and each repayment adds a transaction record. The sections below follow that data from onboarding to payment to partner sharing and point out which team makes each decision.

What this means for your business:

• Map each product's data and the purpose behind it.

• Align consent screens, retention schedules and partner contracts with the rules that apply.

• Prioritise system changes by deadline, and test each one before it goes live.

1. What Does DPDP Compliance Mean for Fintech and Payment Companies?

The business that decides why and how personal data is used is the Data Fiduciary, which is the role a fintech holds for its own customers; the customer, such as a borrower or a wallet user, is the Data Principal. When a bank or merchant sets the purpose and a payment company handles the transactions on its instructions, the company can act as a Data Processor and the bank or merchant is the fiduciary.

DPDP and RBI rules apply together. RBI already directs how long KYC records stay on file and where payment data is stored. The DPDP Act adds notice duties, the customer's right to refuse optional uses and a duty to report breaches, so meeting RBI requirements does not by itself satisfy the Act.

2. Where Do DPDP Obligations Apply Across KYC and Payment Journeys?

From the first app screen to the monthly statement, every step of the journey collects data for its own reason and passes it to its own system and team.

2.1 Customer onboarding and KYC verification

Some KYC steps may run on a legal requirement instead of consent. The Act gives a business two routes to use personal data: the customer's consent, or one of a short list of legitimate uses. Regulated entities run KYC (Know Your Customer), the identity check before an account opens or a loan is approved, because the Prevention of Money-laundering Act, 2002 (PMLA) and RBI's KYC Directions, 2025 oblige them to. RBI issued them on 28 November 2025, replacing the Master Direction of 2016. Counsel should confirm the basis for each step, which may be consent or another listed use.

Start with the purpose of collection. A purpose register gives each data field its own row. On that row go the purpose, the ground (the legal reason for using the field), and the system and team that hold it. A PAN (Permanent Account Number) collected to verify an account earns one row; the same PAN reused to build a marketing audience needs a second row with its own ground.

2.2 Payment processing and transaction records

Classify transaction data first. A payment record becomes personal data when it points to a person, for example through the customer account or a UPI handle (UPI is the Unified Payments Interface, India's real-time payment system). Settlement totals that cannot be traced to any individual may fall outside the Act, which is why classification comes first.

Confirm which payment data RBI requires to stay in India. RBI's directions on storage of payment system data tell payment system providers authorised by RBI, and their service providers, to keep all payment data in systems located only in India. A foreign processor may handle a transaction if the copy abroad is deleted and the data returns to India within one business day or 24 hours of payment processing, whichever is earlier. The directions cover payment system providers and payment data, so the compliance team should check where each dataset stands before anyone extends the rule to CRM or marketing data.

The DPDP Act allows transfers outside India unless the Government restricts them, and it leaves sector rules such as RBI's storage directions in force, so a payment company checks both before sending data abroad.

2.3 Lending partners, analytics and marketing systems

List every recipient of the data. The credit bureau pull and the co-lender hand-off serve loan assessment. The analytics dashboard and the SMS campaign tool serve reporting and marketing. A customer who stops promotional SMS messages should still see the loan balance in the app.

3. How Should Fintech Companies Manage Consent and Privacy Notices?

The Act expects consent to be free, specific, informed, unconditional and unambiguous. In an app, a deliberate action such as ticking a box that starts unticked can meet that expectation. Rule 3 adds that the notice shown before consent must itemise the data and the purpose, from 13 May 2027. Three actions put this into practice in the product.

3.1 Separate core service processing from optional purposes

Verifying identity and completing a payment are core processing, because the customer cannot receive the service without them. Promotional offers, and sharing with partners for their own marketing, are optional purposes. Consent extends to the data the stated purpose needs, so a customer who declines promotional offers should still be able to complete a payment.

3.2 Record the consent and notice version

Make withdrawal as easy as giving consent. After a withdrawal, the business has to stop the processing within a reasonable time, and the Act asks that withdrawing be as easy as consenting was. A customer who agreed with one tap should be able to withdraw with one tap. The consent record should carry the notice version the customer saw and the purpose, with a timestamp and channel for every event, a later withdrawal included. When a customer disputes what was agreed, the business must show the notice given and the consent that followed, and this record holds both.

3.3 Propagate withdrawals across connected systems and test the result

Send each withdrawal to every system that used the consent. A marketing withdrawal made in the app needs to reach the CRM, the messaging platforms and any partner that received the data. Consider a messaging tool that rebuilds its audience list at midnight. A customer who withdraws at 10 am can still get the 8 pm SMS run. Three checks show whether the update reaches everywhere it should:

1. System coverage: list every platform and partner that receives the consent update.

2. Sync timing: find the legacy systems that update in nightly batches, such as the SMS vendor's audience list, and name an owner for each.

3. End to end testing: withdraw consent on a test account at noon, then confirm the evening campaign skips it.

A consent management platform is software a business uses on its own channels to collect and track consent. A Consent Manager is a different thing: a registered entity under Rule 4 that lets customers give, manage, review and withdraw consent across several businesses from 13 November 2026.

4. How Should Fintech Companies Handle KYC and Transaction Data Retention?

Withdrawal ends the optional uses of data, and mandated records stay. The Act asks for erasure when consent is withdrawn or the stated purpose has ended, except where a law requires the business to keep the data. The PMLA sets the exception for KYC: a regulated entity keeps client identity records for five years after the business relationship ends or the account closes, whichever is later, and RBI's KYC Directions follow the same period.

Three situations cover most fintech records:

• Withdrawn consent: marketing uses stop and the data is assessed for erasure.

• Legal retention duty: the KYC file stays for the period the law sets.

• Vendors and backups: deletion extends to every vendor system and backup.

Document why each retained record is kept. For each record type, the retention register states the legal duty and the period, then the start date and the deletion method. The PMLA requires transaction records to be kept for five years from the date of the transaction, and counsel should confirm whether a longer period applies to any category. One scanned identity document can have copies in cloud storage, the e-sign vendor's system and the core database, so the deletion plan names each location and the backup cycle that clears it.

Processing done to prevent, detect or investigate an offence is exempt under the Act from specified provisions, notice and consent among them. The fraud team lists the processes that rely on that exemption, and counsel confirms how far it reaches.

Related reading: Data Retention Policies under DPDPA: How Long Can You Hold Personal Data

5. What Should Fintech Companies Review in Third-Party Data Sharing?

Map every partner that receives customer data. For each one, decide whether it is a Data Processor working on your instructions or a fiduciary with its own purposes. Responsibility for processing done on the business's behalf stays with the business, and the Act requires a valid contract with every processor. Credit bureaus and co-lenders may be fiduciaries themselves. Four points cover a partner review:

• Data and purpose: the fields the partner receives and the reason it needs each one.

• Responsibilities: the side that collects, the side that secures and the side that deletes.

• Contract terms: written duties, including a time limit, in hours, for the partner to report a breach to you. Under Rule 7 the business informs affected customers and the Data Protection Board without delay, and sends the Board further details within 72 hours.

• Exit and incidents: the return or deletion of data when the contract ends, and the steps after a breach.

6. How Can Fintech Companies Assess DPDP Compliance Software?

DPDP compliance software for fintech is useful when consent and preferences must be enforced across many systems. Six criteria help your team compare options:

• Capture: the solution records purpose-specific consent across web, app and other touchpoints, and each record can be traced.

• Evidence: the team can retrieve the notice version and consent record for a named customer on a given date.

• Withdrawal: a test withdrawal appears in the connected systems, and your team can see where.

• Integration: connectors or APIs exist for the CRM and marketing platforms already in use.

• Oversight: reports give the compliance team consent status and open rights requests.

• Delivery: implementation ownership and integration effort are agreed before purchase.

Ask each vendor to run a withdrawal and an evidence search on a test account.

7. What Should Fintech Companies Prioritise Before DPDP Obligations Take Effect?

Begin where the most personal data moves: onboarding, KYC and the first payment.

1. Map personal data and its purpose. Build the purpose register described earlier, with the ground, system and owner for each field.

2. Assign ownership. The product team changes notice and consent screens while compliance reviews grounds and retention. Engineering handles the integrations, and procurement manages partner contracts.

3. Sequence the work. Screen changes move faster than withdrawal updates across legacy systems or deletion from backups. Rank the items by deadline first and effort second.

4. Run the whole workflow as a test. Raise a test withdrawal and a test erasure request, then trace each through every system and partner it reaches. Record the result, close the gaps and repeat the test.

DPDP Compliance for Fintech Companies: Assess Your Consent Readiness

Planning DPDP compliance for fintech companies around consent, KYC and transaction data together makes sense because the same customer record passes through all three. Assess your consent management needs and DPDP readiness with OneConsent. Explore OneConsent's DPDP platform and book a consultation to discuss how your consent flows and partner connections map to your product lines.