GDPR and MiCAR in Poland: Data protection at crypto-asset service providers

Last updated: 28.09.2026

MiCAR does not create a separate data protection regime for the crypto-asset sector. The GDPR continues to apply alongside the Markets in Crypto-Assets Regulation (Regulation (EU) 2023/1114). For crypto-asset service providers, this means that MiCAR compliance also needs to be considered from a data protection perspective.

In practice, many core MiCAR obligations involve personal data. A CASP authorisation application may include criminal record certificates and good-repute documentation. Providers must keep records of orders and transactions and monitor client activity for market abuse. At the same time, Regulation (EU) 2023/1113, known as the Travel Rule, requires identifying data to accompany transfers of crypto-assets.

Blockchain adds another layer of complexity. Information recorded on a public distributed ledger generally cannot be amended or deleted. This can be difficult to reconcile with GDPR requirements on data retention, rectification and erasure, making the crypto-asset sector challenging from a data protection perspective.

This guide is a part of our GDPR in FinTech series and looks at MiCAR together with the GDPR, Regulation (EU) 2023/1113 and the EDPB Guidelines 02/2025 on blockchain. It is aimed at management boards and legal and compliance teams of crypto-asset service providers, as well as businesses planning to enter the market. It covers key areas such as CASP authorisation, data retention, wallet analytics, biometric onboarding and automated decision-making.

Key data protection issues for crypto businesses in Poland

Where does MiCAR generate personal data?

It is worth first mapping the processing operations that MiCAR itself mandates, and then those that follow from commencing business on the crypto-asset market. The application for authorisation under Article 62, fleshed out by Commission Delegated Regulation (EU) 2024/1503, requires evidence of the good repute and of the knowledge, skills and experience of the members of the management body and of shareholders with qualifying holdings, including information on the absence of a criminal record.

This is territory governed by Article 10 GDPR, with national restrictions on who may process data relating to criminal convictions and how such data may be obtained, and the discipline is the same one we described for crowdfunding platforms: the categories set out in the technical standards form a closed catalogue, and an application that gathers more is not more compliant, but less.

Once authorised, a CASP performs a set of continuing obligations, each of which involves the processing of personal data. Three distinct retention bases flow from MiCAR itself:

• records of all services, activities, orders and transactions – kept for five years (Article 68(9)); this is a minimum that must be reconciled with the storage limitation principle by maintaining archives separated by purpose rather than a single common data store;
• complaints-handling files – kept under Article 71, supplemented by Commission Delegated Regulation (EU) 2025/294; those files themselves contain personal data and require their own retention period;
• signals from market abuse monitoring – Articles 86–92 oblige persons professionally arranging or executing transactions to detect and report suspicious orders and transactions.

The monitoring of client behaviour under the last of these obligations constitutes profiling within the meaning of the GDPR. It requires a documented balancing test, a proportionate scope, and a retention period for the generated signals that can be defended before the supervisory authority.

Blockchain and GDPR in Poland: Wallet addresses, immutability and the EDPB Guidelines

An address on a distributed ledger is pseudonymous, not anonymous. The moment a CASP links an address to a KYC-verified client, every historical and future transaction of that address becomes personal data in the provider’s hands, and often in the hands of anyone else capable of making the same link.

This is the fundamental data protection fact of crypto, and it is why the EDPB Guidelines 02/2025 state clearly that, as a rule, personal data should not be written on-chain in a directly identifying form. From the design stage onwards, off-chain storage with only proofs of existence on the ledger, salted or keyed hashes, and cryptographic commitments should be considered; a DPIA will usually be necessary, and for public blockchain networks the EDPB suggests incorporating standard contractual clauses into node participation agreements to address transfers via nodes located outside the EEA.

We discussed the guidelines in detail in our analysis of the blockchain–GDPR relationship, and their design consequences in the on-chain sections of our GDPR in FinTech pillar guide.

