06.29.2016

mIfid II/R and Workflow – The Rise of the Machines (by Steve Toland, TransFICC)

06.29.2016

In 18 months time MiFID II becomes law in the EU. Trading institutions need to look at the technology that supports their workflow now to avoid becoming the Nokia of the Fixed Income and Derivatives markets.

Remember Nokia and their strapline, “Connecting People”? You should, because in Q3 2010, Nokia had a 34% share of the global Smartphone market. Apple’s share was 18% and Samsung was on 7%. Two years later Nokia’s share had dropped to less than 5%.

For any Finnish readers, I would like to say that Nokia did a lot of things right in getting to be the global leader, and I owned a few cool Nokia handsets. But the Nokia example highlights how quickly fortunes can change, due to product and technology decisions combined with the macro landscape.

Why does MiFID II/R Matter?

The Fixed Income and Derivatives markets are currently undergoing macro changes due to near zero/negative interest rates, Basel III / Dodd Frank / Volcker rule regulation and bank restructuring. MIFID II/R, which becomes law in January 2018, requires that the trading and reporting of Fixed Income and Derivative instruments will change. These changes will drive product and technology decisions for Trading Venues, the Sell side and Investment Firms. A great deal has already been written about MiFID II/R and we don’t want to sacrifice any more trees. Instead, we have summarised the key objectives and guidelines.

Using this information we look at how this may impact your technology, based on our team’s experiences of building LMAX Exchange, a regulated MTF, and in building TransFICC, an eTrading technology company for the Fixed Income and Derivatives markets.

What are the key points of MiFID II/R?

The Markets in Financial Instruments Directive II (MiFID II) and the Markets in Financial Instruments Regulation (MiFIR) are European Union (EU) regulations designed to remove barriers to cross border financial services across Europe and to foster a competitive and level playing field between trading venues.

The instruments covered are Bonds, Commodities and Derivatives, in addition to Equities, which were covered under MiFID I. MIFID II/R requires that these instruments trade on a regulated Trading venue (RM, MTF, OTF – See Trading Venue Comparison Table) or via a Systematic Internaliser (SI) system. An example of a SI would be a Bank acting on a principal trading basis.

The Trading Venues need to meet Transparency and Trading Rule requirements and the Banks and Buy side firms trading on these venues will need to adjust their workflows to meet Transparency and Best Execution reporting rules.

  • Pre-Trade Transparency requires the Trading Venue to publish current Bid/Offer prices with Size. This applies to RFQ and Voice trades also. SI’s where they make prices public will need to trade with all clients at the same price. There are some exceptions including Non Liquid instruments  (< €100k notional/day or <2 trades/day), Orders that are large in size or orders held in an Order Management System (OMS). For more detail on the exception rules please read the excellent overview by the ICMA team < MiFID II/MiFIR – Transparency and Best Execution requirements in respect of Bonds Q1 2016> http://www.icmagroup.org/Regulatory-Policy-and-Market-Practice/Secondary-Markets/mifid-ii/
  • Post-Trade Transparency requires RM’s, MTF’s, OTF’s and Investment firms trading OTC to publish all data on trades as soon as possible. There are some questions about how soon is soon – ‘within 5 minutes from 2020’ seems slow compared to other markets, and like Pre-Trade there are some delays that will be allowed for Large Size or Non Liquid Instruments.
  • Best Execution reporting applies to both Trading Venues and Investment Firms. The aim is to make data publicly available so that execution quality and practice can be assessed. All Trading venues will need to publish data in an API format on a quarterly basis. Investment Firms will evaluate their execution practice by identifying and publishing their top 5 trading venues in each instrument class.
  • Governance/Best Practice. Trading Venues, Sell side and Investment Firms all need processes in place to ensure compliance with relevant rules, quantifying risk levels and management reporting. Trading Venues also need to have systems to support Market Surveillance and System Resilience and tick size regime to support algorithmic trading customers.

 

