With less than 200 days to go until the implementation of MiFID II, the uncertainty surrounding direct electronic access (DEA) shows little sign of resolution. I recently attended a panel discussion on the topic at the IDX conference in London, at which a number of important issues were raised.
The concept of DEA, whereby a market participant directly accesses a trading venue by using the trading code of a member firm, is simple enough. But there is still confusion over which market access models should be subject to DEA requirements.
Crucially, the European Commissions delegated regulation specified in 2016 that if a market participant cannot exercise discretion regarding the exact fraction of a second of order entry, then it is not capable of DEA. That led some institutions, including Germanys Deutsche Brse, to assume that direct access to exchanges would not be classified as DEA if the user had no such discretion.
However, the European Securities and Markets Authority (ESMA) clarified in a Q&A in April 2017 that if the user has discretion over the exact fraction of a second an order is sent to the market, it still constitutes DEA, even if subsequent control filters delay the order reaching the matching engine. This distinction is critical, because it brings more market access models back into the scope of DEA.
Meanwhile it is generally agreed that algorithmic execution would not typically constitute DEA because most strategies involve intervening with an order and executing it according to certain parameters, rather than sending it directly to the trading venue using a member firms code.
But point-and-click trading remains a grey area, with varying views on whether it constitutes DEA. One participant on the IDX panel suggested that if a client uses a broker or vendor platform to trade directly and has complete control over the order, then it could be in-scope. But another countered that unless a black box is used, the user does not have control over the fraction of a second at which the order is submitted, and most point-and-click trades should not therefore be considered DEA.
The specific requirements for DEA providers are set out in ESMAs regulatory technical standards (RTS). They must establish policies and procedures to ensure clients comply with the trading venues rules, and put in place substantial pre- and post-trade controls, in addition to monitoring and managing the DEA orders on an ongoing basis. Minimum due diligence is also required on prospective DEA clients, as well as an annual risk-based assessment of their systems and controls.
These requirements all make sense as a way of ensuring DEA takes place within a well-controlled environment without risking market disruption, but they also reinforce the need for clarity over the definition of DEA. Implementing all of these requirements for clients or orders that may not actually need them could result in firms incurring unnecessary cost. This is where partnering with the right provider could help to reduce costs whilst ensuring compliance.
Equally, however, there is a risk that some orders may be considered so simple and easy to handle that the appropriate measures are not deployed. A simple iceberg order may be one such example, as it would likely be considered DEA, but a broker might be so accustomed to processing icebergs that it fails to provide all of the surveillance and other checks required under MiFID II.
The DEA provisions remain largely as beguiling today as they have been for the past 18 months, but the key difference is that time is now in very short supply. The requirements set out in the RTS are only intended to apply to certain activities that constitute DEA, but market participants also need to make their own educated projections on which models are likely to fall in-scope.
With the clock ticking towards 3 January, a conservative reading of the rules is likely to be the most prudent option. But having the flexibility to ensure that systems and controls can adapt to support different interpretations is also prudent, so that if late changes are made, its simply a case of configuring the right services to implement the necessary DEA provisions.
