MiFID II Time Synchronisation – Achieving Compliance
By Rob Skinner, Sales and Support, Time and Frequency Sychronisation Systems
The revised Markets in Financial Instruments Directive (MiFID II) will be implemented across financial markets from January 2018. As part of the new regulations, trading venues and their members are required to synchronise their internal trading networks within a fixed variance from universal co-ordinated time (UTC). Trading venues are also required to annually demonstrate compliance, based on documentation for the synchronisation system.
APC Time has over 15 years specialist expertise in specifying time and frequency synchronisation systems for financial markets, investment banks, broker-dealers and credit institutions.
We work with each of our clients, in complete confidence, to provide a bespoke solution that ensures they meet MiFID II RTS 25 compliance on an ongoing basis. Below, we provide answers to the commonly asked questions about meeting the new requirements. For a more detailed discussion about the steps your organisation will need to take to be MiFID II compliant, contact our team of time and frequency system specialists on 01522 596 570 or email email@example.com
What accuracy is needed within a High Frequency Trading network for MiFID II?
The RTS 25 regulations specify a deviance of no more than 100 microseconds from UTC within High Frequency Trading (HFT) environments, or 1 millisecond latency from UTC within all other non-human trading environments. A tight variance means that the master source of time needs to be as accurate as possible to allow for any unexpected jitter on the network which could increase the delay of the timing packets and therefore the end time of the client.
It is extremely difficult to fulfil this 100 Microsecond requirement by using a standard NTP timeserver, as NTP is not accurate enough in standard network environments. Therefore, to allocate as much error margin as possible it is highly recommended to use a PTPv2 Grandmaster clock, PTPv2 compliant switches and application servers to create MiFID II compliant time stamps.
APC Time can provide flexible solutions for PTPv2 Grandmaster Clocks through the Meinberg Lantime IMS range of time servers, these systems can be individually customised based on the requirements of the end user and the network.
What sort of accuracy can I expect from the clock to the server if I use PTPv2?
It is not possible to provide a figure regarding the overall latency of the network path as this depends on many different variables within each individual network. One example would be whether the entire network path is PTPv2 compatible; if switches are not PTPv2 compatible then it will add unknown delay to the end gateway, which the PTPv2 protocol will not be able to account for increasing the deviance from UTC.
Other variables to consider would be whether the PTPv2 packets will always follow the same network path from the Grandmaster to the end gateway (symmetric delay) rather than different network paths to and from the end gateway (asymmetric delay) as well as other factors such as network bandwidth and the type PTPv2 profile used.
How can it be proved the time is traceable to UTC?
ESMA confirmed on the 10th October 2016 that synchronising to GNSS is acceptable, as long as the time broadcast is in UTC, as per the below statement:
“The use of the time source of the U.S. Global Positioning System (GPS) or any other global navigation satellite system such as the Russian GLONASS or European Galileo satellite system when it becomes operational is also acceptable to record reportable events provided that any offset from UTC is accounted for and removed from the timestamp. GPS time is different to UTC. However, the GPS time message also includes an offset from UTC (the leap seconds) and this offset should be combined with the GPS timestamp to provide a timestamp compliant with the maximum divergence requirements in RTS 25.”
What if the GNSS synchronisation is lost? Would the network still be compliant?
This depends on the remaining error budget that is left over when the network has been finished. Meinberg systems can be provided with different types of oscillator which allow the Grandmaster Clock to hold the time for a certain period after GNSS synchronisation is lost.
Choosing which oscillator to include is a difficult situation as the remaining ‘error budget’ needs to be known to ensure that the drift of the oscillator does not influence the time on the PTPv2 packets to an extent that would put the network out of the compliance specifications. For example, if a Meinberg Lantime/M1000/IMS system was equipped with an OCXO-HQ oscillator and synchronised to a GNSS signal only and installed in the network, there would have to be at least 22us available in the ‘error budget’ to allow the Grandmaster to continue providing PTPv2 synchronisation for 1 day. The OCXO-HQ has a quoted time drift of 22us a day, worst case, after being synchronised to a GNSS signal for 24 hours.
Higher quality oscillators would allow for a higher holdover, but also scale in cost, for example a Rubidium backup oscillator would offer a worst case time drift of 1.1us a day, but the price point is also higher than OCXO-HQ oscillator, or a spare antenna for such an eventuality.
Other alternatives would be to have an independent PTPv2 feed for the system to fall back to in case of loss of GPS, with the oscillator only as a last resort method, as the likelihood of the both the GNSS and PTPv2 feeds failing at 2 sites at the same time, are extremely slim.
What alternatives are there to GNSS synchronisation?
As mentioned previously, one alternative is to install another Grandmaster Clock and a separate location and then provide a direct PTPv2 feed as a backup to GPS. There are services in the UK that provide this PTPv2 feed, such as NPLTime® and these services offer traceability certificates along with the systems which is useful for auditing purposes in proving that the time is traceable to UTC.
There have been some queries regarding the use of Atomic clocks to keep the time in the network stable via a PPS input, however it is prudent to remember that a PPS input has no time of day information, it can only lock the phase of the oscillator. This can lead to situations where the PPS is ensuring that the system has a perfect second, but because there is no time of day information the system could be a year adrift and still be reporting as locked to PPS. It is also important to note that a simple PPS input from an Atomic clock does not transmit leap second information, which PTPv2 is capable of doing.
If a PPS is used in combination with an input that provides time of day then Atomic clocks are a feasible alternative, however the cost of such a solution would have to be weighed up against the cost of simply installing another PTPv2 Grandmaster Clock in another location which provides accurate synchronisation and time of day over the same connection.
What are leap-seconds and why are they important for the RTS25 regulations?
Leap seconds are increments of correctional time to correct the effect of the non-standard rotation of the Earth. The rotation of the Earth is not uniform, as the length of the day drifts, it becomes necessary to adjust UTC to match this offset, hence the introduction of leap seconds.
The leap seconds are important for RTS 25 because, as stated above, the time on the network needs to be provided in UTC. If a leap second update is not processed properly through the equipment, then the network will deviate by 1 second from UTC. GNSS synchronised systems normally receive the leap second information automatically, as all leap second announcements are broadcast through the GNSS satellites.
It is important to test how the network will handle the addition of a leap second and whether all of the equipment installed is able to deal with the leap second. If some equipment does and some does not it can lead to varied time across the network, which is arguably worse than the entire network being 1 second out of time.
What about the auditing of the network?
Article 4 requests an annual review to demonstrate compliance to the MiFID II regulations. The regulations do not state the need for monitoring the network between the compliance reviews, however it is highly recommended that a monitoring solution is considered and implemented.
One of the major incentives for implementing a monitoring solution into the network is simply in case the yearly review fails and it had to be proved in court whether the network has been in compliance throughout the majority of the year, and the reasons why it was not in compliance on the day of review.
If it can be proved that for 99% of the year the network has been in compliance, and on the day of the review the time drifted due to a GPS jamming incident which caused a loss of primary synchronisation, then it makes it much more likely to win a potential lawsuit than if there was no evidence to prove the network was in compliance throughout the year.
Meinberg have developed a monitoring solution for the MiFID II regulations which incorporates an extension to the existing PTPv2 protocol to directly measure the selected end clients’ delay, rather than rely on self-reported status of the clients. The delay information gained from the monitored clients can then be displayed in graphical format via the web interface of the Meinberg system, allowing for quick processing of information for auditing purposes, or alternatively download and remotely stored for processing and evaluation.