Pay Attention…….to Technology

 

  • High Availability. For Trading Venues and Order Management Systems there is an obvious need to have no single point of failure and quick failover between key components. However, the bigger problem when a key component fails is to ensure that you have the current state of all orders and have the ability to recover in a deterministic fashion. Handover of Order responsibility also needs to be considered. Once an order is accepted by an Execution Venue or a bank/buy side acting on behalf of a customer, the ability to recover or replay all orders is required.

 

  • Market Data. When we worked for an MTF, the decision was taken by the technology team to interpret the pre trade transparency requirement for an MTF literally. i.e. every single order book update would be published to the wire in real time. This is great from a regulatory point of view but creates its own technology issues due to the amount of updates being published. Some customers wanted as many updates as possible, as they recognised ‘The MTF’ as an accurate pricing source, but the systems of other customers could not keep up with the data. Some were also bandwidth constrained via circuits or accessing via the Internet. This required the development of throttling tools to manage market data updates, configurable by customer. The two main approaches are to limit data to top of book or limit the number of updates per second. For the customers who could keep up with market data the demand came to update protocols from FIX to Binary. Binary is more efficient for processing market data updates than FIX.

 

  • Tic Storage. With higher rates of market data comes the issue of storing data. The approach we favour is to use optical fibre taps and flat file storage. An optical fibre tap is a prism that reflects a copy of the light source on an optical fibre cross connect. This enables an exact copy of data on the wire without introducing any latency as part of the capture/storage process. Storing the data in flat files keeps the raw data for review and is a cheap approach. However, review and analysis of the data is not that flexible from flat files. Many banks and high frequency Firms need better tools to fully analyse the data and thus purchase relational tic database products. These are typically high functioning and priced accordingly.

 

  • Time Stamps. RTS6 of MiFID II states that trading firms must report when trading instructions are exchanged between counterparties and RTS25 covers the degree of accuracy of Timestamps as divergence from UTC (To understand “Time” itself is a deep subject but please read blog by Judd Gaddie of TransFICC http://wireddevelopment.blogspot.co.uk (cup of tea and a biscuit read). Electronic trades need millisecond accuracy and High Frequency trades need to be at the 100 microsecond level. However, for a bank or investment firm thought needs to be given to synchronisation. Each venue will include a time stamp (microsecond level) on each message but trading venues and customers are in different parts of the world and subject to latency delays that are not consistent. To make a decision on order routing or risk requires time stamping of every input message to your decision-making system, along with the relevant degree of accuracy.

 

  • Analysis. Whether looking at an individual trade or analysing the performance of trading models you need tools to quickly analyse Stored tic. data. Our previous experience with external analysis tools is that they were either hugely expensive or unable to keep up with data on an intra day basis. The vast majority of trade enquiries are for same day tickets. As a result our team decided to develop in house for two reasons: a) It saved on expensive external systems. b) To deliver a better analysis solution to the customer support team. E.g. providing a graphical view of the market significantly helped customers to understand their own trade enquiries, and orders were put into context in terms of Market Data where customers were able to step through market activity sequentially.

 

  • Risk. To trade in any markets at a professional level requires risk management systems. However, many Banks and Investment firms tend to be organised in silos by asset class. E.g. many banks run different systems for Rates, Credit and Swaps, let alone FX and Commodities. The MiFID II reforms demand that many of the existing risk systems will need upgrading. The questions that need asking are: a) What legacy systems will meet the new standards? b) Can we look across asset class?

The Bottom Line…….Technology is the Answer

This paper provides a snap shot of what we think are the main technology issues arising from increased regulation. Although we have focused on MiFID II and the EU, both the sell side and buy side are facing these issues on a global scale.

You would expect us to say that technology provides many of the answers, but what is clear is that in 19 months time MiFID II becomes law in the EU. Trading institutions need to look at the technology that supports their workflow now to avoid becoming the Nokia of the Fixed Income and Derivatives markets.

Related articles

  1. The findings indicate a multi-year trend of increasing fines.

  2. The regulator will consider all comments received by 16 October 2024. 

  3. Emir Trade Reporting Deadline At Hand

    On May 29, 94.55% of transactions were affirmed by the DTC cutoff time of 9:00PM ET on trade date.

  4. The rules establish EU-level ‘consolidated tapes’ across assets.

  5. Buy Side Responds to Esma on Clearing Swaps

    Legislation includes mandatory contribution from trading venues, a single consolidator model real-time data.