Among major MiFID II innovations is the requirement put on all trading venues to synchronise the business clocks they use to record the date and time of any reportable event.

 

The respective legal basis is Article 50 of MiFID II, which imposes the obligation of trading venues and their members and participants to record the date and time of any reportable event using an accurate time source.

 

Details of this new framework have been further stipulated in the Commission Delegated Regulation (EU) 2017/574 of 7 June 2016 supplementing Directive 2014/65/EU of the European Parliament and of the Council with regard to regulatory technical standards for the level of accuracy of business clocks (RTS 25).

 

The essence of new provisions on clock synchronisation is accurate and reliable time-stamping i.e. recording of date and time when execution, pre- or post-trade publication, etc., occurs, for the purpose of establishing evidence that data existed at a particular time.

 

According to the Annex to the said Regulation trading firms’ and venues’ business clocks must be synchronised with Coordinated Universal Time (UTC) - the designation formally accepted in 1960 and substituted for the Greenwich Mean Time (GMT) as from 1974 the as the sole, global standard.

 

Under the RTS 25 the maximum divergence from UTC is to be either one millisecond or 100 microseconds (each microsecond is one-millionth of a second).

 

For members and participants in the trading venues the particularly relevant items of the said Regulation are the Table 2 (Level of business clock accuracy) in the Annex and Articles 1 and 4.

 

Members and participants in the trading venues are required by the RTS 25:

 

1. to synchronise the business clocks used to record the date and time of any reportable event with the Coordinated Universal Time (UTC) issued and maintained by the timing centres listed in the latest Bureau International des Poids et Mesures Annual Report on Time Activities (business clocks may also be synchronised with UTC disseminated by a satellite system, provided that any offset from UTC is accounted for and removed from the timestamp);

2. to establish a system of traceability to UTC, in particular:

- to be able to demonstrate traceability to UTC by documenting the system design, functioning and specifications,

- to be able to identify the exact point at which a timestamp is applied and demonstrate that the point within the system where the timestamp is applied remains consistent,

- conduct reviews of the compliance of the traceability system at least once a year.

 

 

Table 1: Level of business clock accuracy for operators of trading venues

 

 

Gateway-to-gateway latency time of the trading system	Maximum divergence from  UTC	Granularity of the  timestamp
> 1 millisecond	1 millisecond	1 millisecond or better
< 1 millisecond	100 microseconds	1 microsecond or better

 

 

Table 2: Level of business clock accuracy for members or participants of a trading venue

 

 

Type of trading activity	Description	Maximum divergence from UTC	Granularity of the  timestamp
Activity using high frequency algorithmic trading technique	High frequency algorithmic trading technique	100 microseconds	1 microsecond or better
Activity on voice trading systems	Voice trading systems as defined in Article 5(5) of Commission Delegated Regulation (EU) 2017/583	1 second	1 second or better
Activity on request for quote systems where the response requires human intervention or where the system does not allow algorithmic trading	Request for quotes systems as defined in Article 5(4) of Delegated Regulation (EU) 2017/583	1 second	1 second or better
Activity of concluding negotiated transactions	Negotiated transaction as set out in Article 4(1)(b) of Regulation (EU) No 600/2014	1 second	1 second or better
Any other trading activity	All other trading activity not covered by this table.	1 millisecond	1 millisecond or better

 

 

In the face of increasing speed and volume of financial transactions, among those particularly affected may be High Frequency Trading (HFT) firms.

  

As the Bloomberg reports (“Lack of Awareness Surrounding MiFID II Deadline Could See €5m Fines”), to date, one of the most common methods currently used for timestamping is Network Time Protocol-based Internet Time - method that is only accurate to the tenth of a second and while suitable for human trading, it cannot remain a solution for high frequency trading HFT and non-HFT.

 

These methods require 100 microsecond and one millisecond accuracy respectively, under RTS 25.

 

 

“Reportable event”

 

 

Under Article 1 of the RTS 25 the requirement to synchronise the business clocks with the UTC relates to the recording of the date and time of any “reportable event”.

 

It is argued (Bloomberg, “The Advantages of Timestamping Beyond MiFID II Compliance – Part II”) that at the trading terminal, “it would be safe to assume that timestamps related to any trading instructions or orders submitted from the terminal will need to be recorded”.

 

Moreover:

 

- when it comes to automated or algorithmic component of a strategy or system, where the algo engines are programmed to automatically place trades based on a predefined set of instructions or triggers and the most stringent microsecond timestamping and synchronisation applies, the accurate time stamps will need to be recorded both when any instructions are received from the terminal, when the specific signal that triggers an order is received by the system, as well as exactly when the order is sent;

- timestamps should record the time the exchange gateway receives the order and the exact times that each ‘chunk’ of the order is sent to an exchange;

- employing time synchronization at the network level enables firms to ensure a complete and accurate view of the market, or at least the exchanges and liquidity venues to which it is connected, and in turn prove that best execution was achieved.

 

Generally, the new requirements are perceived as complex and costly, 100% synchronisation at all times is said to be at this point in time “technically impossible” within reasonable resources (TheTradeNews, “MiFID II's algo plans come under fire”).