MiFID II compliance

The rest of the Compliance documentation covers the details and tools involved in generating compliance reports. However, it may be helpful to demonstrate directly how to make Compliance provide MiFID II reporting for your hosts.

Assume there are a set of hosts subject to the 100 microsecond reporting threshold. For simplicity, let’s assume those hosts all have ‘accuratehost’ in their name - although it could be any set of host names or IP addresses. Hosts may be scattered through the enterprise and need to be separately listed - that would be fine also.

Similarly, there’s another group of hosts subject to the 1 millisecond threshold, all on the 10.50.3.x and 10.51.82.x subnets. To generate compliance reports on both of these sets of machines automatically, your Compliance configuration section in /etc/timekeeper.conf would look like this (configured directly or via the web GUI):

COMPLIANCEREPORT0() { TITLE='100us hosts'; CLIENTSET='*accuratehost*'; ALERTTHRESHOLD=0.0001; }
COMPLIANCEREPORT1() { TITLE='1ms hosts'; CLIENTSET='10.50.3.*,10.51.82.*'; ALERTTHRESHOLD=0.001; }

That’s all that’s needed. As your Compliance instance collects management data from these hosts it will analyze and build reports on each group separately. New reports will be generated daily, viewable via the web interface interactively, and via PDF files retrievable via the web or on disk. These daily summaries are also collected up into weekly, monthly and yearly reports, all viewable the same way at the same location.

If desired, WARNINGTHRESHOLD values can also be applied so that you get warnings about hosts that are marginal before they exceed the alert threshold. You can do this in the same report above, or create a separate ‘internal’ report that includes the warning threshold for simpler external reporting.

FINRA CAT compliance

TimeKeeper’s multisource feature, the license-controlled ability to use more than one source among other things, allows easy compliance with FINRA CAT NMS Plan requirements. In general for Compliance configuration, the MiFID II and Compliance guidelines apply similarly to systems bound to FINRA CAT thresholds.

Accuracy to within 50 milliseconds of NIST time is required - but it’s unlikely that a public NIST server is being used to drive the clock. By pointing to a NIST server as a secondary source, accurate logs can be maintained that provide continuous system time offsets from NIST time.

To configure for this scenario, the TimeKeeper configuration should specify a NIST server as a secondary (or even lower priority) time source, as in:

SOURCE0() { PTPCLIENTVERSION=2; PTPDOMAIN=80; }
...
SOURCE10() { NTPSERVER=time-a.nist.gov; NTPSYNCRATE=0.1; }

In this case, the primary source is a local PTP Grandmaster on domain 80. The NIST server time-a.nist.gov is a non-primary source that will be tracked and logged in timekeeper_10.data in /var/log by default. Additional servers can be specified in order to maintain a tracked offset if source 0 goes offline.

/var/log/timekeeper_10.data will look approximately like this:

1486063703.142371588 -0.000033029 0.000013451 ...
1486063709.244078475 -0.000027511 -0.000001339 ...
1486063726.824376694 -0.000022426 0.000111881 ...
1486063738.072544688 -0.000009811 0.000101470 ...

As described in the “File formats” section, the first column is the time reported by the time source (time-a.nist.gov in this case). The second column is the local time offset from that sample. These public NTP servers are subject to variations in round trip time across the public internet, so they will not report a sync as clean as high quality local time sources like we configured for source 0 (/var/log/timekeeper_0.data). TimeKeeper applies the same smoothing algorithms it would to any time source, though.

TimeKeeper constantly steers the clock based on the primary source at every sample, so there is no need to explicitly synchronize the servers by hand at predetermined intervals.

When using the multisource feature, TimeKeeper will fall back to other sources (1-9) in the above configuration if the primary PTP grandmaster ceases to provide PTP data. This means there is an automatic fallback in place, even for a different protocol. If all of the other sources fail TimeKeeper will steer to the NIST source, although in general given the long links and noisy network involved the accuracy would be greatly reduced compared to an accurate local failover source.

/var/log/timekeeper_10.data files maintain a complete history of the local clock offset from NIST time and should be retained with other audit trail data. When referencing a public NTP server, please comply with that server’s usage guidelines.