Markets in Financial Instruments Directive II (MiFID II)
The European Union has established new comprehensive rules for investment services,
commonly referred to as MiFID II (or MiFID 2). The regulations include requirements for the synchronization of clocks
and maintaining related audit trail information. In particular, Article 50 of MiFID II applies to trading venues and
their members and participants and requires them to comply with accuracy requirements regarding the maximum divergence
of their business clocks from UTC and to timestamp reportable events to a specific granularity.
Basic Regulatory Requirements
The MiFID II Draft regulatory technical standards on clock synchronization (Regulatory Technical Standards, RTS, 25) specifies
these basic requirements:
UTC Reference Time
Clocks must be synchronized to UTC (Coordinated Universal Time).
"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."
Maximum divergence from UTC
Clocks must be synchronized to UTC within a minimum accuracy target. The accuracy target differs by the type of trading system
(computerized trading vs. high-frequency trading). Machines using high frequency algorithmic trading technique must synchronize
to within ±100 microseconds of UTC. All other computerized trading systems must be synchronized to within ±1 millisecond of UTC.
(RTS Annex Table 1)
Timestamps must be recorded to specified precision for the type of trading system (computerized trading vs. high-frequency trading).
Machines using High frequency algorithmic trading technique must have a timestamp precision of at least 1 microsecond.
Note that does not mean clocks must be synchronized to microsecond accuracy, but that the number of decimal places used
in measuring/recording the timestamps shows the data in microseconds. All other computerized trading systems must record
timestamps with at least 1 millisecond precision.
(RTS Annex Table 2)
Timestamps must be documented as traceable to UTC.
"Operators of trading venues and their members or participants shall establish a system of traceability to UTC. They shall be
able to demonstrate traceability to UTC by documenting the system design, functioning and specifications. They shall 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. Reviews of the compliance with this Regulation of the traceability system shall be
conducted at least once a year."
How to use Domain Time II to comply with MiFID II time sync regulations.
You can easily meet or exceed the MiFID II requirements by using Domain Time II Servers, Clients, Manager, and Audit Server components
to synchronize, measure, and document your time synchronization.
UTC Reference Time
All Domain Time components can be set to use UTC time sources, either for time synchronzation or to use as reference time for accuracy measurements.
How to do so specifically depends somewhat on your chosen time distribution hierarchy.
In general, it's best to have at least one satellite-synchronized hardware time appliance (GPS, GNSS, etc.) on premises to use as
your top-level UTC source. This device may serve NTP and/or PTP protocols.
You may use the distributed domain hierarchy common with NTP or DT2 protocols (i.e. UTC hardware clock -> Domain Time Server(s) -> Domain Time Clients) or
a flat-hierarchy such as used by PTP (all Clients/Servers connect directly to the UTC hardware clock). In either case, Domain Time
components will log all transactions showing their time source, so you have direct traceability to UTC for time synchronization.
In addition, Domain Time Manager (and by extension, Audit Server) can be set to use UTC sources as the reference clock for all
time delta measurements, alerting, and time auditing so you can use and create documentation of synchronization showing UTC traceability.
Domain Time Manager/Audit Server can monitor, audit, and retain
time synchronization records from Windows, Linux, PTP devices, and more.
Maximum divergence from UTC
As indicated, the regulations require different levels of time synchronization accuracy depending on your trading application.
High-frequency algorithmic trading systems
These systems must be synchronized within ±100 microseconds of UTC. Although recent versions of Windows (2012/Win8/2016/Win10 and later) may be able to achieve this
accuracy on well-provisioned modern hardware using only NTP, the most practical way to achieve this level of accuracy (and the only way on Vista, 2008, 2008r2, or Win7 systems) is
to use PTP (IEEE1588-2008/2019). See the PTP documentation on how to configure Domain Time for PTP synchronization.
Follow the instructions there carefully to achieve maximum accuracy.
Other computerized trading systems
These systems must be synchronized within ±1 millisecond of UTC. This is easily achievable on any version of Windows using
the NTP, DT2, or PTP protocols. Use these recommended settings:
If using a distributed hierarchy (UTC clock -> Domain Time Server(s) -> Domain Time Clients),
use at least 3 time sources on your top-level Servers (or, if only one UTC source is available, set to sample it 3 times)
Use a fixed synchronization rate of at least 1 per minute on all your Servers and Clients
All Domain Time components are capable of hectonanosecond precision internally (that's one more decimal point of accuracy beyond the
required 1 microsecond precision).
Domain Time Server and Client record all time transactions in hectonanoseconds. Domain Time Manager and Audit Server can
also record time deltas, measurements, and audit data in up to hectonanosecond precision. The level of precision is configurable
on Manager's Options -> Appearance and Interface -> Format Options menu page.
Use the Significant digits to show: dropdown to select Microseconds.
Reading the Windows local clock in high precision from your application
Note that although both Domain Time and the operating system internally keep time to hectonanosecond precision, the normal
Windows clock API GetSystemTimeAsFiletime only provides time to a best-case precision of 1 millisecond.
If your version of Windows is XP, 2003, Vista, 2008, or Win7, you will need to use a .dll from the Domain Time Software Development Kit (SDK)
in order to read the system clock in the required microsecond precision for HFT systems. The SDK can be obtained from
Greyware Automation Products, Inc.
For OS versions Win8, 2012, 2012r2, Win10, 2016 or later, you may use the built-in GetSystemTimePreciseAsFileTime API.
As mentioned above, you may configure Domain Time to obtain its time from UTC sources, and Domain Time Manager and Audit Server
can also be configured to use UTC as the reference clock for all
all measurement and auditing purposes.
This information is maintained in all audit records and synchronization logs
collected by Audit Server. Using this information, you may easily demonstrate the synchronization status and UTC provenance of any machine at any
You may use this information as part of your documentation in demonstrating design and compliance.
This document is provided for informational and planning purposes only. The information used in compiling this document was obtained from
publically available sources and no representation is made as to the accuracy of the information, nor
as to the accuracy of any reading or interpretation thereof. No warranty is made or implied regarding the usefulness or suitability
of this information for a particular purpose. Further, Greyware Automation Products, Inc. is not liable for any damages, real or
consequential, arising from use of this information.