In part one, I talked about the time synchronisation requirements coming into effect with regulations like MiFID II.  Today I’d like to delve into some of the challenges that await us in tackling these requirements. Like any good sequel, this is where we take the concept from the original and expand it!  Be warned however that as the middle act this is where we come up against seemingly insurmountable obstacles, where all might seem lost, but don’t worry we’ll talk solutions in part three. 

First, let’s be clear that linking servers to time sync services is nothing new.   There was FINRA’s OATS rule in 1998 and I can personally remember implementing NTP on a market data infrastructure in the early 2000s.  The difference here is the levels of accuracy required.  But synchronising your clock is one thing, keeping it in sync is quite another.

Stick with me here, it’s analogy time. 

Think of the system clock on one of your servers as a boat, let’s call it the Orca. 

Orca is floating on a wide expanse of ocean (this ocean is ‘time’). Now, you need the boat to remain on, or very close to, a specific patch of ocean because that is where you expect to encounter a 3 ton great white shark (within 100 microseconds of UTC). Even on the calmest day, your boat will drift because there is nothing holding it in place. No matter how often you correct it and get it back to where it needs to be over time, it will drift and require further correction.

But what of the ‘time’ that you need to be in synchronisation with?  UTC is itself a derivation of International Atomic Time (TAI).  It too requires constant attention, with things like leap seconds being added to compensate for the earth’s rotation.   This is because the earth’s rotation is slowing down due to tidal deceleration, so anyone wishing they had more hours in the day will get their wish - in a few hundred million years. 

Back to the issue at hand and this is where a time service comes in.  You need to be able to generate a time source accurate enough to keep you within the agreed tolerances of UTC. However, that alone is not enough.  Once you have your accurate time source, you need maintain it day to day and make sure that it’s secure enough to prevent tampering, or that it’s sufficiently robust to withstand an attack while you deal with it. 

One of the problems you can come up against is spoofing, where some cheeky scamp spoofs your GPS signal and fools your clock into drifting out of sync.  This raises the key question of how will you know if you’ve been spoofed?  For that matter, how will you know if your clocks have drifted outside of tolerances for any reason, despite your best time sync efforts?  

So, you don’t just need a time source, you need a highly accurate, verified, reliable, robust and monitored time source and you need it soon. 

“You’re going to need a bigger boat.”

TO BE CONTINUED …