Crypto and Web3 Platforms Under the DPDP Act: An Impact Study

Executive summary

India has no licensing regulator for crypto, but crypto platforms are far from unregulated on data. Since March 2023, virtual digital asset (VDA) service providers have been reporting entities under the anti-money-laundering law. CERT-In requires them to keep KYC and transaction records for five years. Exchanges file tax statements naming their users, and from 2026 they must also collect tax-residence data for the international Crypto-Asset Reporting Framework (CARF).

The Digital Personal Data Protection Act, 2023 (the DPDP Act) governs what those rules leave open: use beyond the legal mandate, retention and leaks. Its starting point is awkward for an industry built on pseudonymity. Once a platform can link a wallet address to a person, that address is personal data.

Headline impact rating: High. Six of the twelve areas in the Trayambic scorecard are rated High. The three biggest changes are:

1. 1.Erasure meets ledgers and stacked retention rules. Users can ask for erasure, but blockchains cannot forget, and anti-money-laundering, cyber security and tax rules each set their own retention period.
2. 2.Wallet addresses and counterparties are personal data. Travel-rule messages, blockchain analytics and withdrawal whitelists process data about people, including people who are not customers. Each use needs a documented ground.
3. 3.A KYC leak is a safety event. Identity documents, selfies, addresses and holdings in one place make users targets. CERT-In reporting within six hours continues; from 13 May 2027 the Data Protection Board and every affected user must also be told.

On 9 September 2026 the Financial Intelligence Unit (FIU-IND) issued notices to 15 more VDA service providers it found operating without complying with the PMLA, and sought takedown of their apps and websites. The DPDP Act reaches the same platforms whenever they serve users in India.

Background

Who this study covers

The DPDP Act calls the organisation that decides why and how personal data is processed a data fiduciary, the person the data is about a data principal, and a business processing data on a fiduciary's behalf a data processor. This study covers:

• VDA exchanges and brokers: rupee-to-crypto and crypto-to-crypto trading, and over-the-counter desks.
• Wallet providers: custodial wallets that hold keys for users, and non-custodial wallet software.
• NFT marketplaces: minting, listing and trading of non-fungible tokens.
• Web3 apps: decentralised finance front ends, token issuers, blockchain games and community platforms.
• Offshore platforms serving users in India.

Payments and securities are covered in Trayambic's fintech and capital markets studies.

What data is collected

• KYC: name, PAN, identity and address documents, selfie, bank account and, for corporate clients, directors and beneficial owners.
• Wallet data: deposit addresses assigned to each user, withdrawal addresses, transaction hashes and on-chain history.
• Travel-rule data: names and wallet addresses of senders and recipients, including recipients who are not customers.
• Technical data: device identifiers, IP addresses and timestamps.
• Tax data: PAN-linked records for tax-at-source statements and, from 2026, tax-residence self-certifications.
• Community data: usernames, profile images, linked social accounts, chat activity and NFT creator and holder histories.

Where the data goes

By law, to FIU-IND, the Income Tax Department and investigating agencies. By contract, to KYC and liveness vendors, blockchain analytics firms, custody providers, travel-rule messaging networks, banks providing rupee rails, cloud hosts and support outsourcers, many of them abroad. And some is written to public blockchains, where no one can edit it.

Legal framework

The DPDP Act and Rules

• Personal data (s.2(t)): "any data about an individual who is identifiable by or in relation to such data".
• Reach (s.3): the Act covers processing outside India connected with offering services to data principals in India (s.3(b)), and excludes data the data principal herself makes public (s.3(c)(ii)).
• Grounds (ss.4, 6, 7): consent, or a closed list of legitimate uses, including data voluntarily provided for a specified purpose (s.7(a)) and disclosures to the State required by law (s.7(d)). There is no general "legal obligation" ground.
• Offences (s.17(1)(c)): Chapter II (except ss.8(1) and 8(5)), Chapter III and s.16 do not apply to processing in the interest of preventing, detecting, investigating or prosecuting offences or contraventions of law.
• Security and breach (s.8(5), s.8(6), Rules 6 and 7): reasonable safeguards, logs kept for a year, notice to the Board and each affected person, and a detailed report to the Board within 72 hours. The maximum penalty for failing to take security safeguards is ₹250 crore.
• Erasure (s.8(7), s.12(3)): erase on withdrawal of consent or when the purpose ends, unless retention is necessary for the specified purpose or for compliance with law; processors must erase too.

Crypto instruments

