The Technology Impacts of Mifid II (Part 2)

In the second part of this three-part series, [Part 1 here] Richard Bentley looked at the implications of Mifid II for banks’ and brokers’ technology stacks to support their electronic order flow, with specific focus on pre-trade workflows. He now turns his focus to order execution, following the decision of where to send orders and the completion of pre-trade risk management and compliance checks.

The execution of orders for “Mifid instruments” is fundamentally changing as a result of Mifid II. Rules like the double volume cap, common tick sizes and the various waivers are driving a shift in market models, away from dark pools and crossing networks and toward new venues that use alternative models like periodic and on-demand auctions, block matching using indication-of-interest (IOI) and request-for-quote (RFQ) workflows, and so on. The introduction of systematic internalizers in 2018 further complicates the liquidity landscape.

These changes will impact trading technologies for a long time to come. While many of the impacts are not presently well understood, there are more immediate consequences of the regulation, which we review below.

Market Gateways

One of the biggest impacts of Mifid II, in terms of workload for market members is on direct market access (DMA) gateways—the software that connects internal trading systems to the venues themselves. Mifid II requires changes to the electronic messages sent and received by participants. These changes include updates to timestamp granularity to support microseconds, new message fields—some that must be computed by the order management system (OMS)—related to transparency and for market operator record-keeping, and complete new workflows for new market models. Brokers will have to map new fields on the order message (e.g., identifiers for individuals involved in the investment decision) to short code forms, but a lack of agreement on a common format means these codes may be different depending on the trading venue, creating a complex data mapping challenge.

The result of these changes is that all venues where Mifid instruments are traded will upgrade their application programming interfaces (APIs) in advance of January 2018, requiring a massive effort to update the DMA gateway software that connects to them. In Europe this means more than 50 venues across different asset classes will be revising their APIs this year. As of February 2017, only a handful of those venues had released new specifications, with many yet to even confirm a timetable for doing so. The early-movers have also stated that they will release further revisions to their APIs over the course of this year.

The work to develop, test and recertify DMA gateways to new specifications will be enormous, and heavily weighted to the second half of this year. Brokers offering DMA/low-touch execution across multiple markets are preparing for a very busy third and fourth quarter. Based on our own experience at Ullink, for many participants this will be the driver to investigate outsourcing market connectivity to vendors—especially those providing hosting and managed services—as the costs of maintaining internal market gateways becomes prohibitive.

At-Trade Monitoring and Intervention

Mifid II places new obligations on brokers with respect to real-time monitoring of house and client orders and trades, plus the means to intervene as an emergency measure if issues arise—the so-called “kill switch.” Intervention might be necessary in different scenarios, ranging from suspected market manipulation or erroneous trades, directional trading, which builds a significant exposure—possibly due to an out-of-control algo—or operational issues such as a failure in a client trading system resulting in the client losing visibility and control of its orders.

Larger firms may have several different front-office trading systems across different asset classes, desks or geographies, and gaining a centralized real-time view of activity and exposure, plus the means to intervene, may not be straightforward. In cases of sponsored access, client order flow may bypass broker infrastructure entirely, subject only to broker-supplied pre-trade risk checks. For these reasons, most brokers will connect to venue APIs providing real-time, or “at-trade” drop copies of all orders and trades printed in the firm’s name in order to fulfill their monitoring obligations. Many venues also provide, via the same APIs, means to kill individual or groups of orders, or shut down trading sessions entirely, effectively cancelling any orders still working in the market.

Besides connectivity to venue drop-copy interfaces, the stipulation for central monitoring and intervention requires tools capable of processing and visualizing large volumes of order flow in real time. To locate and kill individual or multiple orders among potentially tens of thousands of working orders also requires rich searching, sorting and filtering capabilities. Notification is a further requirement, to detect and alert on unusual patterns of orders that might signal issues which might require trader intervention. These requirements outstrip the capabilities of most order management systems suggesting that new tools will almost certainly be needed.


In the context of monitoring, Mifid II also stipulates that firms must ensure the accuracy of their trade and position information by reconciling their internal logs with the drop copies provided by trading venues. This provides a second reason why firms must invest to develop the connectivity to venue drop-copy APIs, and introduces the additional requirements to run a reconciliation process.

The principle behind this requirement is to allow a firm to view its overall levels of risk and exposure independently of internal trading systems. This is a form of “4-eyes” risk management, which is not unique to Mifid II, nor is it limited to the sell-side; buy-side firms must also perform similar reconciliation with information provided by their broker or “direct execution access” (DEA) provider.

While Mifid II does not mandate that this reconciliation process is conducted in real time—stating that it must occur “as soon as is practicable”—it is in firms’ interests to detect mismatches as soon as they can. Many firms will look to deploy real-time reconciliation technology with an alerting mechanism to address this requirement to try to prevent erroneous execution reports from being sent to the client, or enable issues to be addressed before trades are reported to the approved reporting mechanism (ARM). With the shortened trade reporting windows under Mifid II, this pushes brokers to reconcile in real time.

Clock Synchronization

Mifid II introduces the notion of “reportable events”—or things that can happen to an order during its lifetime that must be recorded and reported (a subject addressed in the final article in this series). Examples include an order being filled, amended or cancelled—though there is some dispute as to what exactly constitutes a “reportable event.” Whatever the eventual definition, central to this is the adoption of consistent timestamps across participants and trading venues during the order lifecycle, and consequent synchronization of clocks used to generate these timestamps with a reliable time source—such as an atomic clock.

The degree of accuracy—or permitted clock skew—varies depending on the participant and style of trading, but can be as low as 100 microseconds. Achieving this level of accuracy in all cases is not trivial, requiring investments at hardware, network and software levels. While some firms will lean heavily on their datacenter and infrastructure providers to enable them to meet this obligation, doing so will come at considerable cost.

In this article we have highlighted the impacts of Mifid II on some of the technologies and systems engaged in the execution of electronic order flow. In the final article of this series we will turn our attention to the post-trade space, focusing on the impacts of Mifid II rules around order record-keeping, trade and transaction reporting, and best execution.

Richard Bentley is chief product officer at Ullink, a Paris-based provider of multi-asset trading technology and infrastructure to the buy side and sell side. 

Source link

Add a Comment