Table of Contents
- NO BULLSHIT REVIEW: NEON EXCHANGE
- Strong Concerns Regarding Decentralized Security Token Exchanges
- Additional Comments
- Requirements form MiFID 2 / MiFIR with links
NO BULLSHIT REVIEW: NEON EXCHANGE
Neon Exchange (NEX) is a decentralized platform on the NEO blockchain that applies a publicly verifiable off-chain matching engine to handle trading volume and support complex orders (such as limit orders) that are not possible on existing DEXs. The exchange aims to trade: Crypto to Crypto, Crypto to Fiat as well as Security Tokens.
There are several regulators that can allow an institution to sell Securities. NEX is applying for an OTF in Liechtenstein, to sell security tokens within the EU. They will, therefore, fall under the Mifid 1 & laws.
In this article we will dive deep into the laws required for trading Securities within the EU, we are ONLY evaluating NEX ability to sell STOs within the EU. We are NOT evaluating NEX ability to develop a high-quality DEX.
What is MiFID II and how will it affect EU’s financial industry?
The Markets in Financial Instruments Directive 2004/39/EC (known as “MiFID”) as subsequently amended is a European Union law that provides harmonised regulation for investment services across the 31 member states of the European Economic Area (the 28 EU member states plus Iceland, Norway, and Liechtenstein). The EU’s ambitious regulatory reforms, known as MiFID II, aim to transform Europe’s financial industry.
Strong Concerns Regarding Decentralized Security Token Exchanges
Decentralized exchanges will have troubles with MiFID II/MiFIR regulation
Decentralized exchanges (DEX) are creating quite a lot of buzz recently. In this post, I will share some information about what regulations trading venues must comply to and why a trading system based on a decentralized exchange will hardly ever comply with MiFID II/MiFIR.
The most problematic issue in DEX is that there is the possibility of frontrunning the trades. While we have seen quite sophisticated ways of front running orders on centralized systems in the traditional systems where huge penalties were given to those who were doing it, decentralized exchanges are not entirely immune to the practice of front running. Once a trade is broadcast to the blockchain, it awaits verification from miners who decide which transactions to include in the following block. Since the frequency of incoming transactions often outweighs the capacity of the subsequent block, transactions not mined immediately sit in a pending transaction pool, also known as a mempool.
However, the transparent nature of a blockchain mempools enables front runners to enter their trades first, profiting on the resulting price movements when prior orders are finally executed. By setting a higher gas price and making it attractive for miners to prioritize their transaction, these malicious actors can ensure that their trade executes before the transaction they are attempting to front-run. Furthermore, miners can participate in front running themselves by choosing to execute their own trades ahead of time.
Relayer-based DEX might solve some of the issues, but the technology is still being developed and was not yet fully tested. Solutions include encrypting the trade data and decrypting it after the block confirmation from miners.
Deep Dive into Technological Problems with NEX and Regulators
Nex aims to implement a decentralized exchange which is essentially an off-chain order matching + on-chain settlement is not a new concept, though admittedly, to our best of knowledge, these exchanges were limited to Ethereum blockchain. An example of such an exchange would be IDEX. Users need to deposit ETH and ETH-based tokens to a smart contract. IDEX utilizes a relatively fast (for a DEX) matching engine for trading. These trades are then cleared via the smart contract (on-chain). Consequently, settlement takes anywhere from 5-20 seconds under normal conditions. Within these 5-20 seconds, the funds are “in transit” and cannot be used by either party. When ETH blockchain is under heavy load, it can happen that all operations requiring interaction with smart contract (deposits, withdrawals, settlement) are stuck due to previous transactions not being cleared (a consequence of sending txs from a single SC). Admittedly rarely, this can render all operations except order matching with already deposited funds temporarily inaccessible.
Interacting with several smart contracts on different blockchains (as proposed in their WP) just amplifies this problem. The solution which they propose (“smart vault”, where traders can elect whether to keep trade amount within the matching engine as opposed to their wallets) is untested and first of its kind, and thus susceptible to double-spending errors.
Consequently, it is in our opinion, that such structure cannot be MiFID II compliant, as the double-spending possibility is a real danger. If Neon decides to forego “smart valut” and goes only for on-chain settlement, the trading experience will greatly suffer and/or required capital will be far greater for high-frequency traders and market makers due to 1-block lag (5-20 sec on ETH blockchain) for settlement compared to any prefunded exchange.
Balances and settlement of direct FIAT pairs are another problem not addressed in the white paper, especially for PvD (payment vs. delivery) issue with institutional clients. They can either find a clearing house (highly unlikely as CCPs are not yet ready to take over the clearing risk for crypto assets) or develop some novel way of guaranteeing the settlement without prefunded accounts (financial institutions do not prefund their trading accounts with exchanges).
As with all decentralized exchanges, users need to deposit assets to a respective smart contract before they start trading. This situation is not preferred from a regulatory standpoint, as it is unclear who, if anyone, owns these assets from the moment they are deposited to the SC. Upcoming Liechtenstein legislation () recognizes an official status of crypto custodians (TT Protector – A person who holds tokens on TT Systems in their own name on account for a third party. TT Protectors are required to be licensed according to the Trustee Act or the Banking Act). In our opinion, Neon will still be responsible for these assets as a custodian, regardless if they are deposited on a smart contract or in a central wallet.
This adds additional regulatory obligations, which, importantly, cannot be avoided given the DEX business model – no one else can take the custodian role even if regulated custodians for security tokens emerge, as long as a smart contract is in the middle of the trading process.
Given that fact, it is unclear whether it will seek any license under MiFID II, or it will register under the upcoming Liechtenstein Blockchain Law. Even assuming that they apply for a MiFID II license, it is in our opinion more likely that they will seek an OTF, as evident from their roadmap. If they opt for OTF license which enables them to target retail clients directly without an intermediary broker, they will be limited to listing non-equity instruments which would make their whole business model of listing security tokens obsolete (the vast majority of security tokens being issued now are equity or equity-like instruments). Given our knowledge from talking with the regulator, they have not yet approached FMA with the plan to acquire the OTF license.
Massive unverified OTC trading of Neon Exchange white-listed addresses. Pooled Neon SAFTs for half million dollars were often seen and pooled out without AML or KYC.
RTS 1 and RTS 2 set standards for pre- and post-trade transparency obligations for both trading venues and investment firms.
RTS 6 are quite a game changer for algo-traders since they must comply with the standards set in it, especially on the resilience of trading systems and Direct Electronic Access obligations.
RTS 7 is one of the most important standards for trading venues since it sets forth the organizational requirements of trading venues, which include governance, appropriate staffing, and detailed standards for capacity and resilience of the company and its IT systems. Decentralized exchanges might have many problems with the whole Chapter II of RTS 7 especially Article 11, Article 18 and Article 20.
RTS 8 sets standards for arrangements between market makers and trading venues
RTS 9 sets standards for trading venues where they must monitor the ratio of cancelled orders compared to matched orders for all trading participants
RTS 11 sets the standard for determining tick size based on the liquidity and the price of the asset which is something DEX might have technical problems with
RTS 15 is an interesting one as it deals with clearing members of trading venues, which is something regulated financial institutions are used to as CCPs take over the risk, while decentralized exchanges are set up in a way that CCPs cannot be directly involved
RTS 17 defines the standards for listing requirements
RTS 22 sets standards on how to report transactions to the national regulator and ESMA
RTS 25 sets standards on how time should be synchronized across servers (both on trading venue and members of the venue). This is problematic when using on-chain orderbook and matching on decentralized exchanges
Some of the Implementing Technical Standards, available at the website of European Commission.