DEV Community

Cover image for The Constraint That Actually Determines Your Crypto Product's Market (It Isn't Your Stack)
SparqCard
SparqCard

Posted on

The Constraint That Actually Determines Your Crypto Product's Market (It Isn't Your Stack)

If you're building anything in crypto payments, there's a constraint that shapes your addressable market more than any architectural decision you'll make, and it doesn't show up in system design discussions.

It's your licence.

This became unusually visible on July 1, 2026, when MiCA's transitional periods across the EEA closed permanently. Firms with authorisation kept serving European users. Firms without it stopped. No amount of technical quality changed which side of that line a company landed on.

Why this is a builder problem, not just a legal one

The instinct is to treat licensing as someone else's workstream — legal handles it, engineering ships product, they meet at launch. That framing breaks down once you understand the timelines involved.

Authorisation takes quarters to years depending on jurisdiction. Your product roadmap doesn't. If licensing is a parallel track that legal owns, you will build features for markets you can't serve and discover it late.

The practical version: your market map and your licensing map should be the same document.

How the EU structure actually works

Worth understanding the mechanics, because they're unusual compared to most regulatory regimes.

Passporting. A CASP authorisation from any single EU member state's national competent authority extends across all 27 member states. The home regulator notifies host regulators; no second application, no second fee. An EMI licence covers all 30 EEA states (EU 27 + Norway, Iceland, Liechtenstein).

This creates a genuinely unusual dynamic: jurisdiction selection is a high-leverage decision made once, with market-wide consequences.

Where firms actually went. Coinbase runs EEA operations from Ireland, Kraken from Ireland and Luxembourg, Bitvavo from the Netherlands, Bitpanda from Austria and Germany. As of early 2026 roughly 60 CASPs were authorised EU-wide — Germany 18, Netherlands 14, France 6, Malta 6, Finland 1.

Jurisdiction trade-offs are real. Lithuania historically offered faster processing for fintech entrants, but increased Bank of Lithuania scrutiny has lengthened timelines. Ireland is slower but produces a more credible authorisation, which matters for banking partnerships. Regulators expect actual EU decision-making — place of effective management, at least one EU-resident director — not a letterbox entity.

The licence type question

Two non-bank payment licences matter for most crypto payment products:

PI (payment institution) — for firms that only process payments. Lower requirements.
EMI (electronic money institution) — required for stored-value accounts, digital wallets, or prepaid products. This is the one most card products need.

If your architecture involves holding a user balance in any form, you're likely in EMI territory. That's worth knowing before you design the balance model, not after.

Where stablecoins intersect

MiCA classifies stablecoins referencing a single fiat currency as e-money tokens (EMTs), and only credit institutions or authorised EMIs may issue them in the EU.

Circle obtained an EMI licence from France's ACPR on July 1, 2024, which made USDC and EURC compliant from day one of the stablecoin regime. Some other stablecoins exited the EU market rather than pursue authorisation.

Practical consequence for anyone building payment flows targeting the EEA: you need both an authorised service provider and a regulated token. Integrating a stablecoin that withdrew from the EU market means that flow doesn't work there regardless of how clean your implementation is.

Reverse solicitation is not an architecture

You'll encounter reverse solicitation as an argument for serving EU users without EU authorisation. It's a narrow exemption applying only where the client made the initial unsolicited approach.

It is not a design pattern, and building product assumptions on top of it is fragile. After July 1, 2026, transacting through an unauthorised CASP in the EEA carries legal and operational exposure for both parties.

Another cycle is already queued

PSD3 and the Payment Services Regulation are expected to enter into force in late 2026 or early 2027. Existing EMI authorisations remain valid for 24 months afterward, then require re-authorisation under the new framework. Announced changes include adjusted capital requirements, enhanced safeguarding rules, mandatory IBAN-name verification, and a harmonised three-month authorisation timeline.

Mandatory IBAN-name verification in particular is a concrete engineering requirement, not just a policy item — worth tracking if you're designing payout flows now.

The takeaway

Regulatory capacity has become a competitive asset roughly comparable to engineering capacity in this space. That's an unsatisfying thing to conclude if you'd rather be solving technical problems, but the market reflects it: a firm with authorisation and an average product reaches more users than a firm with an excellent product and no licence.

Anyone here been through a CASP or EMI application recently? Curious how much the process actually constrained product decisions versus just delaying launch.

Top comments (0)