The rights to erasure and rectification are the hardest to reconcile with a ledger to which records, once added, can be neither amended nor removed. An address that must remain on a public ledger cannot be wiped, so compliance is achieved by severing identifiability: deleting the off-chain link, destroying the keys, and ensuring that what remains on-chain no longer relates to an identifiable person.

Whether a given privacy-enhancing technique actually achieves anonymisation within the meaning of the GDPR remains an open question and is currently the subject of supervisory proceedings, including the biometric identity verification cases discussed below. Anonymisation claims made by technology vendors should not be accepted without evidence, because the supervisory authority will likewise require them to be proved.

Crypto Travel Rule: What data must accompany crypto-asset transfers?

Regulation (EU) 2023/1113, known in practice as the Travel Rule, extends the traceability obligation for funds transfers to crypto-assets.

The originator’s CASP must ensure that every transfer is accompanied by the following required information for both the originator and the beneficiary, transmitted with appropriate data security safeguards before or at the moment of the transfer:

• the originator’s name;
• the originator’s distributed ledger address or account number;
• the originator’s physical address, official personal document number and customer identification number, or date and place of birth;
• the beneficiary’s name and the beneficiary’s address or account number.

For crypto-asset transfers to or from a self-hosted wallet address above the EUR 1 000 Travel Rule threshold, the CASP must assess whether the address is in fact owned or controlled by its own client, applying the EBA’s 2024 Travel Rule guidelines.

How does the Travel Rule restrict the use of data for money laundering and terrorist financing purposes?

The legislature wrote data protection safeguards into the act itself: Personal data processed under the regulation may be used solely to combat money laundering and terrorist financing, commercial use is expressly prohibited, records are kept for five years, and after that period the data must be deleted unless national law provides otherwise.

This is a statutory purpose limitation and retention regime stricter than the default GDPR standard, with the result that re-using Travel Rule data for analytics or marketing is not merely a failed balancing test but a direct breach of EU law.

How does the Travel Rule affect cross-border data transfers?

This data set travels with the transfer: Every transfer moves a package of identifying data to another provider, potentially outside the EEA, and the regulation itself recognises this collision, mandating the EBA to issue guidelines on whether to execute, reject, return or suspend a transfer where compliance with data protection requirements cannot be ensured during data transmission to a third country.

Chapter V GDPR rules on cross-border transfers, transfer impact assessments and counterparty due diligence therefore belong to the Travel Rule procedure itself, not to a separate privacy annex.

How long must Travel Rule data be retained?

The five-year deletion obligation is technical, not merely procedural: Travel Rule records must be held in a system that actually enables their deletion at the appointed time, separately from the Article 68(9) MiCAR records and from AML documentation.

Wallet analytics and risk scoring: When does profiling arise?

Practically every CASP relies on an external blockchain analytics vendor that screens addresses and transactions against sanctions lists, links to illicit online markets and known fraud patterns, and generates risk scores used at client onboarding, in transaction monitoring and when terminating a client relationship. Where those scores are attributed to identified clients, this is profiling.

Screening mandated by AML law and by restrictive-measures obligations under the Travel Rule rests on a legal obligation; extended analytics that go beyond that mandate, including behavioural clustering and exposure scoring, rest on legitimate interests and require a documented balancing test with a proportionate retention period for the signals.

When does automated risk scoring fall under Article 22 GDPR?

The automated decision-making analysis developed by the Court of Justice for credit scoring applies here almost directly. In Case C-634/21 SCHUFA Holding (Scoring), the Court held that the automated generation of a probability value on which a third party relies to a significant degree itself constitutes an automated decision under Article 22(1) GDPR; a risk score from an analytics vendor that mechanically triggers a block, a withheld withdrawal or a termination fits that reasoning without difficulty.

In Case C-203/22 Dun & Bradstreet Austria the Court clarified that the data subject is owed a description of the procedure and principles actually applied, with trade secrets going to the supervisory authority or court for balancing rather than serving as grounds for a blanket refusal.

