MYTH #4
There’s nothing to do about application-level error on a given
server. It is what it is, and regulators will just have to accept that.
Once again, this is not true. While it is certainly true that there will be situations where the only options are to upgrade the server hardware or to rely on network capture (a topic for a subsequent blog), a regulated firm that finds that a platform’s STAC-TS.ALE benchmark exceeds the firm’s application-level error budget may be able to bring the platform into compliance through one or more types of remediation.
Tuning is the least disruptive sort of remediation. To illustrate its potential effectiveness, I will now reveal that System B in Figure 3 is actually the same hardware and software environment as System A but highly tuned by someone who knows what he’s doing (in this case, Dom Pigott at Intelligent Compute). This tuning involves applying well-documented OS settings as well as pinning particular processes or threads to particular cores.
Another option is to change the software environment, such as upgrading the operating system. In the case of virtualized languages (Java, C#) or virtualized operating systems (VMware, Xen, etc.), upgrading other components in the software environment (virtual machines or hypervisors) may also help. (All the examples in this blog are of completely non-virtualized environments, but STAC-TS also handles virtualized environments, another topic that deserves its own blog.)
Still other remediation options involve modifying the application to use a different timestamping method.
However, none of these options is free. Manually tuning systems takes time from experts. And tuning all the systems that are subject to MiFID 2 time compliance—if they are not already being tuned—may require new kinds of cooperation between application teams and corporate IT. Upgrading software environments is also a costly process. And modifying applications may be the most expensive and most risky option, so it is not usually the first recourse for remediation.
Therefore, while it’s not true that application-level error is fixed for a given hardware platform, it may be expensive to get that error down to an acceptable level, particularly if the firm is dealing with many such platforms.
The other side of the equation
OK, so let’s say you tune and upgrade your platform and even update your applications, yet your application-level error (STAC-TS.ALE) is still outside your error budget. All may not be lost. There’s one more potential way to bring a platform into compliance with the rules: change the rules.
While this may sound like a Captain Kirk/Kobayashi Maru kind of ruse (like hacking into the ESMA website and changing the RTS document), that’s not at all what I mean. What I’m talking about is changing how you interpret the rules. The fact is that ambiguities in the regulations force you and your compliance team to decide how to interpret the rules and to guess how regulators will enforce them. That is, you are faced with a couple of mysteries (actually, more than two, but I’ll cover just two in this blog series).