COMPLIANCE ALERT
MiCA’s CASP obligations have been fully applicable since 30 December 2024. Every crypto-asset admitted to trading on an EU-licensed exchange must now pass through a documented Article 76 suitability framework — including stablecoins listed prior to MiCA’s applicability date. ComplyFactor provides specialist MiCA AML advisory, AML programme development, and fractional MLRO services for CASPs building and stress-testing their token admission frameworks. Contact us here.
1. The Operational Problem CASPs Are Facing Right Now
Every compliance officer at a MiCA-authorised centralised exchange — or at an exchange going through the MiCA authorisation process — is currently navigating the same core operational challenge: how do you build a token admission framework that satisfies MiCA’s Article 76 obligations, manages the legal uncertainty around non-MiCA-compliant stablecoins, and remains commercially workable?
The challenge is compounded by the fact that MiCA came into full force on 30 December 2024 with a pre-existing crypto market that had been operating for years without any of these structures in place. Exchanges that had been listing hundreds of tokens — including major stablecoins like USDT, DAI, and USDS — suddenly found themselves operating under a regulatory framework that imposed specific pre-listing obligations, ongoing monitoring requirements, and the possibility that some of their most liquid trading pairs might need to be reviewed or removed.
The legal debate around whether own-initiative listings of non-MiCA-compliant EMTs are permissible — the subject of Article 1 in this series — is important, but it is in one sense a secondary question for the compliance function. The primary question is: whatever the outcome of that debate, what are your non-negotiable obligations under MiCA when operating a trading platform, and are your systems, policies, and procedures built to meet them?
This article answers that question in full, drawing directly on MiCA’s Title V provisions, the Article 76 suitability framework, and the AML/KYC obligations that apply to every crypto-asset admitted to trading — regardless of whether the token’s issuer is MiCA-compliant, non-identifiable, or based entirely outside the Union.
For the foundational legal debate around EMT classifications and the own-initiative listing controversy, see ComplyFactor’s MiCA stablecoin listings analysis. This article focuses on the operational compliance architecture that applies regardless of where you land on that interpretive question.
2. Which CASPs Does the Admission-to-Trading Framework Apply To?
Before constructing a compliance framework, every CASP must first answer a structural question: does the admission-to-trading framework under MiCA Article 76 apply to your specific business at all?
MiCA defines a trading platform for crypto-assets as one or more multilateral systems that bring together or facilitate the bringing together of multiple third-party purchasing and selling interests in crypto-assets, in a way that results in a contract — either by exchanging crypto-assets for funds or by exchange of crypto-assets for other crypto-assets. In operational terms, this describes a centralised exchange with an automated order book system: a central limit order book (CLOB), a request-for-quote system, or equivalent multilateral matching mechanism.
The admission-to-trading framework — and specifically Article 76 — applies exclusively to CASPs that are authorised to operate a trading platform as their licensed crypto-asset service. CASPs that hold other service authorisations are not operating trading platforms in the MiCA sense, and the admission-to-trading analysis does not apply to them in the same way. Specifically:
CASPs offering exchange of crypto-assets for funds or other crypto-assets (without a multilateral system) are providing a bilateral exchange service. When such a CASP provides a swap of USDT for ETH, no admission to trading is occurring — it is a bilateral transaction between the CASP and its client. The Article 76 framework does not apply, though the CASP’s general AML/KYC obligations and the Article 66(3) whitepaper reference and Article 66(5) environmental disclosure obligations do.
CASPs offering custody and administration of crypto-assets are custodians. Adding a token to your custody service is not admitting it to trading. The Article 76 framework does not apply, though again the Article 66 obligations do.
CASPs offering transfer services are similarly outside the admission-to-trading framework. A transfer service provider including USDT in the scope of its transfer service is not listing it on an exchange.
CASPs operating trading platforms — centralised exchanges with order book matching — must comply with Article 76 in full for every crypto-asset admitted to trading on that platform.
For many larger entities, the question is complicated by the fact that a single corporate group may hold multiple CASP authorisations and operate multiple service types. Revolut’s situation — USDT maintained on its exchange service but removed from its trading platform — illustrates exactly this structural nuance in practice. The compliance architecture must be built service-by-service, not group-wide.
3. The Distinction Between Listing and Offering Services
A further structural distinction that compliance officers must internalise is the difference between admitting a crypto-asset to trading and offering crypto-asset services in relation to a crypto-asset that is already in circulation.
Admission to trading is a specific act: it is the decision to include a crypto-asset in the pool of assets that can be bought and sold on your multilateral trading system. It is a formal, gatekeeping decision that triggers Article 76’s pre-admission obligations.
Offering crypto-asset services in relation to a token that is simply in circulation in the market — providing custody of USDT held in a client’s wallet, executing a transfer of DAI between addresses, or offering exchange of USDS for EUR as a bilateral transaction — is a different category of activity. These are service activities, not admission decisions, and they do not require the full Article 76 suitability process.
This distinction has practical importance in several directions. First, it means that non-trading-platform CASPs can service most common stablecoins without running the Article 76 analysis. Second, it means that for trading platform operators, the Article 76 obligation is triggered at the point of the admission decision — the listing — not at the point of every subsequent trade. Third, it clarifies that a token that was listed before MiCA came into force does not necessarily need to go through a fresh admission process each time a trade occurs, but does need to be reviewed under the Article 76 framework as part of the platform’s post-MiCA operating rules implementation (addressed in Section 4 below).
4. Pre-Existing Listings: What Happens to Tokens Already on Your Platform?
One of the most practically pressing questions for compliance officers at exchanges that were operating before 30 December 2024 is what to do with tokens that were already listed when MiCA came into full force.
MiCA Article 149(2) states that the Regulation applies from 30 December 2024. For service providers that were already operating trading platforms before that date under transitional arrangements — or that operated without authorisation in member states that did not have an equivalent national regime — the position is that once the CASP obtains MiCA authorisation, all of its crypto-asset admissions to trading must comply with MiCA going forward.
The BCAS legal opinion addresses this specifically: once a trading platform becomes authorised as a CASP, any admission to trading of crypto-assets needs to comply with MiCA requirements, meaning that crypto-assets that were previously admitted to trading when the platform was not yet a CASP would need to undergo the admission-to-trading process afresh to comply with MiCA. This is a significant compliance commitment — it means that every token on your order book at the point of authorisation requires a retrospective Article 76 review.
In practice, this creates an immediate prioritisation challenge. Exchanges with hundreds of listed tokens cannot overnight conduct full suitability assessments for every asset. A proportionate, risk-based approach to the retrospective review is therefore essential:
Priority Tier 1 — Stablecoins (EMTs and ARTs): These are the highest regulatory sensitivity assets given the Title III/IV debate and the ESMA statement. Stablecoin suitability assessments — covering the issuer’s authorisation status, reserve structure, AML risk profile, and technical reliability — should be completed first.
Priority Tier 2 — High-volume, high-liquidity tokens: Major crypto-assets by trading volume represent the highest AML risk in absolute terms. BTC, ETH, major altcoins by market cap should be reviewed in the second tier.
Priority Tier 3 — Lower-liquidity tokens: Long-tail tokens with lower trading volumes can be reviewed on a rolling basis, subject to the overall programme being completed within a defined and documented timeframe.
This risk-based phased approach should be documented in writing and approved at board or senior management level. An NCA that reviews your token listing programme will want to see evidence of a structured, deliberate approach — not a haphazard or indefinitely deferred one.
5. Article 76(2): The Suitability Assessment Framework
MiCA Article 76(2) imposes a mandatory pre-admission suitability assessment obligation on every CASP operating a trading platform. Before admitting any crypto-asset to trading, the CASP must assess:
(a) Whether the crypto-asset complies with the operating rules of the trading platform;
(b) The reliability of the technical solutions used in relation to the crypto-asset — including whether the underlying smart contracts have been audited, whether the protocol has a track record of secure operation, and whether the technical infrastructure is sufficiently robust;
(c) The potential association of the crypto-asset with illicit or fraudulent activities — covering money laundering, terrorist financing, fraud, market manipulation, and sanctions evasion risks; and
(d) The experience, track record, and reputation of the issuer and its development team, as applicable.
Several critical points about the scope of this obligation deserve emphasis.
First, Article 76(2)’s suitability assessment applies to all crypto-assets without exception — whether or not a MiCA-compliant whitepaper has been published. The assessment is not conditional on issuer authorisation status. A CASP admitting DAI to trading on its own initiative must conduct the suitability assessment under Article 76(2) regardless of whether the Sky DAO holds any MiCA authorisation.
Second, the suitability assessment must be conducted before admission to trading. It is a pre-listing gate, not a post-listing review. A CASP that admitted tokens to trading before MiCA’s applicability date must treat its retrospective review as a retroactive application of the pre-listing standard — which creates an obligation to delist any token that fails the assessment, not merely to document the failure.
Third, the suitability assessment must be documented in writing and retained as part of the CASP’s records. This is not a mental or informal exercise. It is a structured, written assessment that must be producible to the NCA upon request.
Fourth, the assessment must cover the issuer’s track record and reputation — but the BCAS opinion correctly notes that where an issuer is non-identifiable (as may be the case with the Sky Protocol), this element is assessed in relation to the protocol and development team as applicable. The non-identifiable issuer question does not eliminate the Article 76(2) obligation — it requires the CASP to assess what can be assessed with the information available.
PRO TIP
The Article 76(2) suitability assessment is not a pass/fail checkbox exercise. It is a substantive analytical process that should produce a written assessment document — analogous to a credit committee memo or an investment due diligence report — covering each of the statutory criteria. For high-profile stablecoins like USDT, DAI, and USDS, this document should be detailed enough that a regulator reading it can understand the basis for your listing decision, the risks identified, the mitigants in place, and the ongoing monitoring framework you have established.
6. Breaking Down the Suitability Assessment: Five Critical Dimensions
A robust Article 76(2) suitability assessment for a stablecoin should address the following five analytical dimensions in depth:
Dimension 1: Technical Reliability and Smart Contract Security
For stablecoins built on public blockchains, technical reliability assessment must cover: the smart contract architecture and whether it has been independently audited by reputable security firms; the protocol’s track record — how long it has been operating, whether there have been exploits or security incidents, and how governance has responded to vulnerabilities; the upgradeability architecture (upgradeable contracts introduce governance risk that immutable contracts do not); and the reliability of any oracle infrastructure used in price feeds or liquidation mechanisms.
For DAI and USDS, the Sky Protocol has been audited extensively by ChainSecurity and Cantina across multiple protocol modules — the LitePSM, the Endgame Launch contracts, the lockstake module, and others — providing strong technical reliability evidence. Annex C of the BCAS opinion contains a comprehensive list of audit reports that a CASP compliance team can reference directly.
For USDT, Tether’s technical infrastructure on Ethereum is mature and battle-tested with many years of operation, though the centralised architecture means that the technical risk profile includes counterparty risk on the Tether issuer entity itself.
Dimension 2: AML, Fraud, and Illicit Finance Risk
This is the most substantive analytical dimension for stablecoins. The assessment must evaluate: the degree to which the token has been associated with money laundering, sanctions evasion, ransomware payments, or fraud typologies in publicly available intelligence; the availability of on-chain analytics tools to monitor flows involving the token; the token’s geographic distribution and any associations with high-risk jurisdictions; and any regulatory actions or sanctions designations that have named the token or its issuer.
USDT has been the subject of extensive regulatory and law enforcement attention globally as the dominant stablecoin used in illicit finance typologies identified by FinCEN, FATF, and Europol. This does not make USDT unlawable — it means the AML risk assessment must be substantive, the blockchain analytics monitoring capability must be robust, and the CASP’s transaction monitoring programme must specifically address USDT-related typologies. ComplyFactor’s Europol SOCTA 2025 analysis and FinCEN advisory coverage provide relevant contextual intelligence for this assessment.
DAI and USDS present a different risk profile: their DeFi architecture means that issuance and redemption can occur without identity verification, and the protocol-level permissionlessness creates challenges for tracing the origin of funds deposited as collateral. The suitability assessment must address how your platform’s KYC and transaction monitoring framework manages these specific risks.
Dimension 3: Issuer Experience, Track Record, and Reputation
For identifiable issuers like Tether, this dimension covers Tether Limited’s corporate history, the NYAG settlement and its terms, the CFTC enforcement action, Tether’s reserve composition disclosures and attestation history, and the overall trajectory of its regulatory relationships globally.
For the Sky Protocol’s DAI and USDS, where the issuer identity is itself contested, this dimension covers the protocol’s history since MakerDAO’s founding in 2014 — one of the earliest and most resilient DeFi protocols — the governance token holder community’s track record in managing protocol parameters, the development team’s reputation in the DeFi space, and the protocol’s track record through multiple market stress events including the March 2020 crypto crash and the March 2023 USDC depegging event.
Dimension 4: Regulatory Status and Compliance with the Platform’s Operating Rules
This dimension requires the CASP to assess whether the token’s issuer or any associated party is subject to regulatory action, sanctions, or enforcement in any jurisdiction that would create compliance concerns for the platform. It also requires the CASP to assess whether listing the token would breach any of its own internal operating rules — including rules required by Article 76(1)(a) about whitepaper availability in the cases required by MiCA.
For stablecoins where the whitepaper obligation does not apply because neither an offer to the public nor admission-to-trading seeking has occurred (per the BCAS analysis), the operating rules must specifically note that a MiCA-compliant whitepaper is not required in these circumstances — while still requiring the CASP to reference any available whitepaper per Article 66(3).
Dimension 5: Market Integrity and Manipulation Risk
Stablecoins present specific market integrity considerations distinct from volatile crypto-assets. The assessment should address: the liquidity depth of the stablecoin on the platform relative to its overall market liquidity; the risk of artificial price manipulation during periods of peg stress; the potential for wash trading in stablecoin pairs; and any concentration risk if a small number of large holders can meaningfully impact on-platform pricing.
7. Article 76(1)(a): Operating Rules and the AML/KYC Requirement
Article 76(1)(a) of MiCA requires every CASP operating a trading platform to have in place written operating rules that set out the approval processes applied before admitting crypto-assets to trading. These operating rules must specifically include:
Customer due diligence requirements commensurate to the money laundering or terrorist financing risk presented by the applicant, in accordance with Directive (EU) 2015/849 as amended by Directive (EU) 2018/843 — the EU AML Directive framework. This is not merely a MiCA concept — it integrates the EU’s AML/CTF obligations directly into the token admission process.
A prohibition on listing tokens where no corresponding MiCA-compliant whitepaper has been published in the cases required by the Regulation. This provision deserves careful parsing. It does not say a whitepaper is always required. It says a whitepaper is required in the cases required by the Regulation — i.e., where an offer to the public was conducted in the Union, or where a person sought admission to trading, and the relevant whitepaper was accordingly required to be published. If no such offer or seeking has occurred, the whitepaper obligation under Titles III/IV was never triggered, and the operating rules must reflect this conditional structure accurately.
The operating rules document is not a boilerplate exercise. It is the foundational governance document for your token listing function, and it will be reviewed by your NCA as part of any supervisory assessment. It should address: the composition and mandate of your token listing committee; the process flow from initial identification of a token through due diligence, legal review, suitability assessment, and final listing approval; the AML/CTF risk assessment methodology and how it feeds into the listing decision; the criteria for declining or deferring a listing; the ongoing monitoring obligations post-listing; and the criteria and process for delisting.
For CASPs that do not yet have a formal written token listing policy meeting these requirements, building one is a regulatory priority. ComplyFactor’s AML compliance programme services and AML audit services support exchanges in designing and validating these frameworks.
COMMON MISTAKE
Many exchanges are drafting operating rules that simply state “tokens must have a MiCA-compliant whitepaper” as a blanket listing requirement. This is both over-inclusive and legally imprecise. MiCA Article 76(1)(a) requires that the operating rules state a token is not to be admitted to trading where no whitepaper has been published “in the cases required by MiCA” — which is a conditional, not an absolute, requirement. An overly simplistic blanket whitepaper rule would prevent your exchange from listing Bitcoin, Ethereum, Solana, and virtually every DeFi protocol token — none of which have MiCA-compliant whitepapers. The operating rules must reflect MiCA’s conditional architecture accurately.
8. Building a MiCA-Compliant Token Listing Policy
A MiCA-compliant token listing policy is the master governance document that operationalises your Article 76(1)(a) operating rules and Article 76(2) suitability assessment obligations. It should be a standalone policy document, approved at board level, and reviewed at least annually or upon material changes to the regulatory environment.
A well-structured token listing policy for a MiCA-regulated trading platform should contain the following sections:
Section 1 — Purpose and Scope. Define the policy’s purpose (compliance with MiCA Article 76), the specific crypto-asset service it governs (operation of a trading platform), and the assets to which it applies (all crypto-assets admitted to trading on the platform, including pre-MiCA listings subject to retrospective review).
Section 2 — Token Listing Committee. Define the composition, quorum requirements, voting mechanism, and mandate of your token listing committee. At minimum this should include the Chief Compliance Officer (or MLRO), a representative from legal, a representative from technology/product, and a senior business stakeholder. The committee must have a formal written record of every listing decision.
Section 3 — Token Classification Framework. Set out how the committee classifies a token prior to suitability assessment — specifically whether it appears to qualify as an ART, EMT, or other crypto-asset under MiCA, and the implications of each classification for the listing process and ongoing obligations.
Section 4 — Suitability Assessment Process. Detail the Article 76(2) assessment methodology: the five dimensions (technical reliability, AML/fraud risk, issuer track record, operating rules compliance, market integrity), the standard of evidence required for each, and the documentation format for the assessment output.
Section 5 — AML/CTF Risk Assessment Methodology. Set out how the AML/CTF risk of each token is assessed, including the risk factors considered (ML/TF typologies, jurisdictional associations, sanctions exposure, on-chain analytics capability), the risk rating outcome (high/medium/low), and the enhanced due diligence requirements for high-risk ratings.
Section 6 — Whitepaper Reference and Environmental Disclosure. Set out the process for identifying and hyperlinks to any available whitepaper per Article 66(3), and the process for compiling and publishing environmental impact information per Article 66(5).
Section 7 — Approval and Declining Criteria. Define the specific criteria under which a listing will be approved, conditionally approved (subject to enhanced monitoring), deferred pending further information, or declined. Declined listings should be documented with reasons and retained.
Section 8 — Ongoing Monitoring and Delisting. Define the post-listing monitoring framework — including trigger events that initiate a listing review, the review process, and the criteria and procedure for delisting.
Section 9 — Record Retention. Define the retention period for token listing assessment documentation. Given MiCA’s general record retention requirements and good regulatory practice, a minimum of five years is appropriate.
9. Article 66(3): The Whitepaper Reference Obligation
MiCA Article 66(3) imposes a whitepaper reference obligation on four categories of CASP: those operating a trading platform; those exchanging crypto-assets for funds or other crypto-assets; those providing advice on crypto-assets; and those providing portfolio management on crypto-assets.
For each crypto-asset in relation to which they provide services, these CASPs must provide their clients with a hyperlink to any available crypto-asset whitepaper.
Several important clarifications are embedded in this obligation:
“Any” whitepaper, not only MiCA-compliant whitepapers. The BCAS opinion correctly analyses the word “any” in Article 66(3): it refers to any whitepaper, regardless of whether it has been drafted in compliance with MiCA’s whitepaper requirements or approved/notified to an NCA. An exchange listing Bitcoin must hyperlink to the Bitcoin whitepaper. An exchange listing DAI must hyperlink to the MakerDAO whitepaper. An exchange listing USDT must reference Tether’s available documentation. The obligation is not conditional on the existence of a MiCA-compliant whitepaper — which would otherwise make it impossible to list Bitcoin, Ethereum, or any pre-MiCA crypto-asset.
The interpretation limiting this to MiCA-compliant whitepapers is untenable. If Article 66(3) were read as requiring a MiCA-compliant whitepaper, it would mean that no CASP could provide any service in relation to Ether, Solana, Dogecoin, Bitcoin, or any other major crypto-asset that does not have a MiCA whitepaper. This is obviously not the legislature’s intent and is inconsistent with MiCA’s overall architecture, which explicitly acknowledges that many crypto-assets do not require MiCA whitepapers.
Hyperlinks must be accessible and maintained. The obligation is ongoing — a hyperlink that breaks or becomes outdated creates a compliance gap. CASPs should build a whitepaper reference maintenance process into their token listing infrastructure, with regular checks that links remain active and that clients are directed to the most current version of each project’s documentation.
For DAI and USDS specifically, the MakerDAO whitepaper (as attached to the BCAS opinion as Annex D) and the Sky Protocol documentation provide the requisite reference materials. For USDT, Tether’s reserve attestation reports and technical documentation constitute the available reference materials.
10. Article 66(5): The Environmental Disclosure Obligation
MiCA Article 66(5) requires all CASPs — not only trading platforms, but every category of authorised crypto-asset service provider — to make publicly available on their website, in a prominent place, information about the principal adverse impacts on the climate and other environment-related adverse impacts of the consensus mechanism used to issue each crypto-asset in relation to which they provide services.
For DAI, USDS, and USDT — all of which are issued on Ethereum — this means disclosing information about Ethereum’s Proof-of-Stake (PoS) consensus mechanism and its environmental footprint. Since Ethereum’s transition to PoS in September 2022 (the Merge), its energy consumption has reduced by approximately 99.95% relative to its previous Proof-of-Work architecture, per Ethereum Foundation estimates and assessments by the Crypto Carbon Ratings Institute. This is a materially positive environmental profile relative to Bitcoin, which remains Proof-of-Work.
The disclosure must be prominent on the CASP’s website — a buried footnote does not satisfy this requirement. The standard practice is a dedicated section in the footer or on a regulatory/legal information page, with per-token disclosures accessible from individual token pages.
Third-party sources for Ethereum’s environmental data include the Ethereum Foundation’s own sustainability disclosures, the Crypto Carbon Ratings Institute (CCRI), and academic and institutional research on PoS consensus energy consumption. CASPs should reference authoritative sources and ensure their disclosures are kept current.
For CASPs that also provide services in relation to Bitcoin or other Proof-of-Work assets, the environmental disclosure obligation is correspondingly more significant given the materially higher energy consumption of PoW consensus. These disclosures should be drafted carefully to present accurate information without either understating environmental concerns or making claims that cannot be substantiated.
11. Applying the Framework to USDT, DAI and USDS Specifically
The following sets out how the Article 76 suitability framework applies in practice to the three stablecoins at the centre of the current regulatory debate.
USDT (Tether USD)
| Assessment Dimension | Key Findings |
|---|---|
| Technical Reliability | USDT launched on Omni Layer (Bitcoin) in 2014 and migrated to Ethereum in 2017; mature and widely integrated infrastructure. Centralised minting/burning introduces counterparty risk on Tether Limited. No independent smart contract audit equivalent to open DeFi protocols. |
| AML/Fraud Risk | Highest-risk stablecoin by absolute volume of illicit finance associations per FinCEN, FATF, and Europol reporting. Robust blockchain analytics essential. USDT-specific transaction monitoring typologies must be implemented. |
| Issuer Track Record | Tether Limited: NYAG settlement (2021), CFTC enforcement (2021), ongoing reserve transparency questions. Positive: continued operation through multiple market crises; growing reserve attestation quality. |
| Operating Rules Compliance | No MiCA-compliant whitepaper (whitepaper obligation not triggered if no offer to public or seeking admission in Union). Reference to Tether documentation available. |
| Regulatory Status | Non-MiCA-authorised issuer. ESMA statement directs delisting. BCAS argument supports continued own-initiative listing. Legal risk decision required at board level. |
DAI (Sky Protocol / MakerDAO)
| Assessment Dimension | Key Findings |
|---|---|
| Technical Reliability | Extensive third-party audits by ChainSecurity and Cantina across all major protocol modules. Operating since 2017 with strong track record through multiple market stress events. DAI.sol contract is immutable; protocol parameters governed by MKR/SKY holders. |
| AML/Fraud Risk | DeFi architecture permits permissionless minting — origin of collateral funds is not identity-verified at the protocol level. CEX KYC/AML must compensate. No specific regulatory designations as of assessment date. |
| Issuer Track Record | MakerDAO/Sky DAO: one of the oldest and most resilient DeFi protocols, operating since 2014. Governance token holder community has managed multiple crisis events. Development team has strong industry reputation. |
| Operating Rules Compliance | No MiCA-compliant whitepaper (whitepaper obligation not triggered). MakerDAO whitepaper available for Article 66(3) reference. |
| Regulatory Status | Issuer identity contested (non-identifiable issuer argument). ESMA statement directs delisting. BCAS opinion strongly supports continued own-initiative listing. Legal risk decision required at board level. |
USDS (Sky Protocol)
USDS shares substantially all characteristics of DAI for suitability assessment purposes, given that USDS is the successor token to DAI within the same Sky Protocol governance framework. The additional USDS-specific considerations include: its shorter operating history relative to DAI (launched as part of the Sky Protocol rebrand); the upgradeable USDS contract (Usds.sol) compared to DAI’s immutable architecture; and the cross-chain USDS availability on Base layer-2, which introduces additional bridging and cross-chain AML risk considerations.
12. The Promotion and Advertising Boundary
One area of relative regulatory clarity — even amid the broader listing debate — is the European Commission’s Q&A confirmation that CASPs promoting or advertising non-MiCA-compliant ARTs or EMTs as part of their service offering may themselves be conducting an offer to the public in the Union.
This creates a bright line that compliance officers must build into their marketing, product, and communications frameworks:
Passive listing — making a token available to buy and sell on an order book as one of many hundreds of tradeable assets, without specific promotional activity — is materially different from active promotion.
Active promotion that risks characterisation as an offer to the public would include: featured placement on the exchange’s homepage or app with marketing copy about the token’s benefits; email campaigns to clients highlighting the token; push notifications encouraging clients to trade the token; sponsored content or advertising in relation to the token; or promotional campaigns such as zero-fee trading or enhanced yields specifically linked to the token.
CASPs that maintain listings of USDT, DAI, or USDS but wish to manage their regulatory risk as conservatively as possible should audit their marketing and product presentation to ensure none of these tokens receive specific promotional treatment. This means reviewing homepage featured asset selections, CRM campaign content, push notification triggers, app store listings, and any partnership or affiliate arrangements that involve promotional activity around specific stablecoins.
The distinction between passive listing and active promotion is also relevant for non-trading-platform CASPs. A CASP offering exchange services that includes USDT as an available exchange currency without promoting it is likely outside the offer-to-the-public characterisation. A CASP that actively markets its USDT exchange service — advertising it as a featured product, running campaigns to drive USDT transaction volume — creates a materially different risk profile.
13. Delisting Obligations and the Ongoing Monitoring Requirement
Article 76 does not only impose pre-listing obligations. It implies an ongoing monitoring requirement that has direct implications for the circumstances in which a CASP must consider delisting a previously admitted crypto-asset.
Although MiCA does not contain an explicit provision requiring a CASP to delist a token that it has already admitted to trading, the logic of the suitability assessment framework creates a clear implication: if information emerges after listing that would have caused the suitability assessment to fail, the CASP’s operating rules must address how that situation is managed. An operating rules document that is silent on post-listing remediation events is incomplete.
The following categories of post-listing developments should trigger a mandatory listing review under a well-drafted token listing policy:
- An NCA or ESMA supervisory action specifically referencing the token or its issuer
- A sanctions designation of the token, its issuer, or a materially associated party
- A significant technical security incident — exploit, hack, or smart contract vulnerability affecting the token’s infrastructure
- Material evidence of the token’s use in a significant money laundering, fraud, or market manipulation case that generates regulatory or enforcement attention
- A material change in the issuer’s regulatory status — including any attempt by the issuer or governance holders to seek admission to trading in the Union, which would transform the legal basis for the CASP’s listing
- A significant peg deviation or stability event that raises questions about the token’s technical soundness
The delisting process itself should be orderly and client-protective. MiCA’s general CASP obligations require client asset protection and orderly resolution of client positions. A sudden, unannounced delisting without reasonable notice is likely to breach these obligations regardless of the regulatory rationale. A minimum 30-day notice period for non-urgent delistings, with clear client communication about the reasons, is a reasonable baseline standard.
14. Documentation Standards: What Your NCA Will Want to See
A fundamental principle of MiCA compliance — as with any regulated activity — is that what is not documented did not happen. The following documentation elements should be maintained and accessible for every token admitted to trading on a MiCA-regulated platform:
Token listing assessment file — containing the full Article 76(2) suitability assessment, the token classification analysis, the AML/CTF risk assessment, references to any available whitepaper, the environmental disclosure source material, and the committee decision record.
Operating rules document — the formal written operating rules per Article 76(1)(a), with version history showing approval dates and any amendments.
Token listing committee minutes — a written record of every committee meeting at which a token listing, review, or delisting decision was made, with the decision recorded and the rationale documented.
Ongoing monitoring records — evidence of periodic post-listing reviews, including the date of review, the reviewer, the findings, and any action taken.
Client communication records — copies of any client-facing disclosures relating to token listings, including whitepaper hyperlinks and environmental disclosure materials.
Legal risk assessment — for any token where a genuine legal uncertainty exists (such as the own-initiative listing question for non-MiCA-compliant EMTs), a written legal risk assessment approved by the CASP’s legal counsel, setting out the legal basis for the listing decision and the risk mitigation measures in place.
The retention period for all these records should be a minimum of five years, consistent with MiCA’s general record retention requirements and aligned with the AML Directive’s retention standards for customer due diligence records.
15. The Interaction with EU AML Obligations
MiCA’s Article 76(1)(a) explicitly cross-references Directive (EU) 2015/849 — the Fifth AML Directive — in the context of the customer due diligence requirements embedded in the token listing operating rules. This cross-reference is not decorative. It integrates the EU’s AML framework directly into the token admission process.
What this means in practice is that a CASP’s token listing framework is not a standalone compliance exercise separate from its AML programme — it is part of that programme. The AML risk assessment of a token is an input into the listing decision, and the listing decision in turn has downstream implications for the CASP’s ongoing transaction monitoring and suspicious activity reporting obligations.
CASPs should ensure that their AML programme and their token listing policy are designed as integrated, mutually consistent frameworks rather than separate silos. Key integration points include:
Transaction monitoring rules: When a new token is listed, the transaction monitoring programme must be updated to include token-specific typologies and red flag indicators. For USDT, this means implementing the specific ML/TF typologies identified in FATF guidance and FinCEN advisories. For DAI/USDS, it means addressing the DeFi-specific risks of protocol-level permissionless issuance.
Sanctions screening: The token admission process must include a sanctions screening step, verifying that the token, its issuer, and any materially associated contracts or addresses are not subject to EU, UN, or other applicable sanctions designations. ComplyFactor’s AML programme blueprint covers sanctions integration as a core programme component.
VASP risk assessments: Where a token is primarily used in DeFi or cross-VASP transfer contexts, the CASP’s VASP counterparty risk assessment framework should reflect the specific risks associated with that token’s ecosystem.
Forward-looking: The AML Regulation and AMLA. CASPs building their AML frameworks now should also be aware that the EU is transitioning to a new directly applicable AML Regulation (AMLR) which will replace the current Directive-based framework, and that the Anti-Money Laundering Authority (AMLA) — a new EU supervisory body — will have direct supervisory competence over certain categories of obliged entities, potentially including the largest CASPs. The AMLR and AMLA are expected to be fully operational from 2027. Token listing policies and AML programmes built today should be designed with this structural transition in mind, ensuring that they can be adapted to the AMLR’s direct applicability framework without requiring a complete rebuild.
For CASPs building integrated AML and token governance frameworks, ComplyFactor’s AML audit services, AML advisory, and AML training programmes provide a structured pathway to implementation. Our 6 AML trends analysis covers the evolving regulatory expectations for VASPs and CASPs across the EU and globally.
INDUSTRY INSIGHT
The integration of AML obligations into the token listing process represents a structural shift in how EU crypto-asset compliance must be organised. The traditional model — where the trading team made listing decisions commercially and the compliance team dealt with AML separately — is no longer viable under MiCA. Article 76(1)(a)’s AML/CTF cross-reference means that the compliance function must have a formal gatekeeping role in every listing decision. Exchanges that have not yet restructured their governance to reflect this integration are carrying organisational compliance risk that an NCA supervisory review will identify.
16. Building Your Token Governance Committee
The operationalisation of all the obligations described in this article ultimately depends on having the right internal governance structure for token listing decisions. A token governance committee — sometimes called a digital asset listing committee or token admission committee — is the organisational unit that executes the Article 76 framework.
A well-structured token governance committee for a MiCA-regulated trading platform should have the following characteristics:
Composition: The committee should include at minimum the Chief Compliance Officer or MLRO (chair or co-chair), the Head of Legal, a senior technology or security representative, a representative from the trading or product function, and — for complex or borderline listings — an independent external specialist. For exchanges operating across multiple EU jurisdictions, representation from each material jurisdiction’s compliance team should be considered.
Mandate: The committee’s mandate should be formally documented in the token listing policy and should include: exclusive authority over listing and delisting decisions; responsibility for maintaining the token listing assessment file; authority to impose enhanced monitoring conditions on listed tokens; and responsibility for escalating material legal risk decisions to the board.
Meeting frequency and process: A structured process for token listing requests — including defined timelines for each stage of the assessment, clear escalation paths for borderline decisions, and a formal record of every decision — is essential. Ad hoc, informal listing decisions are incompatible with MiCA’s operating rules requirements.
Independence from commercial pressure: The committee must have genuine decision-making independence. A committee that rubber-stamps commercial listing requests without substantive scrutiny does not satisfy Article 76’s suitability assessment obligation. Compliance officers should document cases where they have applied substantive scrutiny and, where relevant, declined or deferred a listing despite commercial interest in proceeding.
17. Practical Checklist: Pre-Listing Compliance for Stablecoins Under MiCA
The following checklist summarises the minimum compliance steps a MiCA-regulated trading platform must complete before admitting a stablecoin to trading. It is not a substitute for legal advice, a full token listing policy, or a complete Article 76 assessment document — it is a practical reference for compliance teams to structure their pre-listing process. For a full policy framework, see Section 8.
Classification
- Determine whether the stablecoin qualifies as an EMT, ART, or other crypto-asset under MiCA
- Assess whether the issuer is identifiable or non-identifiable (Recital 22)
- Determine whether the issuer is EU-located or established outside the Union
- Assess whether any offer to the public or seeking of admission to trading in the Union has occurred
Suitability Assessment (Article 76(2))
- Technical reliability assessment — smart contract audits, protocol track record, upgradeability architecture
- AML/fraud risk assessment — typologies, on-chain analytics capability, sanctions screening
- Issuer track record assessment — corporate history, regulatory actions, key person dependencies
- Operating rules compliance check — whitepaper availability in cases required by MiCA
- Market integrity assessment — liquidity, manipulation risk, concentration risk
- Document findings in a written assessment file
Operating Rules (Article 76(1)(a))
- Verify the token listing policy addresses this specific token classification
- AML/CTF risk rating assigned and documented
- Committee decision recorded in writing with rationale
Whitepaper Reference (Article 66(3))
- Identify any available whitepaper or equivalent documentation
- Hyperlink added to client-facing token information page
- Process in place for maintaining link currency
Environmental Disclosure (Article 66(5))
- Identify consensus mechanism of the blockchain on which the token is issued
- Source authoritative environmental impact data
- Disclosure published prominently on website
Legal Risk Assessment
- Written legal risk assessment completed for any token presenting regulatory uncertainty
- Legal risk assessment approved by legal counsel and signed off at board/senior management level
- Decision documented with risk mitigants identified
Post-Listing
- Transaction monitoring rules updated for token-specific typologies
- Sanctions screening lists updated if applicable
- Ongoing monitoring schedule established
- Review trigger events defined in token listing policy
18. Frequently Asked Questions
Q: Does Article 76(2) apply to tokens listed before MiCA came into force?
A: Yes. Once a CASP obtains MiCA authorisation, its ongoing operation of a trading platform must comply with MiCA in full — including for pre-existing listings. The Article 76(2) suitability assessment must be applied retrospectively to all listed tokens. A risk-based prioritisation approach (stablecoins first, then high-volume tokens, then the long tail) is appropriate for managing the workload, provided the programme is completed within a defined and documented timeframe.
Q: Can I list a stablecoin without a MiCA-compliant whitepaper?
A: Yes, in most cases. Article 76(1)(a) only requires that a MiCA-compliant whitepaper be available in the cases required by the Regulation — i.e., where an offer to the public or seeking of admission to trading has occurred. For stablecoins like BTC (not an EMT/ART), ETH, DAI, USDS, and USDT (where no offer or seeking has occurred in the EU), no MiCA-compliant whitepaper is required, and the operating rules must reflect this conditional structure. You must still reference any available whitepaper under Article 66(3).
Q: What does a sufficient Article 76(2) suitability assessment look like for USDT?
A: It should be a written document addressing: Tether’s technical infrastructure and security track record; the AML/fraud risk profile including regulatory and enforcement history; Tether’s reserve composition and attestation quality; the legal risk position regarding own-initiative listing under MiCA; the enhanced monitoring measures your platform will implement; and the committee’s decision with supporting rationale. It should be detailed enough that an NCA reviewer reading it understands your basis for the listing decision and the controls you have placed around it.
Q: Do I need to delist USDT to comply with MiCA?
A: This remains legally contested. ESMA’s January 2025 public statement directed trading platforms to delist non-MiCA-compliant EMTs. The BCAS legal opinion concluded that own-initiative listings are not prohibited by MiCA Titles III or IV. This is a legal risk decision that must be made with formal legal advice specific to your jurisdiction, NCA, and business model. If your home NCA has publicly aligned with ESMA’s position, the risk of maintaining the listing is materially higher than in jurisdictions where the NCA has been silent.
Q: How often should post-listing suitability reviews be conducted?
A: MiCA does not specify a mandatory review frequency. Best practice for a MiCA-compliant token listing policy is annual reviews for all listed tokens, with event-driven reviews triggered by specific developments (regulatory actions, security incidents, peg deviations, changes in issuer status). For high-risk tokens — including non-MiCA-compliant stablecoins — more frequent periodic reviews (semi-annual) are appropriate.
Q: Is the token listing policy a document I must submit to my NCA?
A: MiCA requires CASPs to maintain operating rules per Article 76(1)(a) but does not specify routine submission of the token listing policy to the NCA. However, the NCA may request it as part of a supervisory review or authorisation process. It must be maintained and producible on demand. Some NCAs may require it to be submitted as part of the authorisation application — this is jurisdiction-specific and should be confirmed with local counsel.
This article is published for informational purposes and does not constitute legal advice. For MiCA compliance advisory, CASP AML programme development, fractional MLRO services, and token listing policy design, contact ComplyFactor.
Related Articles:
- Can EU Exchanges Still List USDT, DAI and USDS Under MiCA? The Legal Debate Explained
- MiCA Regulation Guide 2026: EU Crypto-Asset Framework Explained
- Ultimate Guide to VASP Compliance: Global AML/CTF/PF Standards
- The Complete AML Program Blueprint: Design, Build and Implement
- AML Audit Checklist 2025: Complete Fintech Guide
- 6 AML Trends in Regulatory Compliance Every Compliance Officer Needs to Follow
- Europol SOCTA 2025: Financial Crime Trends and Cryptocurrency Money Laundering
- Offshore VASPs: FATF’s 2026 oVASP Risk Report Explained
- UK Regulatory Changes 2026: Complete Compliance Guide for Crypto and Fintech
- UAE Crypto Regulation 2025: Complete Guide to VARA, ADGM, SCA, CBUAE