MYTH #3
Application-level error is so significant that no application-
timestamping solutions can meet MiFID 2 requirements.
Fortunately this isn’t true either. Consider the system in Figure 3, below. With a max of 21.3 microseconds, timestamps from this platform will comply with even the most stringent MiFID 2 requirement (100 usecs) as long as the host clock never gets more than 78 microseconds away from UTC (which requires analysis of the time sync chain down to the host clock—again, a subject for another blog).
Timestamp Errors with Respect to Host Clock (STAC-TS.ALE1)
Worst Case Error Percentiles (microseconds)
System B
Figure 3
If all of a firm’s systems that are subject to RTS 25 are like System B, then the firm may not have much trouble complying with the regulations. (Though it will still need to demonstrate to regulators that the systems are like System B, for which purpose it may want to use a standard like STAC-TS.)
But a lot of larger firms tell us they believe the event reporting and timestamping requirements of MiFID 2 apply to many systems with application-level error closer to that of System A than System B. (Exactly which systems are in scope depends on high-level MiFID 2 interpretation questions. A mystery I won’t try to cover in this blog.) What is such a firm to do? Obviously, upgrading hardware is one option. But if the need is widespread, the hardware bill could be large. This fact can lead to despondency if combined with another myth….
<Next: MYTH #4 - There’s nothing to do about application-level error on a given server.>
<Prev: MYTH #2 - Application-level error isn’t significant enough to matter.>