Although we’re just technologists here, and not experts on European Union Regulatory Law, MiFID II is very specific:
Operators of trading venues and their members or participants shall synchronise the business clocks they use 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. Operators of trading venues and their members or participants may also synchronise the business clocks they use to record the date and time of any reportable event with UTC disseminated by a satellite system, provided that any offset from UTC is accounted for and removed from the timestamp. Regulatory technical and implementing standards – Annex I MiFID II / MiFIR
In the Cost Benefit Analysis:
“The final draft RTS also reduces costs of the initial draft RTS proposed in the CP by allowing UTC disseminated via satellite systems (i.e. GPS receiver or the use of other satellite systems when available)”
So the drafters of the regulations are specifically claiming that cost of meeting standard has been limited by making GPS time an acceptable substitute for time coming directly from the national labs. It’s worth noting that time coming directly from the national labs is an estimate of official UTC time which is only determined after the fact by consensus of times from various atomic clocks. For the purposes of financial trading, however, it’s hard to imagine how any of that matters.
GPS time is fragile, so features like SkyMap (above) which helps manage GPS receivers become absolutely essential. Other sources of time – such as the direct feed from the UK’s NPL clocks – suffer from the same problem of fragility. If a switch connecting any source of time to a group of computers fails or even is mis-configured, time quality can suffer. TimeKeeper’s multi-source addresses this issue. To me, the most significant feature of MiFID II timestamping is that accurate timestamps have to be maintained in the face of network events and other issues. Just hanging a GPS clock off a switch or connecting that switch to some terrestrial source is not going to provide the robust time synchronization that the new regulations rely on. In fact, whether a data center is connected to GPS or to a national lab’s atomic clock is not going to make a significant difference in the accuracy of the time on appliction servers that are generating timestamps.
What does ESMA mean by the “offset from UTC”? This is made clear in the document “2014-548discussionpaper_mifid-mifir” where there is an extensive discussion:
There are arguments against using GPS, though: the main one is that GPS and UTC times don’t coincide (GPS time is currently ahead of UTC by 16 seconds because leap seconds are introduced in UTC time to take account of an offset linked to earth rotation). This argument disappears if we consider adjusting GPS time by a correction factor (official difference between GPS time and UTC time) to avoid changing current industry practices based on UTC.
So, if we take leap-seconds into account GPS (and other satellite time) is acceptable. This is only reasonable because the differences between UTC and GPS and GNSS time once leap-seconds are taken into account are in the order of a few nanoseconds. However, this section does make the issue of leap-second handling more interesting. My guess is that ESMA will have to clarify exactly what they want done during leap-seconds because it is impossible to stay on UTC and simultaneously (if I can use that word in this weird context) accurately timestamp records. One approach will be to require slewing time and documenting the slew. We will see.