• PMLA notification, S.O. 1072(E), 7 March 2023, under s.2(1)(sa)(vi) of the Prevention of Money-laundering Act, 2002 (PMLA). Five activities carried on for others in the course of business make a provider a reporting entity: exchange between VDAs and fiat currencies; exchange between VDAs; transfer of VDAs; safekeeping or administration of VDAs or instruments enabling control over them; and financial services for an issuer's offer and sale of a VDA.
• FIU-IND AML and CFT Guidelines for VDA service providers (10 March 2023): registration with FIU-IND (para 5.1); KYC before onboarding and no anonymous or pseudonymous wallets (para 5.7); periodic KYC at least yearly (para 5.7.1); possible reporting of device identifiers, IP addresses with timestamps, wallet addresses and transaction hashes (para 6); travel-rule data covering the sender's PAN or national identifier, name, wallet address and address or date and place of birth, and the recipient's name and wallet address (para 11.3); transfers involving unhosted wallets treated as high risk (para 11.2.2). Registration circulars were revised three times between 2023 and 2025, and updated guidelines issued on 8 January 2026.
• PMLA s.12: transaction records kept five years from the transaction (s.12(3)); identity records five years after the relationship ends or the account closes, whichever is later (s.12(4)).
• Offshore enforcement. FIU-IND issued notices to nine offshore providers in December 2023, penalised Bybit ₹9.27 crore in January 2025, and issued notices to 25 offshore providers in October 2025 and to 15 more providers on 9 September 2026, the last with takedown notices under s.79(3)(b) of the IT Act. Its releases say the obligations are activity-based and "not contingent on physical presence" in India.
• CERT-In Directions (28 April 2022): virtual asset service providers, exchanges and custodian wallet providers must keep KYC information and financial transaction records for five years (direction (vi)); incidents are reported within six hours (direction (ii)) and ICT logs kept for 180 days (direction (iv)).
• Income-tax. The Income-tax Act, 2025 replaced the 1961 Act from 1 April 2026. Exchanges report the 1% tax at source on VDA transfers (s.194S of the 1961 Act, now s.393(1), Table serial 8(vi)) in quarterly statements (Form 142, formerly 26QF) carrying each party's name, address and PAN.
• CARF. Section 509 of the 2025 Act (formerly s.285BAA, inserted by the Finance Act, 2025) requires prescribed reporting entities to report crypto-asset transactions. Rules 241 to 244 of the Income-tax Rules, 2026 apply to providers that are tax resident, incorporated, managed or have a regular place of business in India, or act through an Indian branch (rule 242). Reporting runs by calendar year from 2026, in Form 167, due by 31 May of the following year. Users self-certify name, address, tax residences, tax identification numbers and date of birth, and external wallet addresses must be kept for at least seven years (rule 243). Due diligence on existing individual users must finish within 12 months from 1 January 2026.

How the layers fit

Section 38 makes the DPDP Act additional to these laws and lets it prevail in a conflict. Direct conflict is rare: ss.8(7) and 12(3) let a platform keep what another law requires, and in our view s.17(1)(c) lifts most of the Act from anti-money-laundering monitoring. The Act bites on everything around the mandate: marketing, analytics, community features, data kept "just in case", and security.

Analysis

The Trayambic DPDP Impact Scorecard

Overall impact: High

Wallet addresses are personal data

A wallet address is a string of characters, not a name. But s.2(t) covers data about an individual identifiable "by or in relation to" it. An exchange knows which deposit address it assigned to which user and which withdrawal addresses each user whitelisted. In its hands, each of those addresses, and every transaction hash linked to them, is personal data. Analytics vendors that cluster addresses and label them create more.

Three consequences follow.

• Notices must cover wallet data. A notice listing "name, email, PAN" misses the most revealing data the platform holds: a user's transaction history across platforms.
• Counterparties are data principals too. The travel rule makes the sending platform transmit the recipient's name and address and the receiving platform hold the sender's details; neither person consented to the other platform. In our view, collection and transmission required by FIU-IND guidelines falls within s.17(1)(c), or s.7(d) where it is a disclosure to the State. Neither covers reusing counterparty data for marketing or growth analytics.
• On-chain is not public for every purpose. When a user broadcasts a transaction herself, s.3(c)(ii) may take the on-chain record outside the Act. The exchange's private link between that address and her identity remains in scope. And when the platform, not the user, writes personal data to a chain, such as a username in NFT metadata, in our view the exclusion does not apply, and the data can never be erased.

The design lesson follows from s.3(c)(ii): the platform should never be the one that puts personal data on a chain. Where a link is unavoidable, store a pointer to off-chain data that can be deleted.

Account closure: delete, restrict, explain

A user who closes her account may ask for erasure under s.12. For a crypto platform the answer depends on retention rules that run side by side:

Sections 8(7) and 12(3) let the platform keep what these laws require, and only that. In our view a sound erasure response does three things: deletes what no law requires; restricts what must be kept to its legal purpose; and explains that on-chain history cannot be changed by anyone, while the platform's link between that history and her identity will be deleted when the last period ends.

