Regulatory
What the regulation puts on the screen: a product guide to EU crypto rules
As of 1 July 2026 the transition period is over — the last national grandfathering regimes for crypto-asset service providers have expired, and any provider still serving EU users now has to be authorised under MiCA and compliant in full, with no grace period left to fall back on.
Pavel Chelyuskin
Founder
The regulation of a crypto product is usually discussed at the level of licensing, capital and reporting to the regulator. But a substantial part of what MiCA, the TFR, DORA and the EAA require lives not in the back office but on specific screens — in the wording of a risk warning, in the order of the KYC fields, in whether the spread is shown before the transaction is confirmed, or after.
The problem is that the law is organised by legal topic, not by user scenario. A requirement for the withdrawal screen and a requirement for the asset card may sit in different titles and different regulations — and no table of contents will assemble them into a coherent flow.
This UX checklist is built the other way round — by the scenarios a user passes through: onboarding, the purchase decision, exchange, withdrawal, storage, stablecoins, social features, marketing, complaints, incidents and delistings. Within each scenario: what has to reach the screen, symmetric do-and-don't examples and a reference to the specific article that requires it.
A separate thread runs through what MiCA doesn't require. The appropriateness test, client categorisation, a 24-hour pause for the first-time investor — these are the FCA's rules for the UK market, not MiCA. They reach European products by inertia — "because that's how the big platforms do it" — and add friction where the law asks for none. So every protective screen in the checklist carries a note of its source: MiCA, the TFR, MiFID II, the FCA, or a product decision.
Everything that never reaches the screen is set aside: licensing, prudential requirements, governance, reporting. These articles decide whether a product may exist. The checklist below decides what it looks like.
Stack:
- MiCA (Regulation (EU) 2023/1114)
- the Transfer of Funds Regulation / "Travel Rule" (Regulation (EU) 2023/1113)
- DORA (Regulation (EU) 2022/2554)
- European Accessibility Act (Directive (EU) 2019/882)
- GDPR (Regulation (EU) 2016/679)
- For comparison: MiFID II (crypto derivatives) and the FCA (UK)
1. Onboarding and registration
MiCA Art. 66(2) – all information to the client must be fair, clear and not misleading
No onboarding screen may mislead the user about the service.
Keep the service description free of profitability promises, and state licensing status factually in the "About" section, not as a selling point.
Put "Licensed in the EU" in large print on the first registration screen as a mark of quality. Authorisation is a regulatory formality, not an endorsement — presenting it as one risks breaching the Art. 66(2) duty to give clients information that is fair, clear and not misleading.
GDPR Art. 13 – information to be given when personal data are collected
KYC collects documents, selfies and address data — users should know why, on what basis, and for how long, before handing any of it over.
Show a short screen before the passport upload explaining why the data is needed, on what basis, and how long it is kept (five years, for AML purposes).
Bury the privacy policy link in the footer and give no explanation, on the upload screen itself, of what happens to the document next.
GDPR Art. 35 – data protection impact assessment
Large-scale KYC involving biometrics and screening needs an impact assessment before the flow is built — one that decides what's worth collecting, not a rubber stamp after the fact.
Let the assessment's outcome show in the design — only what verification requires, each field justified, biometrics used only where liveness checks are genuinely needed.
Collect a selfie video, a second document scan and proof of address "just in case", because the verification vendor happens to support it.
European Accessibility Act (EN 301 549, broadly aligned with WCAG 2.1 AA) – applicable from 28 June 2025
The EAA reaches a crypto product as an e-commerce service. Microenterprises — under ten staff, with turnover or balance sheet under €2m — are exempt outright. For everyone else: if onboarding isn't accessible, nothing else about the product's accessibility matters.
Provide full keyboard navigation, adequate contrast, alt text, and form errors that screen readers announce and link programmatically to their fields.
Bolt an accessibility overlay onto an inaccessible layout — it resizes text but fixes neither focus order nor semantics.
What MiCA doesn't require — a common mistake
MiCA has no appropriateness test, client categorisation, or cooling-off period for spot trading. Those come from the FCA (UK)'s cryptoasset promotion rules — a multi-question quiz plus a 24-hour cooling-off period for first-time investors — and, for derivatives, from MiFID II. Neither applies to plain spot trading in the EU.
Give every protective screen a note of its source standard, or mark it as a "product decision" in the specification.
Copy a large UK platform's onboarding quiz and 24-hour pause and impose both on the European product, where neither applies.
2. Reviewing the asset and making a purchase decision
MiCA Art. 66(3) – risk warning and a hyperlink to the white paper
A white paper must be reachable from the asset card, and the risk warning is a legal obligation, not a courtesy.
Link to the white paper from the asset card and place a brief risk warning next to the price.
Tuck the white paper into a "Documents" section in the site footer, leaving only a chart and a "Buy" button on the asset card.
MiCA Art. 6(5) – mandatory risk statements in the white paper
The white paper must say plainly that the asset may lose value, may not be transferable or liquid, and isn't covered by any compensation or deposit guarantee scheme. Echoing this, briefly, wherever the asset appears elsewhere in the product is good practice — though strictly the Art. 6(5) wording binds the white paper. Note, too, that Art. 81(9) makes much the same warning a screen requirement wherever the product gives advice or manages a portfolio, and Art. 66(3) requires a risk warning from every CASP in any case.
Keep the gist to one on-screen sentence, with detail behind a link (the FCA's technique: a short warning plus "Take 2 minutes to learn more").
Bury it in 1,200 words of legal text in a four-line scroll box, closed off by an "I have read and understood" checkbox.
MiCA Art. 6(4) – no assertions about future value
The white paper can't make claims about future value, beyond the mandatory statements above. The same discipline holds up well everywhere else the asset appears, even though the rule itself only binds the white paper.
Show historical performance and volatility as fact, with no extrapolation; allow sorting by performance, but don't default to it.
Feature "analyst forecast", "growth potential" or a "top performers this week" list on the home screen as a default buy recommendation.
MiCA Art. 66(5) – disclosure of climate impact
Each asset's consensus mechanism, and its principal adverse climate and environmental impacts, must be published prominently on the provider's website — the content and methodology set by the sustainability-indicators RTS (Reg (EU) 2025/422).
Give it a dedicated page, with an indicator on the asset card linking to it.
Publish a PDF report, formally, at a URL linked from nowhere.
MiCA Art. 72(2) – disclosure of conflicts of interest
Art. 72(2) requires the conflict to be disclosed prominently on the website (the detail is set by the conflicts-of-interest RTS, Reg (EU) 2025/1142). Whether it also reaches the asset card is a product decision — but a platform that lists its own token and says so only on a policy page is meeting the letter and missing the point.
Mark the native token with a clear affiliation flag in listings and on its card, plus a conflicts-of-interest page in a prominent place.
Put the native token at the top of the "popular" list with no mention that the platform itself issues it.
3. Purchase and exchange
MiCA Art. 66(2) and (4) – prices, costs and fees must be clear before the transaction, not after
Art. 66(4) requires published pricing policies; Art. 66(2)'s fair-and-clear duty is why the actual numbers belong on the amount-entry screen, not the confirmation screen.
Recalculate the final amount receivable, the rate, the commission and the spread live as the amount is entered.
Show only the rate on entry, reveal the commission at confirmation, and never show the spread at all — leaving the user to infer it by subtraction.
MiCA Art. 77(2)–(3) – firm price on exchange
Exchange providers must publish a firm price or pricing method, and execute at the price shown when the order becomes final.
Hold the price for a few seconds with a visible timer, then request a clear re-quote; show any slippage limit before confirmation.
Let the price move the instant "Confirm" is pressed, with no warning or re-confirmation, so the user only learns the final rate from the transaction history.
MiCA Art. 78(3) and (5) – execution policy and client consent
Clients must be given the order execution policy and give prior consent to it; executing outside a trading platform needs separate, express consent.
Use a dedicated consent screen during onboarding, with a short summary and a link to the full policy.
Bury the execution policy as a sub-clause of the general terms and treat a ticked "I accept the T&Cs" box as consent.
MiCA Art. 78(1) – best execution
Where the client gives a specific instruction (a limit price, say), the best-execution duty doesn't apply to that part of the order — and the user should know this.
State plainly, on the limit-order screen, that a specific price means execution to that instruction rather than under the best-execution policy.
Make the limit-order screen look identical to the market-order screen, leaving the user to assume the platform is always seeking the best price on their behalf.
MiCA Art. 13 – 14-day right of withdrawal
Only for crypto-assets bought directly from the offeror or via a placement service, and only before the asset is admitted to trading (Art. 13(4)) — this covers initial offers, not ordinary exchange purchases.
Give the buyer a 14-day timer and an accessible withdrawal button after an initial-offer purchase, refunding via the original payment method, free of charge.
Mention the right only in the PDF white paper and nowhere in the interface, leaving email to support as the only way to cancel — and only if the user knows the right exists at all.
MiCA Art. 76(13) – fee structures must not encourage disorderly trading
Art. 76(13) bites on the fee schedule itself: rebates and volume discounts must not reward churn or feed disorderly trading. Whether the rest of your engagement mechanics do the same job by other means is a product decision — no article will make it for you.
Keep fees simple and predictable; don't turn volume discounts into a game mechanic; show account statistics as results, not rankings.
Run leaderboards for trade count, streaks for daily activity, or bonuses for turnover — rewarding frequency rather than judgement.
4. Transfers and withdrawals
TFR Art. 14 – originator and beneficiary details
Required fields for the originator: name, wallet address or account number, plus one further identifier (address, document number, client ID, or date and place of birth). For the beneficiary: name and wallet address. There's no de minimis threshold — a €5 transfer carries the same information requirement as a €50,000 one.
Explain fields in one line ("required under the Transfer of Funds Regulation — this data goes to the receiving platform"); make recipient type (individual or legal entity) a segmented control, not a drop-down.
Spring seven new fields on the user with no explanation of why the form has tripled in size — it reads as arbitrary friction.
TFR Art. 14(5) and Art. 16(2) – verifying ownership of a self-hosted wallet above €1,000
For transfers of more than €1,000 to or from a self-hosted address, the provider must take adequate measures to assess whether the address is owned or controlled by the client — a cryptographic signature or a test transaction, say.
Verify the address once, whitelist it, and let the user simply select it from a list thereafter.
Make the user re-sign a message and wait for a test transaction every single week for the same personal wallet.
TFR Art. 17 – action on incomplete information
The transfer may be executed, rejected, returned or suspended.
Show a "transfer under review" status with an expected timeframe, a reason, and a clear next step.
Leave the transfer stalled with no status and no timeframe, forcing the user to contact support just to find out what's happening.
MiCA Art. 82 – transfer services
The client should understand the process and the fees for a transfer, as set out in the transfer-service agreement.
Show the network fee and platform fee separately, state the expected crediting time, and flag that the transaction is irreversible.
Merge fees into a single unexplained number and give no timeframe at all, leaving the user unsure whether to expect a minute or a day.
5. Asset storage: wallet and portfolio
MiCA Art. 75(1) and (5) – custody agreement and statement of position
Client positions sit in a register; a statement covering assets, balance, value and transfers goes out at least quarterly, and on request.
Make the quarterly statement downloadable from the portfolio section, with a notification when it's ready.
Skip the statement altogether — a common gap, since the requirement isn't anchored to any one screen and falls between design and compliance.
MiCA Art. 75(4) – hard forks and newly created rights
Assets created by a fork belong to the client by default. A custody agreement may say otherwise — but ESMA has held (Q&A 2290) that buried terms of service can't carry that derogation: the client must consent explicitly and affirmatively to the specific clause.
If you take the derogation, put it on its own screen with its own control, in plain words, and record the consent separately.
Fold "assets arising from a fork accrue to the platform" into clause 14.3 of the terms and treat the T&Cs tick as consent — ESMA has said, in terms, that this doesn't work.
MiCA Art. 75(9) – use of sub-custodians
Where a provider uses another crypto-asset service provider to custody client assets, it must tell clients so.
Use a dedicated screen naming the sub-custodian and explaining what that means for the client.
Mention sub-custody only as a sub-clause in the general terms, with the sub-custodian's name nowhere to be found.
MiCA Art. 70 – segregation of client assets and funds
Client funds may not be used for the platform's own benefit.
Disclose segregation in plain language in the security section, easy to find without searching.
Stay silent on the question every user has asked since the last wave of exchange failures: "Where is my money?"
6. Stablecoins and yield products
MiCA Art. 40 (asset-referenced tokens) and Art. 50 (e-money tokens) – prohibition on paying interest
Any reward tied to how long a token is held counts as interest. This isn't a UX question — it decides whether the product can exist at all.
If a feature has to go, explain honestly why, with a reference to the rule and reasonable advance notice.
Advertise "hold a stablecoin and earn 4% a year". This exact rule ended Coinbase's USDC Rewards in Europe on 1 December 2024; the customer emails went out in the last days of November, giving roughly three days' notice.
MiCA Art. 49 – right to redeem an e-money token at par value, at any time
Keep the redemption button always available, free of charge, with terms visible before the click.
Require a support ticket to redeem, give no timeframe, and reveal the fee only after the fact.
MiCA Art. 29 and Art. 53 – marketing of asset-referenced tokens and e-money tokens
Marketing must mention the right of redemption at par value — a duty on the issuer, though a CASP promoting someone else's stablecoin owes the same candour under Art. 66(2).
State the right to redeem at par value and link to the terms in every stablecoin promotion.
Advertise "stability" and "full reserve backing" without a word on how to get the nominal value back.
7. Social features: copy trading, leaderboards, signals
MiCA Art. 91(3)(c) – market manipulation
Voicing an opinion on an asset you hold, then profiting from the price move it causes, counts as manipulation unless you disclose the conflict at the same time.
Show the copy-trading leader's position automatically next to the signal, with the conflict disclosure inside the post itself, not as small print beneath it.
Rank a leaderboard by weekly return, add a "copy this trade" button, and skip both the position disclosure and the risk warning — a pump-and-dump design in all but name.
MiCA Art. 88 and ITS (EU) 2024/2861 – public disclosure of inside information
Where a platform admits a crypto-asset on its own initiative, it is the person seeking admission and must disclose inside information — a listing, say — publicly and without preferential access, in a dedicated, dated and timestamped section (the ITS sets the mechanics of the page). Two parts of Art. 88 bite on the screen: the disclosure may not double as marketing, and it must stay up for at least five years.
Keep a chronological disclosures section on the website, dated and timed, where listing announcements land at the same moment as everywhere else.
Let the listing announcement reach a private Telegram channel first and the website an hour later — by which time the price has already moved.
Let the disclosure page double as a promo surface (Art. 88 forbids combining the two), or roll it off after a quarter — it has to stay up for five years.
8. Marketing, promotions and referral programmes
MiCA Art. 7 – marketing communications
Must be marked as marketing, fair, clear and not misleading, consistent with the white paper, and carry the verbatim regulator disclaimer — none of it published before the white paper itself.
This covers landing pages, banners, push notifications, in-app promotions, social posts and influencer content wherever they promote a specific crypto-asset. Marketing of the platform itself — referral programmes, brand campaigns — falls under Art. 66(2) instead: the same fair-and-clear standard, but without the Art. 7 disclaimer.
Label the material as advertising with the disclaimer inside it, not in the landing-page footer; keep referral terms clear, and check the local position before paying for referrals at all — the FCA bans incentive schemes in cryptoasset promotions outright, and the AFM has treated referral payments as prohibited inducements.
Run an influencer "review" with no advertising label. Two cautionary examples worth knowing, even though neither was a MiCA enforcement action itself: the Dutch AFM fined trading platform BUX €1.6 million — imposed November 2024, published March 2025 — over payments to finfluencers and a refer-a-friend scheme, under the general inducements ban for investment services; and Spain's CNMV fined X (formerly Twitter) €5 million in 2025 under national advertising rules, for carrying adverts for an unauthorised crypto service.
MiCA Art. 66(2) – in-product marketing is still marketing
A promotional card in the app's feed is a marketing communication like any other.
Make the promotion visually distinct from analytics — a different background, a clear label, kept out of the general quote list.
Let the promoted asset's card look identical to the analytical selection, so users read the advert as the platform's own recommendation.
9. Complaints and support
MiCA Art. 71 and Commission Delegated Regulation (EU) 2025/294 (RTS on complaints-handling)
Filing a complaint is free, on the website or any device, through an easily accessible procedure and template.
- The RTS makes clear a client can't be forced to use the template;
- acknowledgement of receipt comes without undue delay;
- a decision follows within two months — extendable in exceptional cases, but only with reasons and a new date given to the client.
Give support a one-click complaints section, a form plus a free-text option, and an automatic acknowledgement with a reference number and expected review period.
Force complaints through the template alone (a direct breach), bury the form behind three layers of FAQ, and skip acknowledgement of receipt.
10. Incidents, delistings and feature closures
DORA Art. 19(3) – notifying clients of major ICT incidents, from 17 January 2025
Where an incident affects clients' financial interests, they must be told without undue delay what happened and what's being done about it.
Post a status page, an in-app banner, and an email — stating what happened, what it affects, and what the user should do.
Stay silent, or dress up "scheduled maintenance" as an explanation that explains nothing.
The delisting scenario — a consequence of MiCA, not a separate article
A widespread pattern across 2024–2025: EU exchanges delisted USDT because Tether never sought MiCA authorisation.
- Coinbase: moved earliest — restricted EEA users from trading or holding the affected stablecoins from 13 December 2024, ahead of the 30 December CASP deadline.
- Kraken: sell-only mode from 27 February 2025, trading fully suspended (including sell-only) from 24 March, full delisting 31 March.
- Crypto.com: new purchases stopped 31 January 2025, full delisting and automatic conversion of remaining balances by the end of Q1 2025.
Design the states in advance — a banner with the deactivation date, a "sell only" mode, and a screen offering a genuine choice: convert, withdraw to your own wallet, or do nothing and take the default conversion.
Force a conversion of balances on the platform's own rate and timetable, with no choice offered — the user loses control of the asset, and it's the best advertisement for self-custody the market has produced.
11. Advice and portfolio management
Applies only where the product gives advice or manages a portfolio — not to plain spot trading.
MiCA Art. 81 – suitability assessment
Assess knowledge, experience, objectives, risk tolerance and ability to bear losses. If it's not suitable, warn the client and don't recommend it — and review at least every two years.
Use questions with plausible wrong answers and concrete loss examples, with a genuine branch in the outcome — some users should fail.
Ask "Do you understand that crypto-asset values can fluctuate?" with only "Yes" and "Yes, completely" as options, or highlight the intended answer with a tooltip. The FCA found exactly this in its review: the assessment used as a tutorial, with leading questions engineered to get the user through it.
MiCA Art. 81(2) – nature of the advice must be disclosed
Before giving advice: is it based on a broad or a limited analysis, and is it independent?
State, before any recommendation, that the analysis is limited to the platform's own assets and that the advice isn't independent.
Present the recommendation as an objective analytical conclusion when it rests on a narrow set of the platform's own assets.
Cross-cutting requirements: check on every screen
Equivalence of buttons after a warning
Use two buttons of equal size and weight, differing only in colour.
Make "I understand the risks, continue" a full-width blue button and reduce "Cancel" to grey, size-eight text beneath it. That isn't a choice, it's a signpost — and the FCA found exactly this pattern in its review.
When the warning appears
Show the risk warning on the asset card and on the amount-entry screen, while the decision is still being made.
Show the modal on the confirmation screen, after the decision is made and the money already spent mentally — it gets closed unread and serves only as legal cover.
Layered disclosure
Put one sentence carrying the main risk on-screen, with a link to the full detail.
Rely on a wall of legal text and an "I have read and understood" checkbox — formally closed, but never actually read.
Accessibility (the European Accessibility Act, aligned with WCAG 2.1 AA)
Meet the requirements across every client-facing flow, and publish the accessibility information the EAA requires in your terms — in an accessible format, which is the part everyone forgets.
Make only the landing page accessible while onboarding, withdrawals and complaints are not — precisely where accessibility matters most.
Keeping the source of each requirement visible
Give every protective screen a note of what drove it — MiCA, the TFR, MiFID II, the FCA, or a proprietary product decision.
Carry UK-style restrictions in the EU "because that's how the big platforms do it", with no one able to explain why.
What isn't in this checklist
Articles that matter for compliance but don't dictate interface elements:
- authorisation and licensing (MiCA Art. 59–65)
- prudential requirements (MiCA Art. 67)
- governance (MiCA Art. 68)
- reporting to the regulator (MiCA Art. 69)
- outsourcing (MiCA Art. 73)
- wind-down plans (MiCA Art. 74)
- asset-referenced token reserves (MiCA Art. 36)
- significant asset-referenced and e-money tokens (MiCA Art. 43–47, 56–58)
- regulators' powers and sanctions (MiCA Art. 93–138)
- internal systems for detecting market abuse (MiCA Art. 92)
- incident-reporting deadlines to the regulator (DORA)
These decide whether a product may exist. The checklist above decides what it looks like.
What the checklist comes down to
Behind the forty-odd requirements sit a few simple disciplines: say the important thing plainly, say it while the decision is still open, show the conflict where it lives, leave the user a real choice. The screen changes — onboarding, exchange, withdrawal — the discipline doesn't.
The failures repeat just as reliably: the 1,200-word disclosure closed by an "I have read and understood" box; the blue "Continue" button with "Cancel" small and grey beneath it; the risk warning that appears only after the money is already spent. Each is a screen built to pass an audit rather than to be understood — and that gap is what most of MiCA's interface duties are really about.