ESMA's October: the stablecoin list and the collateral test

On 8 October 2026 ESMA published an opinion telling national competent authorities that MiCA-authorised crypto-asset service providers should not provide any MiCA service in relation to a stablecoin that does not meet MiCA's issuance conditions. The next day, 9 October, it opened a call for evidence on whether EU central counterparties could safely accept tokenised collateral.

They look like different subjects. One is about stablecoin issuers and the platforms that list them. The other is about clearing houses and the assets behind margin. Read together, they say the same thing. The regulator is no longer asking what you disclose. It is asking what your systems can enforce and prove.

This note covers both, because the teams who have to act on them overlap.

The 8 October opinion#

The opinion is addressed to national competent authorities, not directly to firms. Its job is to tell supervisors what to look for. That distinction matters less than it sounds, because the expectations are specific.

What it says, in order of how much it changes:

All services, not just trading. The expectation covers every MiCA service, alone or in combination: operating a trading platform, exchange, order execution, order reception and transmission, placing, advice, transfer services, custody and portfolio management.
A presumption, not a case-by-case judgement. ESMA's reasoning is that the risks of a non-compliant token come from the missing issuer-level safeguards, which a CASP cannot mitigate from its side. It therefore presumes that servicing such a token is incompatible with the CASP's duty to act honestly, fairly and professionally in clients' best interests (Article 66(1)).
Disclosure does not fix it. The opinion states that warnings and client acknowledgements are not enough. If your current answer is a risk banner and a tick-box, ESMA has already said it will not count.
Controls are expected. CASPs should have technical, contractual and organisational controls that prevent these tokens being available in the Union, including controls that stop EU clients acquiring or increasing positions.
A three-month clock for legacy exposure. Where supervisors find existing exposure, they should require remediation as soon as possible and no later than three months after publication. That puts the outer edge at around 8 January 2027.
A narrow wind-down lane. Continued service is limited to liquidating, converting, withdrawing, transferring or safekeeping existing holdings. It must be time-limited, clearly communicated to clients and closely supervised. No new acquisitions, no promotion, no active distribution.

"Non-MiCA-compliant" is defined in a footnote: tokens for which the conditions for a lawful offer to the public or admission to trading under Titles III or IV are not met, taking into account applicable exemptions and transitional arrangements. Compliance status is therefore a property of a token at a point in time, not a permanent label.

Where this breaks in a real stack#

Most CASPs will read the opinion and think about the listing. The listing is the easy part. The hard part is that "available to EU clients" is spread across several systems.

Eligibility is data, and it changes. You need one authoritative record of which tokens are compliant, sourced from the issuer and token registers and carrying effective dates. A hard-coded list in the trading engine will be wrong the first time a status changes. Someone has to own that record and review it on a schedule.
Every service path needs the check. Blocking a market on the exchange does not stop an order arriving through order reception, a transfer in from an external wallet, a portfolio-management rebalance, or a staking or custody sub-account. The opinion names them all. A control that sits only on the front-end order ticket does not meet it.
Wind-down needs a mode, not a switch. The permitted residual services are sell-only, convert, transfer out and safekeeping. That is a distinct state in the product: buying disabled, selling and withdrawal enabled, deposits restricted, client messaging attached. Most platforms have on and off. They need a third state, with an expiry date.
Evidence for the supervisor. If an authority asks how you prevent clients increasing exposure, the answer has to be a log of decisions, not a policy document. That means recording which rule blocked which request and when the eligibility record last changed.
DORA still applies. New controls are ICT changes. Third-party price, liquidity and custody providers that still touch an affected token are in scope for your register of information. The EBA published its final DORA third-party risk guidelines on 18 September 2026. Check that your remediation plan and your provider inventory tell the same story.

For scale: the EBA's response to the Commission's MiCA review, published 24 September, says 39 e-money tokens had been issued as of 1 September 2026 and no asset-referenced tokens had been authorised. The compliant universe is small and countable. That makes an eligibility record practical to maintain.

