GERMANY Trends and Developments Contributed by: Wolfgang Richter, gunnercooke GmbH
Centralised Decentralisation: When Token Protocols Become Regulated in the EU For fintechs, token issuers, protocol developers and other businesses handling crypto-assets, decentrali- sation is no longer only a technical choice. It is also a regulatory question. Under EU law, the way in which a token service is built may determine whether the activity is regulated or falls outside the regulatory perimeter. A business may decide to operate through a centralised platform, with a company controlling the user relationship, the interface, order flow, custody, pricing or execution process. In that case, the regulatory analysis is rel- atively familiar: the company is the identifiable ser- vice provider and may need authorisation, whether under Regulation (EU) 2023/1114 (MiCAR), Directive 2014/65/EU (MiFID II) or another financial services regime. But the same economic function may also be imple- mented through decentralised infrastructure. A smart contract may execute transactions automatically. An AMM may replace a conventional order book. Users may interact directly with a protocol. Governance may be moved to token holders. Fees may be calculated by an oracle. Access may be controlled through a KYC credential rather than through a conventional platform account. In such cases, the regulatory question becomes more difficult: is there still a regulated service provider, or is the activity carried out in a fully decentralised manner without an intermediary? MiCAR and MiFID II MiFID II tokens are tokenised versions of the instru- ments already traded on traditional securities markets, including tokenised transferable securities, money- market instruments, collective investment units, commodities-linked derivatives and similar instru- ments. Under Article 2 (4) of MiCAR, any crypto-asset that qualifies as a financial instrument under MiFID II is carved out of MiCAR’s scope. All other fungible tokens – cryptocurrencies, stablecoins, utility tokens, e-money tokens and asset-referenced tokens – fall within MiCAR’s scope.
The two regulatory regimes are mutually exclusive: a given token is either a financial instrument within the meaning of MiFID II – and therefore subject to MiFID II, MiFIR, the Prospectus Regulation, the Market Abuse Regulation and the wider EU securities-law acquis – or a MiCAR crypto-asset governed by MiCAR Titles II-VI, but not both. That distinction matters because MiCAR expressly recognises that crypto-asset services provided in a fully decentralised manner without an intermediary should fall outside its scope. If a service is centralised, the provider may require authorisation as a crypto- asset service provider. If the same service is genu- inely decentralised, there may be no legal person on whom the MiCAR’s service provider obligations can be imposed. MiFID II contains no explicit decentralisation exemp- tion comparable to MiCAR Recital 22. Where the token qualifies as a financial instrument, EU law does not provide a general decentralisation exemption merely because the instrument is issued, traded or settled on-chain. A decentralised technical layer does not by itself preclude the application of investment services or trading venue rules. There are, however, good rea- sons to apply comparable criteria to MiFID II tokens, as will be argued below. This creates a practical structuring question for mar- ket participants. Businesses dealing with tokens must decide whether to build a regulated centralised ser- vice, or whether they can – and should – design infra- structure that is genuinely decentralised. That choice is not cosmetic. It affects licensing strategy, govern- ance, investor protection, AML design, user access, liability, revenue models, technical architecture and the long-term ability to operate across the EU. The problem is not blockchain – the problem is control “Decentralised” is not a single legal or technical fact. A protocol may be decentralised at one layer and cen- tralised at another. A smart contract may be immuta- ble, but the website may be controlled by a company. An AMM may be ownerless, but the token list may be curated. Fees may be calculated automatically, while the oracle may be controlled by a single entity.
268 CHAMBERS.COM
Powered by FlippingBook