DEV Community

Azalea
Azalea

Posted on

Your "Licensed" Badge Is Doing More Work Than It Should

A lot of crypto apps in Europe now show some version of the same line near the buy button: "Licensed under MiCA." It's true, it's reassuring, and a surprising number of users read it as "this is safe to buy."

That's not what it means. And if you build these products, the gap between those two readings is partly a design problem.

I wrote earlier about what MiCA changed after July 2026. This post is narrower. It's about how a compliance fact turns into a trust signal on screen, and how to keep it honest.

What the badge actually certifies

MiCA regulates the operator, not the asset. A crypto-asset service provider gets authorized after meeting rules on capital, governance, custody of client assets, complaints handling and disclosure. Since July 1, 2026, no transition period is left anywhere in the EU, so a company without that authorization shouldn't be serving EU customers at all.

So the badge says: this company is supervised and accountable.

It doesn't say:

  • the asset is protected (there's no deposit guarantee for crypto);
  • the user was checked for whether they understand the product;
  • the user controls the coins.

Users don't read regulation text. They read your UI. If the license badge sits right next to the "Buy BTC" button with nothing else around it, you've made a claim you didn't intend.

Users are being told to check things your product should make easy

Consumer guides have started telling people exactly what to verify before using a platform. A Spanish explainer on what MiCA means for people who use crypto in 2026 is a good example. Its advice comes down to a short list: confirm the platform is authorized, understand which stablecoin you hold, check the destination address and network before sending, keep records for taxes, and remember that the regulation doesn't make crypto a safe investment.

Read that list as a product spec. Every item is something your app can support or quietly make harder.

1. Make the license verifiable, not decorative

A badge that just says "Licensed" is an image. A useful one names the regulator and the license number, and links to the public record.

type LicenseInfo = {
  regime: "MiCA";
  authority: string;      // e.g. "AMF (France)"
  licenseId: string;
  registerUrl: string;    // national register or ESMA's list
  homeState: string;      // where the passport comes from
};
Enter fullscreen mode Exit fullscreen mode

The homeState field matters more than it looks. A MiCA license works across the EU, so a user in Spain may be using an app supervised in Malta or France. Say so. ESMA keeps a central MiCA register you can point to.

2. Keep the badge and the risk warning apart

Put the license and the price-risk warning in separate places, with separate visual weight. When they share a card, users tend to read the badge as cancelling the warning.

A plain line works better than legal copy: "Our license covers how we hold and handle your assets. It doesn't protect you from price drops."

3. Say who holds the keys, in the product, not the terms

"Custodied by us" and "in your wallet" are different products. Some licensed services in Europe don't give users keys and only allow withdrawals to addresses at approved providers. That's a legitimate setup, but users should learn it before buying, not when they try to leave.

Show withdrawal rules on the asset page:

{
  "custody": "platform",
  "withdrawals": {
    "selfCustody": false,
    "allowedDestinations": "approved_providers_only",
    "networks": ["bitcoin", "ethereum"]
  }
}
Enter fullscreen mode Exit fullscreen mode

I covered the pre-send side of this in What a Crypto App Should Do Before You Press "Send". The same idea applies one step earlier, at purchase.

4. Treat stablecoin support as something that can change

Tether never applied for MiCA authorization, so licensed platforms have been phasing out USDT for EU users. ESMA told them to finish by January 8, 2027, and some exchanges moved faster, converting leftover balances into USDC after a deadline.

Most users found out from an email. A better pattern is a status field per asset that the UI can surface early:

type AssetSupport =
  | { status: "supported" }
  | { status: "deprecating"; until: string; convertsTo?: string }
  | { status: "withdraw_only"; until: string };
Enter fullscreen mode Exit fullscreen mode

Meanwhile USDC moves the other way. The European Banking Authority classified it as the EU's first "significant" e-money token, with direct EBA supervision of its reserves from November 12, 2026. That's worth reflecting in your asset info too.

5. Build tax records in, because the tax office already has them

Under DAC8, platforms collect users' tax residence and report their transactions from January 1, 2026, with the first reports sent in 2027. Your users' tax authorities will see their trades. Many users still won't have their own records.

A one-click export (date, pair, amount, price, fee, network, tx hash) costs little to build and saves people a lot of pain in spring. It's also one of the items on every consumer checklist, so it reads as care rather than a feature.

The short version

A license tells users the company is accountable. Your interface decides whether they think it means more than that. Name the regulator, separate the badge from the risk, show custody and withdrawal rules up front, warn before an asset loses support, and give people their records.

None of this is required by MiCA in exactly this form. It's just what users are now being told to look for.

Top comments (0)