Time is a precious thing. In the trading environment, the difference between microseconds, nanoseconds, picoseconds and femtoseconds – the smallest quantifiable units of time -translate to the difference between profit and loss, success and failure.
The issue is, of course, that time is ambiguous. What is 10am GMT to one clock is 10:00:01 to another. But in trading, that can’t happen. UTC (Universal Coordinated Time) is the gold standard and tracking trades to UTC is essential, particularly under MiFID II. That’s why clock synchronization is vital.
MiFID II and traceability
The RTS 25 directive stipulates that banks have to demonstrate traceability and trades have to be timestamped to within 100 microseconds of accuracy and tracked to a particular ‘business’ clock. This is why network latency is important, as RTS 25 demands you have a consolidated view that can be referenced to a certain point in time.
Each change of event – initial client order, initial decision to deal, when the deal is made – needs to be recorded with microsecond granularity or better. So the technical challenges of MiFID II relate to the clock itself, the organizations involved in the trade and the granularity of the time stamp.
Resiliency
MiFID II demands that the trade has to be traceably good, 100 per cent of the time. If there is a fault in the system – for example, the usual disruptions you get as part of network functioning – there has to be resiliency. To cover yourself, you have to have the right level of resiliency built into your infrastructure.
Resiliency is one of the reasons you need multiple clocks – a combination of sources such as GPS, eLORAN and a managed traceable PTP (Precision Time Protocol) service, the direct-fibre NPLTime from the National Physical Laboratory clocks would work well. You can’t be solely reliant on GPS, for example – if a hurricane were to hit and GPS went down, you need a back up plan. The level of traceability from GPS by itself is not sufficient to be traced back to UTC – there are status updates and alerts about each satellite constellation that need to be tracked too. A comprehensive solution means monitoring information from many sources.
The next tier of problem is distributing your traceable, resilient time within your trading infrastructure – getting timestamps to the business clocks so that the overall ‘latency budget’ of 100 microseconds accuracy is not exceeded.
And it’s not just your clocks – you might be using different vendors, all of which could have a number of different clock sources themselves. Understandably, clock synchronization is a massive problem within the investment banking industry, particularly in light of MiFID II.
A stitch in time – what can you do?
Institutions have to be able to stitch together these complex flows. And be able to timestamp within applications, as well as on the network. Being able to gather statistics on all the different types of data and deal with the different sources of data is essential for MiFID II compliance. Also tracking events as they happen in the application and on the network, and producing analysis on business processes, produces important information for the regulator. And collecting information and metrics on the quality of the timestamp can be invaluable, as you can be alerted if there is a divergence from UTC. It is not just about tracking the transaction flow, but also about the monitoring the quality of the timing at every point.
The trading environment is complex enough. And MiFID II makes it much more so. With clock synchronization and time stamping, you can’t afford to get it wrong – the regulator will penalize you heavily if you do. And getting it right has a positive impact on the bottom line. The clock is ticking, so making sure they are ticking right needs to be a number one priority.