The new seven-year CARF period covers external wallet addresses, not the whole KYC file, so set retention record by record.

Offshore platforms and cross-border flows

FIU-IND treats PMLA duties as activity-based: an offshore platform serving Indian users must register whether or not it has an Indian presence. The DPDP Act takes the same approach. Under s.3(b), an offshore exchange onboarding Indian users is a data fiduciary with the same duties as an Indian one, including breach notice to Indian users and the Board.

CARF draws its line differently. India's rules bind providers with an Indian tax residence, incorporation, management, place of business or branch. An offshore platform without such a link falls outside them, although CARF is built for exchange between tax authorities, and the CBDT's guidance note of 24 July 2026 refers to an aspiration that many jurisdictions begin exchanges by 2027.

Cross-border flows are built in: travel-rule messages go to foreign platforms, and analytics vendors and cloud hosts are often abroad. No country is restricted under s.16(1) as of October 2026, so transfers are lawful, but the platform answers for its processors abroad (s.8(1)) and must name recipients in access responses (s.11).

Breach: when a KYC store becomes a target list

Not every crypto loss is a personal data breach. Tokens stolen from a hot wallet are lost assets; a DPDP breach needs personal data to be accessed, disclosed, altered or lost. Platforms attract attackers because they hold both, and a leaked file showing who holds large balances, and where they live, puts people at physical risk.

The clocks stack: CERT-In within six hours of noticing a covered incident; from 13 May 2027, notice without delay to the Board and to each affected user, and a detailed Board report within 72 hours. For crypto users, the steps the notice suggests should include phishing warnings and withdrawal-whitelist resets.

Worked example: an exchange with a support-tool leak

A rupee-to-crypto exchange incorporated in India and registered with FIU-IND runs an NFT marketplace, uses a foreign KYC and liveness vendor, and outsources first-line support to a call centre with access to a support dashboard (figures illustrative).

An attacker phishes a support agent's credentials and exports records of 80,000 users: names, phone numbers, emails, selfies, cities, balances and withdrawal addresses. From 13 May 2027:

• It is a personal data breach, and the exchange's. The call centre's agent was phished, but the exchange answers for its processor (s.8(1)).
• Three reports. CERT-In within six hours; the Board without delay; a detailed Board report within 72 hours on facts, causes, mitigation and notices sent.
• Each of the 80,000 users must be told, in plain language, with steps matched to the risk: phishing warnings, a freeze option, whitelist resets and a dedicated helpline.
• Balances raise the stakes. Users with large holdings face extortion and physical risk; contact them first and directly.
• The Board will ask about safeguards: why a support screen showed selfies and balances, why bulk export was possible, and whether access was logged and alerted (Rule 6).
• The NFT arm adds exposure. Leaked addresses can be matched with public NFT holdings, and nothing on-chain can be recalled.

The lasting fix is minimisation inside the platform: support screens should show only what an agent needs.

Compliance framework

Checklist

Roadmap to 13 May 2027

Now to December 2026. Appoint a DPO, map wallet and counterparty data first, and finish CARF due diligence on existing individual users by 31 December 2026. Offshore platforms serving India should assess FIU-IND and DPDP duties together.

January to March 2027. Rebuild notices and consent, set record-by-record retention, strip personal data from on-chain writes and lock down support tools.

April to May 2027. Sign vendor amendments, run a KYC-leak breach drill, launch notices to existing users and file the first Form 167 by 31 May 2027.

Ongoing. Track FIU-IND guideline changes, Board guidance, any s.16 restrictions and any SDF designations.

Recommendations

1. 1.Treat every wallet address you can link to a person as personal data.
2. 2.Never write personal data to a chain yourself: no names or KYC-linked data in tokens or metadata.
3. 3.Set retention record by record, so a seven-year wallet-address rule does not become seven years for everything.
4. 4.Keep the s.17(1)(c) exemption to screening. Counterparty and monitoring data collected under AML rules should not feed marketing or growth models.
5. 5.Design support tools for leaks: masking, no bulk export, alerts on unusual viewing.
6. 6.Plan breach notices around user safety, not only regulatory clocks.
7. 7.Offshore platforms: assume Indian law applies once Indian users are onboarded.

Key takeaways

• Crypto and Web3 platforms rate High on the Trayambic scorecard, with six of twelve areas rated High.
• Once a platform can link a wallet address to a person, that address and its transaction history are personal data under s.2(t).
• Erasure must be answered record by record: PMLA and CERT-In five-year periods and the new seven-year CARF rule for wallet addresses can justify retention, but nothing else.
• In our view, personal data a platform itself writes to a blockchain falls outside the s.3(c)(ii) exclusion and can never be erased, so platforms should write none.
• Offshore platforms serving Indian users are data fiduciaries under s.3(b), just as FIU-IND treats them as reporting entities regardless of physical presence.