By 1 July 2026, crypto-asset service providers that were operating in the EU before the end of 2024 have to be fully authorized under MiCA, the EU's Markets in Crypto-Assets Regulation, or stop serving EU customers. MiCA doesn't replace data protection law; it plugs into it. Article 101 ties a provider's data handling to GDPR, and the EDPB oversees that overlap. So an exchange going through MiCA authorization is also, in effect, being asked to demonstrate mature data protection, and the public-facing part of that is the consent layer on its website.

Crypto sites are global by default, high-value targets for tracking, and built on data that ranges from ordinary contact details to KYC identity documents to on-chain identifiers. This guide covers how to run cookie consent on an exchange or Web3 property without tripping over the regulation stacking up around it.

Why MiCA raises the data-protection bar

MiCA is primarily a financial-services and market-integrity regulation, but it carries data-protection expectations that touch the website. The ESMA overview of MiCA sets out the authorization and conduct framework, and IAPP's analysis of data governance under MiCA makes the practical point: a MiCA-authorized provider is expected to run GDPR-grade privacy practices, including privacy-by-design and clear handling of personal data across KYC, marketing, and product.

MiCA also regulates marketing communications: they must be fair, clear, not misleading, and clearly identifiable as marketing. That connects to your cookie stack, because the retargeting and analytics that power crypto marketing depend on tracking that needs consent. If the marketing itself is regulated and the data feeding it needs consent, sloppy consent management becomes a compliance problem on two fronts at once.

GDPR and ePrivacy apply because your users are everywhere

A crypto exchange doesn't get to opt out of EU data law by being based elsewhere. If you offer services to people in the EU or monitor their behavior, GDPR's territorial scope reaches you, and the ePrivacy cookie rule applies to the tracking on your site. Practically:

Marketing and analytics cookies need consent. Retargeting pixels, ad-platform tags, and behavioral analytics require prior opt-in for EU and UK visitors, and an opt-out path for US state visitors.
Necessary cookies don't. Session and authentication cookies, security and anti-fraud tokens, and the state that keeps a trade or deposit flow working are strictly necessary and shouldn't be gated.
KYC and AML data is a legal obligation, not marketing. The identity data you collect to meet anti-money-laundering duties rests on legal obligation, but keep the marketing and analytics scripts away from the KYC flow so they can't scrape identity fields.

Our GDPR cookie compliance checklist covers the baseline, and because exchanges move data across borders, our EU-US data transfers guide is relevant to where that data ends up.

Wallet addresses and on-chain identifiers

Crypto adds a category of identifier most sites don't have: the wallet address. It's pseudonymous, but pseudonymous isn't anonymous. When a wallet address can be linked to a person (through KYC, an IP address, or clustering analysis), it's personal data under GDPR, and analytics or advertising tooling that ties browsing behavior to a wallet is processing personal data that needs a basis.

Two implications for the consent layer:

Don't feed wallet-linked behavior into marketing tools without consent. If your analytics associates on-chain activity or a connected wallet with a browsing session, that association is tracking, and marketing uses of it need consent.
Be careful with third-party analytics on connect-wallet flows. Web3 sites often load analytics that observe wallet connections. Treat those the way you'd treat any behavioral tracking: blocked until consent, and scoped so they don't capture more than they should.

One brand, every jurisdiction

Exchanges serve a global user base under a patchwork of rules: GDPR and ePrivacy in the EU and UK, US state privacy laws with opt-out and Global Privacy Control, and a growing list of national crypto and privacy regimes elsewhere. A single global banner will be wrong somewhere. EU and UK visitors need prior opt-in with no non-essential cookies firing until they agree; US state visitors need an opt-out model with a working Do Not Sell or Share path.

Geo-targeted consent matches each visitor to the framework for their location from one configuration, which our regional consent guide walks through. And because exchanges are financial platforms, the discipline that fintech sites apply to consent (keeping tracking away from regulated data, logging everything) carries over directly; see our fintech consent guide.

Proving consent when a regulator asks

MiCA authorization and GDPR both put you in a position where a regulator can ask you to demonstrate compliance, and consent is one of the things you'll need to evidence. A durable, timestamped record of what each user consented to, and the banner they were shown, is the difference between a defensible answer and a shrug. Server-side consent enforcement adds a second layer: rather than trusting the browser to have blocked the right tags, you can gate downstream processing on the recorded consent state.

Our consent logging guide covers what a defensible record looks like, proof of consent covers documentation, and server-side consent enforcement covers gating processing on consent rather than hoping the client behaved.

How CookieBeam handles crypto sites

CookieBeam manages the website consent layer. It doesn't run your KYC, AML, or MiCA authorization, but it targets the tracking-consent risks an exchange creates.

Script blocking that protects sensitive flows. Marketing, analytics, and session-recording scripts stay blocked until consent, so they can't scrape identity fields on KYC pages or wallet data on connect flows. Session, auth, and anti-fraud cookies run regardless, so trading and deposits never break.
Scanning across the funnel. The scanner crawls sign-up, KYC, and wallet-connect pages and flags new cookies and outbound connections when an integration changes.
Geo-targeted rules. EU/UK opt-in and US opt-out from one configuration, with each jurisdiction's framework matched to the visitor.
Durable records and server-side enforcement. Timestamped consent logs plus the ability to gate downstream processing on recorded consent, which supports both a MiCA and a GDPR inquiry.

Checklist for crypto exchanges and Web3 sites

Assume GDPR and ePrivacy apply. Serving EU users pulls you in regardless of where you're based.
Classify cookies correctly. Marketing and analytics need consent; session, auth, anti-fraud, and KYC-required cookies are necessary.
Keep marketing tags away from KYC and wallet-connect flows. Don't let pixels scrape identity or wallet data.
Treat linkable wallet addresses as personal data. Wallet-linked behavior in marketing tools needs a basis.
Geo-target the banner. EU/UK opt-in, US opt-out, one configuration.
Keep MiCA marketing rules in view. Marketing communications must be fair, clear, and identifiable, and the data feeding them needs consent.
Log consent and enforce it server-side. Keep timestamped records and gate processing on consent, not on the browser behaving.