MiFID II Clock Synchronization
RTS 25 Business Clock Accuracy

1. Scope: who RTS 25 binds, and to which table

"RTS 25" is Commission Delegated Regulation (EU) 2017/574, the regulatory technical standard on the level of accuracy of business clocks. It supplements Directive 2014/65/EU (MiFID II), whose Article 50 requires that the business clocks used to record the date and time of reportable events be synchronized.

It binds two distinct populations, each governed by a different table of the Annex:

• Operators of trading venues — regulated markets, MTFs and OTFs. Their tier (Annex, Table 1) is set by the gateway-to-gateway latency of each trading system.
• Members or participants of a trading venue — the investment firms trading on those venues. Their tier (Annex, Table 2) is set by the type of trading activity.

2. The core obligation — traceable to UTC, within tier

The obligation has two measurable dimensions, set per applicable tier:

1. Maximum divergence from UTC — how far the business clock may drift from Coordinated Universal Time at the instant a timestamp is applied.
2. Granularity of the timestamp — the smallest time unit the recorded timestamp must resolve (1 second, 1 millisecond, or 1 microsecond).

Both are anchored to UTC, and the reference is specified in Article 1:

Two consequences follow directly. First, a free-running clock — however stable — is non-compliant: the requirement is divergence from UTC, an external reference, not internal stability. Second, if you derive time from GNSS, the GNSS-to-UTC offset must be documented and removed, not assumed to be zero.

3. The two tiered accuracy tables

These two tables, from the Annex of Reg. (EU) 2017/574, are the heart of the standard. Find your row, and you have your divergence budget and granularity.

Table 1 — Operators of trading venues (criterion: gateway-to-gateway latency)

"Gateway-to-gateway latency" is the time a venue's matching system takes from receiving a message at one gateway to transmitting at another. A sub-millisecond matching engine pulls the venue into the 100 µs tier.

Table 2 — Members or participants (criterion: type of trading activity)

4. Traceability to UTC and the annual review

Hitting the number is not enough; you must be able to prove it on demand. Article 4 makes traceability and documentation a standing obligation:

In practice, "traceability to UTC" means an unbroken, documented chain from your business clock back to a recognised realisation of UTC — a UTC(k) maintained by a national metrology institute, for example UTC(OP) at LNE-SYRTE, Observatoire de Paris, or UTC(PTB), UTC(NPL), UTC(NIST) — or to GNSS-disseminated UTC with the offset documented and removed. The chain, the timestamp-application point, and the measured divergence must all be written down, and the whole thing re-reviewed at least annually.

5. A compliant reference topology

The architecture that maps cleanly onto Article 4 is a supervised GNSS-disciplined Stratum 1 layer, a documented distribution layer, and a recorded accuracy budget end to end:

        ┌───────────────────────────────────────────────┐
        │  Reference: UTC realisation                    │
        │  ─────────────────────────────────────────────  │
        │  GNSS (multi-constellation) + PPS              │
        │  offset-to-UTC documented & removed            │
        │  cross-check vs UTC(k) national lab            │
        └─────────────────┬─────────────────────────────┘
                          │  PPS-disciplined, supervised
                          ▼
        ┌───────────────────────────────────────────────┐
        │  Stratum 1 time servers (redundant, peered)    │
        │  ─────────────────────────────────────────────  │
        │  hardware timestamping for the 100 µs tier     │
        │  NTS for authenticated software distribution   │
        └─────────────────┬─────────────────────────────┘
                          │  per-tier distribution
                          ▼
        ┌───────────────────────────────────────────────┐
        │  Timestamping points (the recorded clock)      │
        │  ─────────────────────────────────────────────  │
        │  Matching engine / OMS / gateway / capture     │
        │  divergence measured & logged continuously     │
        └───────────────────────────────────────────────┘

This is exactly the kind of supervised Stratum 1 infrastructure RDEM Systems operates and documents — a GNSS-disciplined, PPS-supervised reference with a recorded accuracy budget. The reference design and the server role are described on the hub: the RDEM time infrastructure and the Stratum 1 server reference. For the authenticated distribution layer, see NTS (RFC 8915).

6. Which protocol for which tier (NTP, NTS, PTP, GNSS)

RTS 25 names no protocol. It is deliberately technology-neutral — it sets an outcome (divergence + granularity) and demands proof. The engineering question is simply which distribution method can demonstrably hold your tier:

7. Evidence pack for the regulator

Assemble and keep current — Article 4 makes this a living file, reviewed at least annually:

1. System design document. The full traceability chain from business clock back to a UTC realisation, with the timestamp-application point identified.
2. Tier determination. For each system/activity, the applicable Table 1 or Table 2 row and the rationale (measured gateway-to-gateway latency, or the trading-activity classification).
3. Reference proof. The UTC source in use (UTC(k) lab or GNSS), and — for GNSS — documentation that the offset to UTC is accounted for and removed.
4. Divergence measurement. Continuous or sampled records showing measured divergence stays within tier, with the methodology.
5. Granularity proof. Evidence that recorded timestamps resolve to the required unit (1 s / 1 ms / 1 µs).
6. Annual review. Dated record of the at-least-annual compliance review and any corrective actions.
7. Source validation. Output of the Online NTP Validator against each external source — stratum, offset, refID, dual-stack reach — captured for the file.

8. RTS 25 vs RTS 22 / RTS 24 — don't confuse them

Three MiFID II / MiFIR technical standards touch "time", and regulators expect you to keep them distinct:

RTS 25 is the foundation the other two stand on: RTS 22 and RTS 24 prescribe what timestamp to record and where to send it, but the timestamp is only as good as the clock that produced it. For the supervisory interpretation of the borderline cases, the ESMA Q&A on MiFID II and MiFIR market-structures topics is the reference. To position RTS 25 alongside ISO 27001, NIS 2, PCI-DSS and DORA in one place, use the NTP audit checklist; for the financial-sector resilience angle, see the companion DORA time-synchronization guide.

Different angle? Use the right tool:

• Measure jitter, offset, latency → ntp-tester.eu
• Diagnose firewall / port 123 / daemon → check-ntp.net
• Enterprise reference architecture → ntp.rdem-systems.com