It’s Time to Clock-Sync Your Data
MiFID II requirements for clock-synchronization, as summarized in RTS-25, require firms and venues to timestamp events accurately relative to Coordinated Universal Time (UTC) and to an appropriate level of granularity depending on where a trade is executed and the gateway-to-gateway latency of the venue. Specifically, Article 4 of RTS-25 states “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.” ESMA/2015/1909 Section 3.1 further clarifies the use of UTC clock-synchronization for “reportable events”.
Over the past several years we have worked with the leading venues, participants and market makers throughout the world to develop robust, cost effective and accurate methods to record the timing of electronic trading events. We have found that accurate and precise timestamps of electronic trading events are a critical first step in making sense of these events in terms of latency measurement, forensic investigation and surveillance of trading activity.
Time-keeping technologies such as NTP and PTP are readily available today. Both technologies can deliver time-signals to well within the tightest divergences specified in MiFID II (100 microseconds). However, achieving tight divergences reliably and consistently is not always easy. NTP and PTP each have strengths and weakness when it comes to reliably and consistently achieving the tightest divergences specified. Reliability and consistency of reporting should be a key requirement for any regulatory reporting system.
Given these strengths and weaknesses, we have found that it is often not sufficient to deploy a network-based time-keeping protocol and assume it will work correctly.
Methods for measuring and applying timestamps to electronic trading events fit into two broad categories:
These two time-stamping measurement methods (hardware and software) can be used to create three timestamp data sources for trade execution events:
In practice the three data sources lend themselves to specific use cases.
Application Timestamps are generally used to record the time at which a specific decision was made by the trading application. For example, the time at which a matching engine made a trade. This event time would be when the matching engine software made a match decision between buyer and seller. Typically, this time is recorded in the log file and inserted into the order execution response message for third parties to retrieve and use in their operations.
Host Timestamps are generally used to record the time a specific message was received or sent by the host machine. For example, the time a gateway receives an order or sends an order response. The exact location where this measurement is made in the host stack can vary. It can happen at the socket layer or deeper within the software stack. This can introduce some level of variability and ambiguity in comparing event times between host machines.
Wire Timestamps are most often used to unambiguously determine when a specific message was received and when it was sent by a trading function. For example, wire timestamps are frequently used to unambiguously determine when a gateway received an order or when it sent an order. In practice, wire timestamps tend to be more reliable and precise as there is no variability and ambiguity as to where in the host stack the measurement is made. Reducing measurement variability and ambiguity becomes important when reconstructing events across multiple systems. Wire timestamps are broadly used throughout the industry for troubleshooting potential causality issues with application and host based timestamps.
The intent of MiFID II time-stamping requirements is to forensically verify and survey the specific sequence of reportable events leading to a transaction outcome, it is important to understand the causality relationships between the available timestamp data sources.
Figure 1 shows a general picture of a host machine processing incoming events from the network wire, processing them and responding with a sequence of outgoing events. This is typical of the situation we encounter with trading gateways, smart order routers and matching engines. In this example, the host machine is UTC synchronized via PTP distribution of the clock signal to the host machine.
Figure 1: Wire, host timestamps, and application timestamps for measurement and recording of reportable electronic trading events.
Wire timestamps are typically implemented using specific purpose hardware and tend to be more accurate and reliable. For this reason, they are often used to calibrate and troubleshoot potential problems with host and application timestamp measurements to assure correctness and fidelity.
For a more detailed discussion of Corvil’s implementation experience and best practice recommendations for implementation of RTS-25, please download our ebook here.