Asset-referenced tokens, or ARTs, are designed to hold stable value by referencing another value, right, or combination of assets, such as gold, crypto assets, or a basket of currencies. E-money tokens, or EMTs, aim to maintain stable value by referencing a single official currency. Under MiCA, that distinction determines which issuance and compliance rules apply.
How ARTs and EMTs differ in the MiCA rulebook
The legal distinction is simple but important. An asset-referenced token is stabilised by referencing one or more assets, while an e-money token is stabilised by referencing a single official currency. Under MiCA, that difference is not just semantic, it drives which issuance model, reserve expectation, redemption logic and compliance track the issuer must follow.
For practitioners, the key question is not whether a token aims to be stable, but what it is anchored to. If the reference is a basket, commodity, crypto asset or other combination of values, you are in ART territory. If the reference is one fiat currency, you are in EMT territory, which is generally treated more like a payments instrument with a narrower stability promise.
That distinction also affects how you explain the product to regulators, counterparties and customers. Marketing language that implies “stable coin” is not enough on its own, because MiCA looks through the label to the reference mechanism and the rights the holder receives.
What the reference asset changes in practice
The reference asset is the operational centre of gravity. For ARTs, stability depends on the quality, composition, custody and governance of the reference arrangement, because the token’s value is linked to something broader than one currency. For EMTs, the issuer is promising a closer currency substitute, so the practical focus shifts toward redemption at par in that currency and disciplined money-like handling.
This matters because the issuer’s risk profile is different. An ART can expose users to wider reserve composition risk, valuation risk and governance complexity. An EMT is narrower in design, but it creates stronger expectations around redeemability, liquidity and consistency with the referenced currency.
Under MiCA and DORA for Crypto-Asset Service Providers Guide, these stable-value products sit inside a wider operational and custody compliance environment, so the reference design should be assessed together with custody, controls and incident readiness rather than in isolation.
Why the distinction matters for issuance, redemption and controls
MiCA uses the ART and EMT split to separate products that may look similar to users but have different issuer obligations. The real compliance consequence is that the issuer must align reserve management, disclosure, redemption terms and governance to the token type actually being offered, not to the commercial wording in the white paper or app interface.
That is where implementation mistakes happen. Teams sometimes design a product as though it were a payment token, then discover that the underlying reserve structure, redemption promise or cross-asset reference pushes it into a different regime. The same issue appears in reverse when a fiat-pegged token is treated too casually and the issuer underestimates the operational discipline expected of an EMT.
If you are building or reviewing a product, Cybersecurity for Fintech Guide is a useful companion for the control environment around payment-like products, because the stability promise is only credible when reserves, APIs, fraud controls and operational access are tightly governed.
Risk and Threat Considerations
Misclassifying an ART as an EMT, or the other way around, can create regulatory exposure, disclosure gaps and poor product controls. The technical risk is not just incorrect paperwork, it is that the issuer may build the wrong reserve model, redemption workflow or control set for the promise being made to holders.
Failure mechanism: The issuer anchors governance to the wrong reference model, so reserve management, redemption rights, liquidity planning and communications do not match the actual token design.
Impact: That mismatch can trigger supervisory action, customer harm, broken redemption expectations and avoidable operational stress if the token comes under market pressure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token issuance and redemption workflows depend on secure credential and secret handling. |
| Recommendation — Harden token-related secrets and rotation to prevent misuse of issuance or redemption flows. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | MiCA token operations rely on governed access to reserve, issuance and redemption systems. |
| Recommendation — Apply access control to issuance, reserve and redemption systems according to role. | ||
| CIS Controls v8 | CIS-5 — Account Management | Operational control of issuer and treasury accounts is central to stable-token governance. |
| Recommendation — Review and restrict privileged accounts that can change token reserves or redemption settings. | ||
Practitioner Guidance
What to verify: Start with the token’s reference mechanism, not its branding. If the value promise depends on a basket, commodity or other non-fiat reference, treat it as an ART review path; if it references one official currency, treat it as an EMT review path.
Decision rule: If the white paper, reserve design and redemption promise do not all point to the same classification, pause launch readiness until the legal and control interpretation is reconciled. Ambiguity at design time is usually a governance defect, not a drafting detail.
Common mistake: Teams often focus on the stable value claim and ignore the reference structure that MiCA actually uses. That shortcut leads to misplaced controls, unclear disclosures and avoidable compliance rework.
Practitioner takeaway: The practical difference is not “two kinds of stablecoin”, it is “two different regulatory and control assumptions”, so classification must be locked before the product, reserve model and redemption process are finalised.
Related resources from NHI Mgmt Group
- What happens if a firm misclassifies an asset-referenced token as an e-money token under MiCA?
- How do security teams know if NHI tokens in AI workflows are actually under control?
- How should virtual asset platforms govern crypto listings under tighter regulatory rules?
- How should organisations govern virtual asset providers under the Travel Rule?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org