Anti-money laundering or commercial risk decision: Why does the distinction matter?

A problem characteristic of the crypto-asset market is the conflict between transparency towards the client and the tipping-off prohibition where a block stems from AML law. Two situations must be kept apart: where the restriction rests on a suspicious transaction report, the provider relies on the statutory restriction of data subject rights and documents it; where it rests on the provider’s own commercial risk policy, the client is owed a full explanation, human review and a route to contest the decision.

Merging the two categories and hiding commercial decisions behind AML secrecy is a practice the supervisory authority is most likely to challenge. For the provider this means maintaining two separate blocking procedures – one for AML cases and one for commercial decisions – together with documentation capable of showing which route a given case followed.

Biometric onboarding and proof-of-personhood under GDPR in Poland

Crypto onboarding leans heavily on biometric identification, from video verification and face matching to the most experimental proof-of-personhood schemes, based on iris scans and binding a biometric template to an on-chain identifier and a token allocation.

Biometric data processed for the purpose of uniquely identifying a natural person are special category data under Article 9 GDPR, and for commercial schemes the only realistic legal basis is explicit consent, with everything that entails: granularity, genuine voluntariness, effective withdrawability and a prohibition on collecting minors’ data.

What do the Worldcoin cases show about biometric data under GDPR?

The Worldcoin proceedings are today the benchmark for the European authorities’ approach to this boundary. On 6 March 2024 the Spanish data protection authority (AEPD) ordered Tools for Humanity, as a provisional measure under Article 66(1) GDPR, to cease collecting and processing personal data in Spain and to block the data already collected, citing insufficient information, the collection of minors’ data and the inability to withdraw consent; the measure was subsequently upheld by the courts. On 26 March 2024 the Portuguese data protection authority (CNPD) ordered a 90-day suspension of biometric data collection on similar grounds.

In December 2024 the Bavarian data protection authority, acting as lead supervisory authority, closed the main proceedings with a decision finding that iris codes had been processed unlawfully for passive comparison purposes and ordering their deletion, stressing that every user must have an unrestricted ability to exercise the right to erasure. The operator has appealed, seeking a ruling on whether the privacy-enhancing technologies it uses meet the Union’s legal threshold for anonymisation.

For any provider contemplating biometric onboarding or a token distribution tied to identity verification, the lessons are concrete: consent must be demonstrably informed and withdrawable, age controls must work before data are collected, and the DPIA must be kept current as the architecture changes. Privacy-enhancing technology is an argument to be proved, not a conclusion to be declared.

CASP authorisation and the end of the transitional period

As the transitional period expires – the period that covered Virtual Asset Service Providers (VASPs) operating before MiCAR became applicable on the basis of previous national rules (in Poland, entry in the VASP register) – those entities are applying for CASP authorisations across the European Union.

This is not a re-authorisation: the earlier register entries were not authorisations – a new authorisation must be obtained. The documentation itself deserves to be designed with data protection in mind.

Good-repute files should be collected according to the closed catalogue of Delegated Regulation (EU) 2024/1503, on defined templates; criminal record information should be handled in a separate Article 10 GDPR procedure; documentation on candidates ultimately not appointed should be kept on a shorter schedule than the files of the approved management body; and access to the dossier should be restricted rather than replicated across the firm’s general document workflow.

The exchange of documentation with competent authorities, ESMA and the EBA is likewise subject to data protection law. The same closed-catalogue principle for the information collected, discussed in our companion guide on the GDPR and the ECSP Regulation, applies here with equal force.

Compliance checklist for crypto-asset service providers in Poland