What the market is offering#

The commentary so far falls into two groups. Law firms and compliance newsletters explain the legal reasoning and what the opinion says about Article 66. Exchanges and trade press report which tokens may be affected.

What is thin is the implementation view: where in a CASP's architecture the check lives, how a wind-down state is modelled, and what evidence to keep. That is engineering work with a date attached, and the date is January.

The 9 October call for evidence#

ESMA's CCP Supervisory Committee has asked whether, and under what conditions, EU CCPs could use tokenised collateral. The call covers three models: tokenised versions of assets that stay in traditional infrastructure, assets issued directly on a distributed ledger, and hybrid arrangements, including how each interacts with tokenised cash and other settlement assets.

The questions are about the lifecycle after a clearing member default. Can the CCP access the collateral, transfer it and convert it into liquidity? How are client protection, segregation and settlement finality maintained? Does tokenising an already-eligible asset change its risk profile?

The committee chair is clear that the core safeguards stay unchanged: high quality, legal enforceability, liquidity and operational availability under stress. Responses are due 15 January 2027, and ESMA will assess them in the first quarter of 2027 before deciding next steps.

This is a consultation, not a rule. Nothing here obliges anyone to build anything. It does tell you what the eventual test looks like, and it is not a test about the token standard.

What the collateral test asks of a tokenisation stack#

Anyone tokenising an asset in the hope that it becomes eligible collateral should read the questions as a checklist for their own architecture.

Default-day mechanics. On the day a member fails, can the asset be moved and sold within the CCP's timelines? That depends on transfer restrictions, identity and whitelisting logic, and whether the custodian and transfer agent can act inside the same window. These are the integrations between the token engine and the rest of the stack, not the contract itself.
Segregation you can show. Client positions must be demonstrably separate. On a ledger that means account structure, and the reconciliation between the ledger, the custodian's books and the CCP's records has to hold at the same moment.
Finality and cash. The call asks how tokenised collateral interacts with tokenised cash. If your settlement leg depends on a bridge or an off-chain confirmation, that is where the finality question will land. The Eurosystem's Pontes, live since 21 September, settles the cash leg in central bank money, and ESMA frames the cash side as part of the same analysis.
Pricing and valuation. A haircut model needs a defensible price when markets are stressed. Oracle and NAV feeds that work in calm conditions become part of the risk case.

None of this is solved by choosing a different token standard. It is solved, or not, by how the pieces are connected and how well each one is evidenced.

One thread through both#

ESMA also said on 30 September, in its response to the Commission's MiCA review, that regulated crypto firms should be prevented from offering services linked to non-compliant stablecoins, and that the EU needs a framework for tokenised securities and on-chain settlement. The opinion and the call for evidence are the first concrete steps on those two points.

For a CASP, the lesson is to stop treating compliance as a layer above the product. A token's status, its permitted services and the evidence of control need to live in the system itself. For a tokenisation team, the lesson is that institutional eligibility will be decided in the integrations: custody, transfer agency, valuation and settlement. The token is the smaller part.

How we help#

We do not sell a platform or list tokens, so the review is neutral about which ones you carry.

CASP Compliance Stack Audit. Fixed fee, two to four weeks. We map every service path against the opinion's list, check where an eligibility control exists and where it does not, and look at the DORA treatment of the providers involved. You get a gap list, a design for the eligibility record and the wind-down state, and a build plan sized against the January date.
Tokenization Stack Assessment. For teams connecting an ERC-3643 or T-REX class engine to KYC, custody, transfer agency and core banking. We use ESMA's collateral questions as the test cases: what does default-day handling require, and which integrations are missing.
RWA Risk Readiness Review. Where the question is whether an institution can price the risk, we look at oracle design, data feeds and cover structures.

If the January date is on your plan, start with a fixed-scope verdict. See the readiness sprints, or write to us at info@prodevel.com.