MIFID II Compliance: The Meinberg FAQ

By Heiko Gerstung.

(AAP Image/David Ewing)

We receive an ever increasing number of questions from our customers regarding MiFID 2 and the time synchronzation of RTS 25 and therefore decided to publish the answers here in one place:

1. What is MiFID 2 ?

The Directive on markets in financial instruments (MiFID 2) is an European regulation for financial markets. It has been published in the EU Official Journal on June 12, 2014. The directive empowers ESMA, the European Securities and Markets Authority to develop regulatory technical standards (RTS) as well as implementing technical standards (ITS). ESMA delivered three sets of technical standards in 2015. The original plan was to put these standards into effect on January 1st, 2017. Due to the high complexity and the technical challenges this has been postponed to January 2018.

2. What is RTS 25 ?

The Regulatory Technical Standard 25 is a part of the standards developed by ESMA in the context of MiFID II. RTS 25 defines standards for clock synchronization, acknowledging that this topic has a direct impact in numerous business processes of the financial industry.  The ever increasing speed and volume of financial transactions requires more accurate time stamps in business records like order books. Basically, RTS 25 covers two main topics: the time reference to be used and the required level of accuracy for time stamps used in business records.

3. What are the requirements for clock synchronization as defined in RTS 25 ?

Article 1 of RTS 25 defines that the time reference used for synchronizing the business clocks used by operators of trading venues shall be Coordinated Universal Time (UTC).

Article 2 defines the accuracy level for business clocks of trading venue operators. It specifies requirements which depend on the gateway-to-gateway latency time of a trading system, allowing the maximum divergence from UTC to be either 1 millisecond (gw-to-gw latency of > 1 ms) or 100 microseconds (gw-to-gw latency =< 1 ms). The granularity of the time stamps can be either 1 millisecond or 1 microsecond, also depending on the gateway-to-gateway latency time.

In most cases, our customers falling into the trading venue operator category face the 100 microsecond accuracy and the 1 microsecond granularity requirements.

Article 3 defines the level of accuracy for members or participants of a trading venue. A table is used to describe five different types of trading activity and like article 2 defines a maximum offset to UTC and a minimum time stamp granularity. The top requirements (100 microsecond accuracy and 1 microsecond granularity) are placed on the high frequency algorithmic trading activity class in this table.

In Article 4 the ESMA demands that operators of trading venues shall establish a system of traceability to UTC and define that it is enough to deliver proof by documenting the system design and specs. It is also required to identify the exact point at which a timestamp is applied. Finally, the article specifies that reviews of the compliance of the UTC traceability system have to be conducted annually.

4. What is UTC?

Since RTS 25 demands that the business clocks shall be synchronized to UTC. Here is a short explanation of what UTC is:

UTC is a time scale maintained by an organization called Bureau International des Poids et Mesures (BIPM), headquartered in Paris.

The time scale is derived from comparing atomic clocks of over 70 recognized atomic clocks maintainers, mainly national metrology institutes like the National Physical Laboratory (NPL) in the UK, the Physikalisch-Technische Bundesanstalt (PTB) in Germany or the National Institute of Standards and Technology in the United States. This timescale is the base for local timezones like Central European Time (CET) or Pacific Standard Time (PST), which are defined as UTC+X where X can be a positive or negative value. Central European Time (CET) is defined as UTC+1, meaning that 14:00 o’clock UTC is 15:00 o’clock CET.

5. What are Leap Seconds and why are they required?

It is important to know that UTC is by definition not bound to the rotation of the Earth, which is variable due to all kinds of effects and dynamic influences, for example tidal effects caused by the Moon. That means that one rotation does not exactly take 86400 seconds (24 hours) every day, it can differ between -0.0012 and  +0.0045 seconds each day (measurements since 1965). In order to maintain a close relationship between UTC and the Earth Rotation, the BIPM introduces a leap second in order to compensate for the cumulative difference. Due to the dynamic and unpredictable nature of the Earth rotation speed, the introduction of a leap second is decided approximately 6 months in advance by the International Earth Rotation Service (IERS), an international organization responsible for measuring and calculation of the Earth Rotation parameters. The IERS issues a document named “Bulletin C” about every six month, typically in mid January and mid June, announcing whether there will be a leap second introduced or not. Although it is theoretically possible that a negative leap second is inserted into UTC, it is doubtful whether this going to happen one day. All previous leap seconds have been positive because the Earth rotation has been slowing down. A negative leap second would require the Earth to speed up, which is not impossible but extremely unlikely.

The unpredictability of leap seconds makes it hard to handle them. A clock needs to be told that a leap second is introduced and that can only happen after the IERS decided that a leap second is coming and published its decision. There are a number of possible ways to then communicate this to each and every clock installed. If a clock has a GPS receiver built inside, it can receive this leap second announcement via GPS. In the past, the GPS satellites started to broadcast the leap second announcements shortly after the release of the Bulletin C by IERS. That means that GPS synchronized clocks know about an upcoming leap second slightly less than 6 months in advance. The network time synchronization protocols NTP and PTP also have means to announce an upcoming leap second, but they begin to send out the announcement to clients with a shorter warning time.