• Map processing operations by source: mandated by MiCAR, by the Travel Rule, by AML law, and chosen commercially; the legal basis follows the source.
• Separate the archives: Article 68(9) MiCAR records, Travel Rule records with five-year deletion, AML documentation and complaints files, each with its own retention and access regime.
• Treat every KYC–address link as creating personal data across the entire ledger, and design erasure as the severing of identifiability, in line with the EDPB Guidelines 02/2025.
• Keep Travel Rule data away from analytics and marketing; the statutory purpose limitation prohibits commercial use.
• Build transfer impact assessments into Travel Rule counterparty due diligence and document the logic for executing, rejecting, returning or suspending a transfer where third-country conflicts arise.
• Carry out a DPIA for wallet analytics and risk scoring; separate AML restrictions from commercial ones and give the latter a documented explanation and a human review route.
• For biometric onboarding, design consent that is informed, granular and withdrawable, with working age controls, and keep the DPIA current.
• Build the CASP application documentation on the closed catalogue of the technical standards, with an Article 10 GDPR procedure for conviction data and differentiated retention.
• Integrate DORA incident reporting with GDPR breach notification in a single process.

Practical example: Closing GDPR and Travel Rule compliance gaps before CASP authorisation

A provider applying for CASP authorisation was relying on compliance procedures and systems built while only the previous national rules applied. Travel Rule data sets were held indefinitely in the same repository as marketing analytics, a foreign analytics vendor received full KYC–address links without a processing agreement or a transfer assessment, and accounts were blocked automatically on the basis of the vendor’s risk scores, with a template message citing anti-money laundering law regardless of the actual basis.

The legal risks arising from these compliance gaps included a breach of the statutory purpose limitation, an unlawful third-country transfer, and an automated decision-making architecture with no review route.

In preparing the application, the archives were separated and scheduled deletion was implemented, the vendor relationship was completed with a processing agreement, a transfer impact assessment and a map of roles, and the blocking process was split into an AML-secrecy route and a commercial route with an explanation and human review. As a result, the risks were removed before the application file reached the authority.

Legal and compliance support for crypto-asset businesses in Poland

We support CASPs, applicants and entities entering the Polish crypto-asset market in the following areas:

• We assist in obtaining CASP authorisation before the KNF and in the transition from an entry in the VASP register to the MiCAR regime – we prepare the data protection part of the application, the Article 10 GDPR procedure for criminal record information, and the documentation for members of the management body;
• We design the data protection architecture for crypto-asset services – we draw up the record of processing activities, map the legal bases across MiCAR, the Travel Rule and AML law, and prepare retention schedules separated by purpose;
• We design on-chain and off-chain data architecture consistent with the EDPB Guidelines 02/2025 – we carry out DPIAs for CASP services and prepare clauses for node agreements;
• We design Travel Rule compliance – we define the scope of data collected, conduct counterparty due diligence, and prepare transfer impact assessments and the technical mechanisms for data deletion;
• We put wallet analytics and risk scoring on a defensible legal footing – we draw up balancing tests, Article 22 GDPR safeguards, decision-explanation procedures, and the separation of the AML and commercial routes;
• We advise on biometric onboarding and identity schemes – we select the legal bases under Article 9 GDPR, design the consent mechanism and carry out the DPIA;
• We put vendor and outsourcing compliance in order – we prepare processing agreements, DORA-compliant ICT contracts and transfer mechanisms;
• We handle incident and breach response – we manage DORA reporting, notifications to UODO and communications with clients.

Contact our crypto and data protection team

If you are applying for CASP authorisation in Poland, transitioning from an entry in the VASP register to the MiCAR regime, or providing crypto-asset services across the Union, our team will build the data protection layer into your CASP application file, reconcile the retention regimes imposed by MiCAR, the Travel Rule and AML legislation, and defend your on-chain architecture, the analytics tools you use and your onboarding design before the KNF and UODO.

We regularly support firms from the UK, the US and the EU entering the Polish market across the full spectrum of regulatory requirements: GDPR in Poland, MiCAR, the Travel Rule, PSD2/PSD3, DORA, NIS2, the AI Act and AML.

FAQ: GDPR, MiCAR and the Crypto Travel Rule in Poland