Atomic clocks were in the news earlier this month with UBS signing a deal with the UK's National Physical Laboratory for a trusted timestamping service. Chris McConville, global co-head of equity electronic agency trading at UBS said:
The NPLTime solution will provide UBS infrastructure with a stable, accurate and resilient time signal whilst simplifying the MiFID II time synchronisation traceability requirements."
This is likely to raise the bar for other brokers to follow as they try to get ahead of the challenge of assuring compliance and transparency demanded by ESMA RTS-25.
Yet deploying resilient time-distribution systems isn’t quite a straightforward proposition. UBS’s Annie Austin and Thomas Lee co-published an instructive research paper with NPLabs. It describes the trial configuration and the results of their testing. The deployment included a PTP-enabled switch connected to the NPLTime® distribution hub, PTP interface cards on the test trading server, a low latency network. One can just imagine how that would have to expanded across their entire trading infrastructure.
It wasn’t surprising to us that their initial results found that “measurements at the UBS server, however, were substantially outside expected values.” Nor it is surprising that it took some clever detective work to uncover the root cause and implement new infrastructure to get the results required for compliance.
As we’ve discussed in our clock management best practices eBook: PTP is a newer protocol which leaves the disciplining of local clocks up to the implementation. In our experience, implementation of clock disciplining can vary widely in sophistication and level of effort undertaken to iron out issues such as variable delays (ie jitter). The UBS paper demonstrates effort required to deploy a traceable time signal to every server.
However, MIFID compliance is not only about getting a good signal at the server. As the UBS paper notes:
It is not enough to have a time source feeding systems; it is critical to understand and manage how time is delivered, distributed and consumed.”
Their experience reinforces why our solution engineers are constantly reminding our clients time-stamping is not a “set it and forget it” effort. It’s not enough to deploy, configure and calibrate a time distribution solution and assume it will work correctly for ever after. It is critical to implement appropriate sanity checks on the timestamps being recorded.
Our CTO Raymond Russell knows a lot about implementing timestamping sanity checks. He always says that it’s best to check for apparent violations of causality, which simply means looking for instances where it looks like event B caused event A when the opposite is really true. In other words, understanding how your carefully configured time distribution solution is disciplining server clocks, as UBS has done, is the first step. The next step is figuring out how to independently check on what is actually happening after deployment, so that your time distribution “ever after” can be happily fine-free.
Having lived through many early implementations of accurate timestamping with clients, we are in favor of best practices that makes implementation and ongoing sanity checks Simpler, Faster, Cheaper.