Electronic TradingRTS-25: Clock-Sync

It’s Time to Clock-Sync Your Data

RTS-25: Clock-Synchronization of Trade 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”.

UTC Time Sources, Distribution and Timestamps

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.

NTP Strengths

  • Mature protocol
  • Most systems use the same implementation for divergences within 1 millisecond

PTP Strengths

  • Standardizes aspects of network time-synchronization for much tighter divergences
  • Can achieve well below a micro-second of divergence with right hardware deployment

NTP Weaknesses

  • Requires extensive modifications for tighter divergences
  • Modifications may become un-supportable by anyone but the original engineer

PTP Weaknesses

  • Newer protocol still ironing out wrinkles in early implementations
  • Leaves the disciplining of local clocks up to the implementation
  • Implementation of clock disciplining can vary widely in sophistication

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.

Overview Of Timestamp Methods For Trade Event Measurement

Methods for measuring and applying timestamps to electronic trading events fit into two broad categories:

  • Software Timestamps – these are timestamps applied to a specific event of interest using software running on a host machine that is synchronized to a reliable clock source.
  • Hardware Timestamps – these are timestamps applied to a specific event of interest using specific purpose hardware in a network switch or a network interface card (NIC) in a host machine.
    In general, hardware based timestamps are more reliable, have higher time precision (i.e., nanoseconds) and are less ambiguous. However, some complex trading events involving decision to trade require the use of software timestamps that are accurately synchronized to a UTC time source.

These two time-stamping measurement methods (hardware and software) can be used to create three timestamp data sources for trade execution events:

  • Application Timestamps - These are timestamps made inline by software running on a host machine.
  • Host Timestamps – These timestamps are made inline by software running on a host machine.
  • Wire Timestamps – These timestamps are made passively by hardware that takes a copy of the network packets, timestamps the packets and then decodes the underlying messages to recreate the trading context of the traffic, e.g., orders and/or market data.

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.

Measurement of Time-stamped Trade Execution Events

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.