Stablecoins
Do EMIs need MiCA to handle stablecoins?
How e-money-institution status and MiCA’s EMT and CASP rules fit together.
By James Hickson · Updated 3 July 2026
Key takeaways
- Not necessarily as a separate step. An authorised EMI is already an eligible issuer of e-money tokens under MiCA. But issuing an EMT differs from providing crypto-asset services such as exchange or custody, which require separate CASP authorisation. Map each activity to the right permission, and take advice.
- Governing rule. MiCA — Regulation (EU) 2023/1114
- Who may issue an EMT. An authorised EMI or a credit institution
- EMI status. The gateway to issuing a single-currency stablecoin (EMT), not an automatic CASP permission
- Crypto-asset services. Exchange, custody, transfer and similar require separate CASP authorisation
- Common pitfall. Assuming EMI authorisation covers crypto-asset services it does not
- Status. General information, not legal advice — take your own regulatory advice
General information, not legal advice.
What is the relationship between an EMI and MiCA?
An electronic money institution (EMI) is a firm authorised under the EU e-money regime to issue electronic money and provide related payment services. That authorisation predates MiCA and sits alongside it. MiCA — the Markets in Crypto-Assets Regulation, formally Regulation (EU) 2023/1114 — did not replace the e-money framework. Instead, it built a bridge between it and the crypto-asset world by defining a category of token that behaves, in economic terms, like e-money on a distributed ledger.
That category is the e-money token, or EMT: a crypto-asset that aims to keep a stable value by referencing a single official currency, for example a euro-referenced or US-dollar-referenced stablecoin. MiCA generally reserves the issuance of EMTs to two kinds of entity — a credit institution, or an authorised EMI. In other words, if a firm wants to issue a single-currency stablecoin that falls within the EMT definition, holding EMI authorisation is one of the recognised routes to being permitted to do so. For many fintechs, EMI status is therefore the gateway to issuing a compliant stablecoin under MiCA rather than an obstacle to it.
This is worth stating plainly because the two regimes are easy to conflate. An EMI is not, by virtue of being an EMI, a crypto business. And a crypto business is not, by virtue of dealing in tokens, an EMI. MiCA connects the two by saying that the specific act of issuing an EMT should be carried out by an entity already subject to prudential and safeguarding discipline — which the e-money regime provides. The EMI's existing obligations around holding client funds, safeguarding and redemption map closely onto what MiCA expects of an EMT issuer, which is part of why the regulation drew the line where it did.
There are also additional, EMT-specific requirements layered on top. An EMI issuing an EMT will typically need to prepare and publish a crypto-asset white paper and notify its competent authority before offering the token to the public or seeking its admission to trading, and it must respect MiCA's rules on how the token is backed, redeemed at par and how reserve assets are held. These are general features of the regime rather than a complete checklist, and the precise obligations depend on the token, the currency referenced and the scale of the activity. The headline point stands: EMI authorisation is closely tied to the right to issue an EMT, but it comes with its own conditions that you should confirm against the current text and your regulator's guidance.
How does issuing an EMT differ from providing crypto-asset services?
This is the distinction that trips up most operators, and it is the single most important thing to get right. MiCA regulates two broadly different things. First, it regulates the issuance of certain tokens — asset-referenced tokens (ARTs) and e-money tokens (EMTs) — and who may issue them. Second, it regulates the provision of crypto-asset services to third parties, and it does so through a separate authorisation for crypto-asset service providers, known as CASPs.
Issuing your own EMT is an activity governed by the issuance rules and, as above, is generally open to credit institutions and authorised EMIs. Providing crypto-asset services is a different activity with a different permission. Crypto-asset services under MiCA include things such as operating a trading platform, exchanging crypto-assets for funds or for other crypto-assets, custody and administration of crypto-assets on behalf of clients, execution of orders, transfer services, and providing advice or portfolio management on crypto-assets. Carrying on those services by way of business generally requires CASP authorisation.
The practical consequence is that an EMI which only issues its own EMT is not, for that reason alone, a CASP. Issuing a token and running a service that lets other people trade, hold or move tokens are separate regulated acts. Equally, the relationship does not run the other way: being a CASP does not make a firm an EMI, and CASP authorisation does not, by itself, permit a firm to issue an EMT. The two permissions answer different questions — the first, 'may you create and put this stablecoin into the market?'; the second, 'may you provide these crypto-asset services to clients?'
It helps to think in terms of activities rather than firm labels. A single business might sit in one box, both boxes, or neither, depending on what it actually does. A fintech that issues a euro EMT and does nothing else with third-party crypto is on the issuance side. A firm that custodies and exchanges tokens for customers but issues nothing is on the services side and needs CASP authorisation. A firm that does both will generally need to satisfy both sets of requirements. Because the boundaries around what counts as a 'service' can be fact-specific, and because ART rules differ again from EMT rules, this is precisely the area where firms should verify their own analysis rather than rely on a general description.
When does an EMI also need CASP permissions?
An EMI is likely to need CASP authorisation, in addition to its e-money authorisation, when it provides crypto-asset services that go beyond simply issuing its own EMT. The trigger is the nature of the activity, not the fact that a token is involved. If the EMI starts doing things for clients that fall within MiCA's list of crypto-asset services, the issuance route no longer covers it.
Consider some realistic scenarios. An EMI issues its own stablecoin and lets customers redeem it at par — that redemption function is part of the issuance and EMT framework. Now suppose the same EMI also offers to hold a range of third-party crypto-assets on behalf of customers in wallets it controls. That looks like custody and administration of crypto-assets, a crypto-asset service. Suppose it also lets customers swap its stablecoin for other tokens inside its app, or matches buyers and sellers. That starts to look like exchange services or the operation of a trading platform. Each of those is on the services side of the line and would generally call for CASP authorisation.
The transfer of crypto-assets on behalf of clients is another activity to watch, as is any advice, order execution or platform operation. The point is not to memorise the list but to run each proposed feature through a simple test: is this the issuance and redemption of our own EMT, or is it a service we are providing to clients in relation to crypto-assets? Where the answer is the latter, CASP permissions come into view. Where a feature sits close to the boundary — for example, mechanisms that move tokens as an inherent part of redemption versus a standalone transfer service — the categorisation can be genuinely finely balanced, and a definitive view needs proper legal analysis of the specific design.
There is also a sequencing question. Authorisations take time and carry their own capital, governance and conduct requirements. A firm that expects to grow from pure issuance into a broader set of services should plan the permission architecture early, rather than discovering mid-build that a new feature has quietly moved it into CASP territory. None of the above should be read as a determination that any particular activity does or does not require authorisation in your case; treat it as a prompt for a proper mapping exercise with your advisers.
What does this mean in practice for a fintech weighing stablecoin activity?
In practice, the useful discipline is to map the activity to the permission before committing to a build. Start by writing down, in plain terms, exactly what the business intends to do with stablecoins. Are you creating a token and putting it into circulation? Are you holding tokens for other people? Are you moving them, exchanging them, or running a venue where others transact? Each of those questions points to a different part of MiCA, and the answers together define your regulatory footprint.
If issuance is on the table, remember that the EMI or credit-institution route is the recognised path for an EMT, and that it brings its own obligations. Expect to deal with white paper preparation and notification to the competent authority, rules on how the referenced currency is backed and redeemed at par, and requirements around how reserve assets are held and safeguarded. These sit on top of the safeguarding and prudential duties an EMI already carries under the e-money regime. The specifics vary with the token and the jurisdiction, so confirm them against the current regulation and your regulator's expectations rather than working from a summary.
If crypto-asset services are on the table, the CASP framework is the relevant one, with its own authorisation, governance, conduct and prudential requirements. And if both are in scope, plan for both from the outset. A common and avoidable mistake is to assume that one authorisation implicitly grants the other — that holding EMI status covers customer custody or exchange, or that a CASP licence lets you mint an EMT. It does not, in either direction. Building the wrong assumption into a product roadmap is expensive to unwind.
Two further practical points are worth holding in mind. First, timelines: authorisation and the associated build-out of compliance, risk and reporting functions are not quick, so the permission you need should be identified before engineering commitments are locked in. Second, proportionality: not every business that wants stablecoin settlement in its product needs to become an issuer or a CASP itself. The regime distinguishes between doing the regulated activity and consuming a regulated service provided by someone else — which is where a settlement partner can change the calculus entirely. As with everything on this page, this is general information rather than advice on your particular facts.
How does a regulated settlement partner fit in?
For many fintechs and EMIs, the question is not really 'how do we obtain every permission stablecoins might touch?' but 'how do we offer stablecoin settlement to our customers without rebuilding our licensing from scratch?' Those are different problems. Becoming an EMT issuer or a CASP is the right answer for firms whose core proposition is the regulated activity itself. For firms whose core proposition is something else — a payments product, a marketplace, a treasury workflow — accessing compliant stablecoin settlement through a regulated provider is often the more sensible route.
Xchange360 operates as a regulated provider, holding authorisations that include Switzerland ARIF (registration 4572), Canada FINTRAC MSB registration, and a Costa Rica registration. Working with a partner of this kind lets a business plug stablecoin settlement into its own product while the regulatory and operational weight of the underlying activity sits with the provider. That can shorten the path to launch and reduce the compliance surface a firm has to own directly, though it does not remove the firm's own obligations under whatever regime applies to it.
This is not a way to sidestep regulation, and it should not be presented as one. A firm still needs to understand its own status, its own customer-facing obligations, and how the partnership is structured. What a regulated settlement partner does is let a business consume a compliant service rather than construct the full permission set itself — which, for a firm whose ambitions do not extend to becoming an issuer or a CASP, can be the difference between shipping a stablecoin feature this year and spending that year in an authorisation process.
The right choice depends on strategy. If issuing your own EMT is central to the business, pursue the EMI or credit-institution route and the EMT obligations that come with it. If providing crypto-asset services is central, pursue CASP authorisation. If stablecoin settlement is a feature rather than the business, a regulated partner is worth serious consideration. In every case the starting point is the same: map the activity to the permission, and take your own regulatory advice on your specific facts. Nothing here is legal advice — it is general information to help you frame the right questions.
FAQ
Common questions
Is an EMI automatically allowed to issue a stablecoin under MiCA?
An authorised EMI is one of the recognised issuers of an e-money token under MiCA, alongside credit institutions, so EMI status is the gateway to issuing a single-currency stablecoin. It is not automatic in the sense of being obligation-free: expect white paper, notification and reserve or redemption requirements. Confirm the specifics and take advice.
Does holding EMI authorisation also make a firm a CASP?
No. EMI authorisation relates to e-money and, under MiCA, to issuing an e-money token. Crypto-asset services such as exchange, custody and transfer require separate CASP authorisation. An EMI that only issues its own EMT is not automatically a CASP. If it provides crypto-asset services to clients, it will generally need CASP permissions too.
What is the difference between an EMT and an ART under MiCA?
An e-money token (EMT) references a single official currency and is generally issued by an EMI or credit institution. An asset-referenced token (ART) references a basket, other assets or a mix, and is governed by a distinct set of rules. The two categories differ in their issuance and ongoing requirements, so the correct classification of your token matters. Take advice on which applies.
If we only issue our own stablecoin, do we need CASP authorisation?
Issuing your own EMT sits within MiCA's issuance rules rather than the crypto-asset services rules, so issuance alone does not, by itself, make you a CASP. But if you also custody, exchange, transfer or otherwise provide crypto-asset services to clients, those activities generally require CASP authorisation. The trigger is the service, not the token. Map each feature carefully.
Can we offer stablecoin settlement without becoming an issuer or a CASP ourselves?
Often, yes. A business whose core proposition is not the regulated activity can access compliant stablecoin settlement through a regulated provider rather than obtaining every permission itself. Xchange360 is a regulated provider (Switzerland ARIF 4572, Canada FINTRAC MSB, Costa Rica). This does not remove your own obligations, so understand your status and structure the arrangement with advice.
Is this page legal advice on whether we need MiCA authorisation?
No. This is general information about how MiCA (Regulation (EU) 2023/1114) treats EMIs, EMT issuance and crypto-asset services. It is not legal or regulatory advice, and edge cases can turn on specific facts. Map your intended activities to the relevant permissions and take your own regulatory advice before acting. Requirements can change, so verify against current sources.