MiCA and GDPR Obligations: A Current Overview and Assessment

MiCA and GDPR Obligations: A Current Overview and Assessment

As of 2026, the European Union's digital ecosystem is undergoing one of the most significant structural and legal transformations in its history.

The interaction between the Markets in Crypto-Assets Regulation (MiCA) and the General Data Protection Regulation (GDPR) has created a new compliance environment for Crypto-Asset Service Providers (CASPs). This environment not only increases compliance requirements but also has the potential to reshape the technical and operational architecture of crypto businesses.

MiCA focuses on market integrity, transparency and accountability, while GDPR prioritises principles such as data minimisation, privacy and the right to erasure.

The coexistence of these two regulatory frameworks creates what can be described as a compliance paradox for the crypto sector.

MiCA has established a harmonised and directly applicable legal framework for crypto-asset markets across all 27 EU Member States. It regulates issuers of asset-referenced tokens (ARTs), electronic money tokens (EMTs), crypto-asset service providers and other crypto-assets offered to the public, bringing an end to much of the fragmented national regulatory structure that previously existed across the European Union.

1. End of the Transitional Period

MiCA's principal rules applicable to CASPs became applicable on 30 December 2024.

However, Article 143(3) provided a transitional period for firms already operating under existing national legislation. Subject to shorter periods introduced by individual Member States, this transitional regime ended no later than 1 July 2026 or when a CASP authorisation application was refused.

The transitional period has now expired. Businesses operating within the EU or providing relevant services to EU clients must therefore review and organise their activities in accordance with the applicable MiCA framework.

From this point onward, exchanges, custodians and intermediaries that require authorisation under MiCA but do not hold the relevant licence can no longer rely on the transitional regime.

For businesses unable to obtain the necessary authorisation, this may require the suspension of new customer onboarding, KYC processes and marketing activities, as well as the orderly transfer of existing customer assets to authorised platforms or self-hosted wallets where appropriate.

Considering the potentially substantial administrative penalties under both MiCA and GDPR, regulatory compliance should be treated as a fundamental operational requirement rather than a secondary legal exercise.

1.2. CASP Licensing Processes and Corporate Structure Requirements

Becoming an authorised Crypto-Asset Service Provider under MiCA requires significantly more than submitting a licensing application.

Applicants are expected to establish governance, risk management and operational systems comparable in many respects to those used by regulated financial institutions.

The documentation submitted to the relevant National Competent Authority should address the company's operational structure and material risks in detail.

These capital requirements represent only the starting point of the operational resilience framework.

Applicant firms are also required to maintain an appropriate presence within the EU and satisfy the relevant corporate governance requirements.

CASPs are additionally subject to requirements arising from the Digital Operational Resilience Act (DORA). This includes the establishment of a comprehensive information and communication technology risk management framework for critical ICT systems and compliance with applicable incident reporting obligations following major cybersecurity events.

1.3. Administrative Sanctions Framework

The enforcement framework surrounding MiCA is designed to ensure that violations cannot simply be treated as an ordinary cost of doing business.

Depending on the nature of the breach, the status of the entity and the applicable legal provision, companies may face significant administrative penalties and supervisory measures.

The scale of these sanctions demonstrates the importance of taking MiCA compliance seriously.

For example, a global stablecoin issuer or crypto exchange generating EUR 500 million in annual revenue could potentially face penalties exceeding EUR 62.5 million in connection with certain turnover-based infringements.

Financial penalties are not the only possible consequence.

Depending on the circumstances, competent authorities may also impose measures such as withdrawal of authorisation, temporary or permanent restrictions on managers and suspension of particular services.

For this reason, MiCA compliance requires coordinated legal, technical and operational preparation.

2. The Core Conflict Between GDPR and Blockchain

GDPR requires personal data to be collected only for specific purposes, limited to what is necessary, stored only for an appropriate period and erased where the applicable legal conditions are met.

Distributed ledger technologies and blockchain systems are based on a very different technical principle.

Information recorded on a blockchain is generally intended to resist retrospective modification, remain part of the ledger and be replicated across a distributed network.

This creates one of the most significant legal and technical challenges at the intersection of blockchain technology and European data protection law.

2.1. The Expanding Definition of Personal Data in the Crypto Ecosystem

Article 4(1) GDPR defines personal data broadly as any information relating to an identified or identifiable natural person.

In the blockchain context, information does not necessarily need to include a person's name, surname or identification number to qualify as personal data.

