MiFID II Article 50 and FINRA Rule 613: What Clock Synchronisation Actually Demands

What the regulations actually say

MiFID II is the European Union's framework for investment-firm regulation, in force since January 2018. Within MiFID II, Regulatory Technical Standard 25 (RTS 25) sets the requirements for clock synchronisation. It applies to investment firms operating trading venues, market makers and any participant whose order flow contributes to the audit trail. The core requirement is that all reportable events be timestamped to a common reference time, traceable to UTC, with bounded divergence.

The maximum divergence depends on the trading activity. For high-frequency trading — defined under MiFID II as trading characterised by sub-millisecond latency and message rates above defined thresholds — the divergence ceiling is 100 microseconds, with timestamp granularity of at least 1 microsecond. For other algorithmic trading and matching engine activity, the ceiling relaxes to 1 millisecond, with 1-millisecond granularity. Voice trading and other manual activities have a 1-second ceiling.

FINRA's Consolidated Audit Trail (CAT) under SEC Rule 613 is the US equivalent. It requires reporting industry members to synchronise their business clocks to within 50 milliseconds of NIST UTC for most order events. CAT-reportable events from HFT venues face the same 100-microsecond expectation as MiFID II in practice, even where the rule text is less specific. The traceability and audit-trail requirements are similar in spirit if not in exact wording.

What "traceable to UTC" actually means

The phrase "traceable to UTC" in both regulations is a precise technical concept, not a marketing term. It means the firm's local clock must be synchronised to a reference clock whose time is in turn synchronised to a national metrology institute (in practice, a stratum-1 GNSS receiver locked to GPS, Galileo, or both, with documented calibration). The chain of synchronisation must be continuous, documented and demonstrable.

This rules out a few patterns that occasionally show up in compliance discussions. NTP from the public internet is not adequate for traceability under MiFID II, even if the achieved accuracy nominally fits the budget — the public NTP infrastructure is not formally traceable, and the firm cannot produce documentation of the synchronisation chain on demand. Likewise, a corporate NTP server pulled from random pool servers is not adequate. The traceability chain has to terminate at a primary reference time clock (PRTC) on the firm's premises, normally a GNSS-disciplined hardware grandmaster.

From the PRTC, the synchronisation chain to the trading systems must be documented and bounded. PTP is essentially the only protocol that can deliver microsecond-class traceability to UTC across an enterprise network in a way the firm can actually evidence to a regulator. This is why every regulated trading venue runs PTP rather than NTP for HFT timestamping.

What a compliant timing fabric looks like

A compliant MiFID II timing fabric for an HFT venue has six load-bearing components. Get any one of them wrong and the audit defence becomes hard.

• ●A primary reference time clock (PRTC). A GNSS-disciplined hardware grandmaster on the venue's premises, with multi-band multi-constellation GNSS reception (L1+L5, GPS+Galileo at minimum), an OCXO or rubidium holdover oscillator, and IEEE 1588 PTP output. Ideally a redundant pair, configured for BMCA failover.
• ●A PTP distribution network. Boundary clocks across every layer between the PRTC and the trading systems, all configured for the same PTP profile (typically the IEEE 1588v2 default profile with hardware timestamping, or in some venues a vendor-specific profile). Every device on the path must be PTP-aware.
• ●Hardware-timestamping NICs in trading systems. Mellanox/NVIDIA ConnectX-6 or later, Intel E810, or equivalent. Software-only PTP on commodity NICs cannot consistently meet the 100-microsecond budget for HFT.
• ●Continuous observability. Every clock on the timing path streaming phase offset, clock class, GNSS health and BMCA election outcomes into a monitoring stack with alerts on excursions. Without this, the firm has no way to detect compliance breaches before the regulator does.
• ●Tamper-evident audit logs. Long-term storage of all timing-related metrics (typically 5+ years for MiFID II) with cryptographic integrity guarantees. The firm must be able to produce, on demand, evidence that any specific event was correctly timestamped against the PRTC.
• ●Failover and redundancy testing. Documented quarterly exercises that demonstrate the timing fabric continues to meet the synchronisation budget when individual components fail. "Fail open" is not an acceptable answer to a regulator.

Where compliance teams get caught out

We've supported enough MiFID II audits to recognise the patterns that get firms in trouble. None of them involve the protocol itself failing — the protocol works fine when it's deployed correctly. The failures are operational, and they share a common root: timing infrastructure being treated as install-and-forget rather than as a continuously monitored production service.

The most common pattern: a venue installs a hardware grandmaster, configures PTP across the network, achieves the required precision on day one, and never measures it again. Three years later, the GNSS antenna has been physically obstructed by a building extension, the BMCA priority on the backup grandmaster was misconfigured during a maintenance window, or the OCXO has aged enough that holdover no longer meets the budget. The firm doesn't notice until the regulator runs a spot check or until a market event puts a magnifying glass on the audit trail.

The second pattern: the firm depends on a single grandmaster with no documented failover testing. The first time the grandmaster is taken down for maintenance, the backup turns out to have a misconfiguration that nobody caught, the timing fabric drifts out of compliance for the duration of the maintenance window, and the firm is now in the position of explaining a several-hour MiFID II breach to a regulator.

The third pattern: the firm uses NTP for some components and PTP for others, on the assumption that NTP is "good enough" for the systems that don't directly handle HFT order flow. Then the audit trail ties an HFT timestamp to a downstream report that was timestamped via NTP, and the inconsistency between the two times (an NTP-derived event happening "before" a PTP-derived event with an earlier timestamp) becomes a regulator-reported anomaly.

The audit trail is what gets graded

When MiFID II or FINRA examiners arrive, the question they're trying to answer is not "is your clock accurate now?" — that's trivially demonstrable. The question is "can you prove your clock was accurate during the events under examination?" That requires the firm to produce, on demand, the historical record of phase offset, clock class, GNSS satellite count and BMCA state at the relevant moment, signed and tamper-evident, and to demonstrate the procedural controls that made the record trustworthy.

This is the part of compliance that hardware vendors don't sell. A grandmaster ships with a configuration interface and some current-state telemetry. The firm has to build, or buy, the operational layer that captures that telemetry continuously, stores it for the required retention period, signs it for tamper evidence, and exposes it to compliance staff in a form they can navigate. The TimeBeat Sync Insight platform is built specifically for this — it's the operational substrate that turns hardware grandmasters into a compliance-defensible timing fabric. Other vendors offer similar capability under different names. The point is that the operational layer is mandatory, not optional.

Where TimeBeat fits

TimeBeat builds open-standard PTP grandmasters (Open TimeCard, Open Time Appliance) and the operations platform (Sync Insight) that regulated trading venues use to meet MiFID II and FINRA timing requirements. Our customers include market makers, trading venues, prime brokers and clearing houses across European and US markets. We are obsessive about audit-defensibility because we have all spent careers in compliance discussions where "the clock was probably fine" is not an answer.

If you're approaching a MiFID II audit or trying to scope a compliant timing fabric for a new venue, the engineering team is happy to walk through architecture, observability and audit-trail patterns specific to your activity profile.