We need clarification on Article 3 of RTS 25 especially with respect to the latency we have between an application reading the time from clock(s) and actually applying that time to an event. We requested a Big Four consultants view but it was pretty useless.
There are two parts to applying a UTC timestamp to an event:
Part 1 is the clock source sending time to a host server. This can be monitored by using the time protocol which gives us detailed statistics on the inaccuracy of a server vs UTC. And we can monitor and adjust the drift within 15 seconds (we poll every 15 secs for drift)
Part 2 is the application running on the host server reading the time from host server and applying the timestamp to reportable transactions. There is a delay between when the application requests the time from the host and applies the timestamp to a record. Currently there is no way for us to know how much this delay is.
Question: Does the tolerance limit (1ms for electronic transactions) apply only to Part 1 or both Part 1 & Part 2?
How would we manage what could be vastly differing latencies on different application stacks?
Any thoughts greatly appreciated.
There are not two parts as such but two distinct sets of measurements. In the end traceability is from the exact point at which a timestamp is applied, where traceability is generally taken to be a chain of unbroken measurements between the point of the reading and the reference source.
As such most people are using a protocol such as PTP/NTP to discipline the system clock to within a define accuracy budget. What that budget is will depend on your overall setup and needs. Taking this one step at a time.
It is generally accepted that the uncertainty (the amount of uncorrectable error) in your time reading is most in the software stack. As such you need to determine the range of this and then ascertain that the related uncertainty of your system clock disciplining is accurate enough for you to meet the overall target.
In your software stack you can measure the time it takes to read your clock. You need to be careful to read this in a typical usage and not using a benchmarking tool that will optimize the results. In our tests a typical clock_gettime call on a Linux machine will cost about 250ns under such a test, it is the outliers, however that you need to take into consideration and these can easily reach 50usecs or more. In other technology stacks this will vary further still.
Having established the outliers you can assign this as the uncertainty of your clock read i.e. the time read I +/- N usecs from the time your read as you do not know where in that window of read latency the time was actually read.
If N is 100usecs then you have 900usecs of your 1ms budget left. This in turn tells you that you will need to ensure that your system clock can never be more than 100 usecs wrong. Whether 15 seconds is frequent enough to keep your system clock accurate to within 100 usecs will need to be tested and if necessary you’ll need to discipline more often to ensure that a tighter time is maintained.
I hope this helps answer the question.
Regards
Neil
co-chair MiFID clock sync working group
1 Like
Hi Neil,
Thanks for the details. Can you suggest how we can measure the time taken to read the clock. Is there a software in the market which can do this? What are other financial organisations doing for this aspect.