Wallet Addresses and Public Keys

A wallet address may qualify as personal data where it can reasonably be linked to an individual using additional information.

Such information may include:

• IP addresses
• KYC records held by an exchange
• Transaction patterns
• Device information
• Other identifying datasets

On-Chain Metadata

Transaction hashes, smart contract state transitions, logs and on-chain balance information may also fall within the scope of personal data where they contribute to identifying a natural person.

Blockchain analytics, clustering techniques, open-source intelligence and data held by crypto exchanges can often be combined to associate blockchain activity with real individuals or organisations.

For this reason, blockchain identifiers should generally not be assumed to be inherently anonymous. In many circumstances, they are more accurately described as pseudonymous.

2.2. Controller and Processor Responsibilities

A central requirement of GDPR compliance is identifying the party that determines the purposes and means of processing personal data.

Under Article 4(7) GDPR, that party is generally regarded as the data controller.

Centralised Crypto Exchanges

A centralised exchange providing custodial services will generally act as a controller for personal data processed in activities such as:

• Customer registration
• Identity verification
• Trading
• Deposits and withdrawals
• Fraud monitoring
• Regulatory compliance

Third-party providers carrying out specific processing activities on behalf of the exchange may instead qualify as processors.

Examples may include:

• KYC verification providers
• Identity scanning services
• Blockchain analytics companies
• Cloud infrastructure providers

Where a controller-processor relationship exists, the parties must establish an appropriate data processing agreement in accordance with Article 28 GDPR.

2.3. The Right to Erasure and Blockchain Immutability

One of the most difficult issues arises from the interaction between blockchain immutability and the right to erasure under Article 17 GDPR.

Where there is no longer a valid legal basis or purpose for processing personal data, an individual may under certain circumstances request the deletion of that information.

In a conventional database, the relevant information can usually be modified or removed.

Blockchain technology creates a different challenge because historical records are generally designed to remain part of the chain and resist retrospective alteration.

Changing previously recorded information may affect cryptographic references to later blocks and compromise the integrity of the ledger.

For this reason, European data protection authorities have increasingly focused on the principle of Privacy by Design under Article 25 GDPR.

Data protection requirements should not be added only after a blockchain architecture has already been deployed. They should form part of the system's design from the beginning.

3. EDPB Guidelines on Data Protection and Blockchain Integration

Following a public consultation process, the European Data Protection Board adopted the final version of its Guidelines 02/2025 on the processing of personal data through blockchain technologies in July 2026.

The guidelines provide practical direction for organisations planning to deploy blockchain systems that involve the processing of personal data.

3.1. Avoiding Personal Data Directly On-Chain

One of the central approaches in the guidelines is that directly identifiable personal data should generally not be stored openly on a blockchain.

This principle reflects several GDPR requirements, including:

• Data minimisation under Article 5(1)(c)
• Storage limitation under Article 5(1)(e)
• Integrity and confidentiality under Article 5(1)(f)

A more privacy-conscious architecture generally involves storing personal data in an off-chain environment where access can be controlled and the data can be updated or deleted when legally necessary.

The blockchain can instead be used to store hashes, cryptographic commitments or pointers that demonstrate the existence or integrity of the underlying information without placing the complete dataset directly on-chain.

Where a data subject exercises the right to erasure, the underlying information stored in the off-chain database may then be deleted.

In certain architectures, encryption keys may also be destroyed using a method commonly referred to as crypto-shredding.

This type of hybrid architecture can help organisations reconcile blockchain functionality with GDPR requirements.

3.2. Public and Permissioned Blockchains

Public blockchain networks create additional privacy challenges because information may be accessible to a potentially unlimited number of network participants and replicated across multiple jurisdictions.

For corporate applications involving personal or financial information, private or permissioned blockchain structures may therefore provide greater control.

Such systems can define:

• Who may access the network
• Who may write information to the network
• Who may validate transactions
• How governance decisions are made
• How security controls are implemented

Where a public blockchain is used, the data controller should carefully assess whether the open and potentially permanent availability of information is necessary and proportionate for the stated processing purpose.

3.3. Encryption, Zero-Knowledge Proofs and Their Limits

Privacy-enhancing technologies such as Zero-Knowledge Proofs (ZKPs) and strong encryption methods can significantly reduce privacy risks.

However, the use of these technologies does not automatically remove information from the scope of GDPR.

