MSSA and Traceability in Clock Sync: Are You Really Compliant?

MSSA in plain English

Maximum System Synchronisation Accuracy is the worst-case time error between any timestamp the firm produces and UTC. MiFID II RTS 25 caps this at 100 microseconds for high-frequency trading and 1 millisecond for other algorithmic trading. The cap applies to the worst case, not the average — a system that's correctly synchronised 99.9% of the time but drifts to 500 microseconds during the other 0.1% is not compliant under any reading of the regulation.

This is the part that most firms underestimate. Achieving the precision under nominal conditions is straightforward; demonstrating that the precision is held under credible disruption (GNSS denial, hardware failure, network reconfiguration, oscillator ageing) is harder. The firm has to be able to show that the worst case across the reporting period stayed within the cap, not just that the typical case did.

Traceability in plain English

Traceability means the firm can document the chain of synchronisation from its local clock back to a national metrology institute (BIPM, NIST, NPL, PTB or equivalent), with no unverifiable links. Public NTP doesn't qualify because the public pool servers are run by anonymous volunteers and the firm can't document what the upstream clocks are doing. Corporate NTP servers pulled from public pools have the same problem one layer down.

PTP from a hardware grandmaster locked to a GNSS reference does qualify, because the chain is concrete: GNSS satellites (operated by national bodies and traceable through international agreements), GNSS-disciplined grandmaster (locally operated, configuration-documented), PTP distribution chain (every device PTP-aware and documented), local slave (hardware-timestamped). Each link is verifiable by the firm and demonstrable to a regulator.

Where firms get caught out

Three patterns recur. First, the firm achieves typical-case precision but doesn't measure worst-case. When the regulator asks about a specific historical period, the firm produces average metrics rather than worst-case metrics, and the conversation gets uncomfortable when the regulator notices.

Second, the firm uses NTP because "the precision is fine" without confirming traceability. The precision genuinely is fine for the relevant budget, but the synchronisation chain isn't documented and can't be verified by a regulator. This is a documentation gap, not a precision gap, and it's harder to fix retroactively than to prevent.

Third, the firm depends on a single grandmaster with no documented failover testing. The next failover surfaces a configuration drift nobody caught, and the firm spends hours or days outside the precision cap before anyone notices. The regulator views this as a worst-case violation regardless of how brief the excursion was.

How to close the gaps

Three actions. Capture worst-case metrics continuously, not just averages. Phase offset to UTC measured at every PTP slave, retained for the regulatory retention period in queryable form. Document the synchronisation chain explicitly: a single document that shows the chain from each reportable system back to the primary reference time clock and from the PRTC back to UTC, updated whenever the architecture changes. Test grandmaster failover quarterly in production and capture the results in the audit trail.

None of these are technically difficult. The challenge is doing them consistently across a deployment that's already running, where the original team has moved on, and where the timing fabric was specified once and never re-evaluated. The TimeBeat Sync Insight platform exists specifically to make this operational discipline easier to maintain over time.