Meinberg offers leap second announcement updates for their LTOS V6 based products (LANTIME, SyncFire) which are available shortly after the IERS announcement and which can be installed at any time before the actual leap second happens. This is required for all LANTIME devices which are not capable of receiving the announcement via GPS.

6. Which solutions are available from Meinberg for ensuring MiFID II compliance?

In general, the technical requirements of RTS 25 have to be met by both the business clocks and by the actual systems involved in the trading, i.e. database servers, application engine servers, matching engines and order processing systems.

The standard uses the term business clocks, e.g. by stating that “Operators of trading venues and their members or participants shall synchronize the business clocks they use to record the date and time of any reportable event with the Coordinated Universal Time (UTC) …”. There is no formal and clear definition of how such a business clock looks like in reality, i.e. which device(s) can be identified as business clocks in the context of this directive. Meinberg NTP or PTP Servers are not directly “used to record the date and time of any reportable event […]”, therefore it is probably a good assumption that the term “business clocks” refers to the system time / operating system clock of the servers involved in recording reportable events (and their time stamps). Our time synchronization solutions are used to synchronize these “business clocks” and can be considered an important part of the cited “system design” that ensures traceability to UTC. Since the accuracy on the “business clock” systems cannot be better than the accuracy of their synchronization sources (time references), the accuracy of Meinberg servers obviously not only has to meet the specified requirements in Article 2 and 3, it has to exceed them. The error budget for time errors (maximum divergence from UTC) is already very demanding for trading servers that are, unlike Meinberg systems, not optimized for time synchronization accuracy and stability. It is therefore important, that the lion share of the allowed error budget (e.g. 100 microseconds) is available for the systems creating the time stamps.

It is common understanding in the technical community that the 100 microsecond requirement cannot be fulfilled easily by using NTP to synchronize the time stamping systems. It is not impossible to synchronize a system clock of a server to less than 50 microseconds using NTP. However, in the past this has only been achieved in near perfect, NTP optimized network  environments and only with selected hardware (read: server models/mainboards) and software (read: OS and NTP implementation). The assumed accuracy of 50 microseconds for an NTP based time synchronization of a server would already eat 50% of the allowed error budget of a 100 microsecond class trading application. Therefore, most synchronization and network engineers agree that the synchronization solution that aims to comply with MiFID II / RTS 25 should be based on using PTP as the method for time transfer between the reference clocks and the actual application servers that have to create MiFID II compliant time stamps.

In regards to the reference sources, there is a common understanding that GNSS (GPS) is providing UTC traceable time. However, this is subject of a debate, with the main question: what is the definition of traceability to UTC in the context of this directive? There are some articles about traceability available online,  one example is this white paper created by NPL and available from ESMA as a download: https://www.esma.europa.eu/file/16989/download?token=qCLY-NSq

In order to provide an alternative to GPS, NPL offers a service called NPLTime which provides a time traceable to UTC(NPL) using IEEE 1588 as a transmission protocol. NPLTime is available at certain data centers in and around London and is directly traceable to UTC. The service uses Meinberg M1000 servers to transfer time directly taken from the atomic clocks of NPL over long fiber connections to certain central places where users can get a UTC traceable PTP feed from the local M1000 clock.

7. What about the annual compliance review?

Article 4 of RTS 25 requests an annual review to demonstrate compliance based on documentation of the synchronization system. This obviously cannot provide proof that the installed synchronization infrastructure and the application servers / trading systems fulfilled the accuracy requirements at any time during that 12 month review time frame.  So, basically this seems to indicate that an online monitoring of the synchronization performance – or the accuracy of your business clocks –  is not required to demonstrate compliance. However, there are several good reasons for establishing a monitoring solution.

8. Why and How should I monitor my Business Clocks?

One reason is that it is crucial to be prepared for a potential future lawsuit, whose outcome could depend on whether you can deliver proof that the business clocks of your involved systems have been within the allowed requirements as defined by RTS 25. Another is the operational point of view: your trading systems rely on synchronization already, especially if you are into algorithmic trading you are correlating information from multiple sources all the time to create or drop buy/sell decisions. In this specific case your solution most probably already achieves synchronization accuracy levels that are far below what ESMA allows. However, monitoring time sync accuracy is not an easy task, the only chance to determine the time error of a clock is to compare it with a more accurate clock. However, if you have a more accurate clock available at a specific location, you would normally want to use it as a reference for your time synchronization and then you need an even more accurate clock to monitor this one.

Meinberg developed a PTP monitoring solution with  MiFID II compliance in mind and currently works on implementing the concept in our products. We are cooperating with a number of companies and vendors of PTP stacks to ensure that support for this monitoring approach will be built into as many PTP implementations used in todays (and tomorrows) financial networks. The monitoring system will however not be limited to MiFID II related applications, it is universal and can be used to monitor the performance of PTP installations in a lot of different industries and application spaces. More details about this solution will be published in the upcoming weeks, so please stay tuned and look out for this on the Meinberg website and blog.