Encrypted or pseudonymised information may still qualify as personal data where it can reasonably be linked back to an identifiable person.

Accordingly, encryption and ZKPs should be treated as important technical safeguards rather than automatic legal exemptions.

They should form part of a wider set of appropriate technical and organisational security measures.

3.4. Data Protection Impact Assessments

Blockchain-based processing can create significant privacy risks due to factors such as:

• Difficulty of modifying recorded information
• Distributed data storage
• Cross-border data transfers
• Long-term accessibility
• Complexity in exercising data subject rights

Where processing is likely to result in a high risk to individuals' rights and freedoms, organisations may be required to conduct a Data Protection Impact Assessment before processing begins.

A comprehensive DPIA should assess issues including:

• Location of network nodes
• Potential data transfers outside the European Economic Area
• Data breach scenarios
• Data retention
• Access controls
• Erasure and rectification mechanisms
• Data subject access rights
• Governance and allocation of responsibilities

The assessment should be carried out during the design stage rather than after the system has already been deployed.

3.5. Smart Contracts and Automated Decision-Making

Smart contracts can automatically execute predefined actions when coded conditions are met.

Where such actions produce legal effects or similarly significant consequences for individuals, GDPR rules relating to automated decision-making may become relevant.

Examples may include:

• Automatic liquidation of collateral
• Automated rejection of a loan
• Suspension of access to a service
• Automated eligibility decisions

Companies should therefore assess whether their smart contract architecture requires mechanisms for human intervention, review or dispute resolution.

Users should also be provided with clear and understandable information about how automated decisions operate.

Making complex source code available is not, by itself, sufficient to provide meaningful transparency to an ordinary user.

4. Non-EU Service Providers and Reverse Solicitation

Crypto businesses established outside the European Union, including companies based in Türkiye, the United States or Asia, face specific restrictions when providing crypto-asset services to EU clients without MiCA authorisation.

One of the narrow exceptions available under MiCA is reverse solicitation under Article 61.

The principle is based on the client initiating the relationship exclusively on their own initiative.

ESMA's guidelines on reverse solicitation interpret this exception narrowly in order to prevent third-country businesses from using it as a route to actively target EU clients without obtaining the appropriate authorisation.

Where a third-country company directly or indirectly solicits EU clients, reliance on the reverse solicitation exception may no longer be possible.

Marketing and Promotional Activities

Activities that may be relevant when assessing whether a company has actively targeted EU clients include:

• EU-specific advertising campaigns
• Localised websites
• Mobile application notifications
• Targeted social media advertising
• Search engine marketing activities
• Sponsorship of events aimed at EU audiences

Affiliates and Influencers

Indirect marketing can also be relevant.

Promotional activity conducted through:

• Affiliates
• Group companies
• Commercial partners
• Influencers
• Finfluencers

may be attributed to the service provider depending on the circumstances.

The fact that an advertisement was not directly published by the company does not automatically place the activity outside the scope of solicitation rules.

Evidence and Record-Keeping

Simply including a disclaimer stating that a service was provided exclusively at the customer's initiative may not be sufficient.

Companies relying on reverse solicitation should be able to demonstrate how the client relationship began.

Relevant records may include:

• Initial communication records
• Audit logs
• Timestamps
• Customer requests
• Screenshots
• Onboarding documentation

For non-EU crypto platforms seeking continued access to the European market, one of the principal options is to obtain the appropriate MiCA authorisation.

Where a company intends to rely on reverse solicitation instead, EU-related marketing, advertising and customer acquisition activities should be assessed very carefully.

5. Conclusion

The interaction between MiCA and GDPR demonstrates that regulatory compliance in the crypto sector can no longer be treated solely as a legal documentation exercise.

Companies operating in this environment must coordinate legal, technical and operational teams.

CASP licensing, operational resilience, data protection, blockchain architecture, automated decision-making and cross-border marketing rules increasingly form part of the same compliance ecosystem.

This is particularly important for businesses in Türkiye and other non-EU jurisdictions that maintain commercial relationships with customers, partners or counterparties within the European Union.

Failure to comply may result not only in significant administrative penalties, but also in licensing restrictions, suspension of services and difficulties accessing the European market.

Legalifi supports organisations seeking to address these requirements through multidisciplinary compliance projects covering regulatory areas including MiCA, GDPR and KVKK.

By combining legal expertise with technology-supported compliance processes, Legalifi aims to help businesses monitor evolving European digital regulations and adapt their operations accordingly.