MiFID II Clock Synchronization
RTS 25 Business Clock Accuracy

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

"RTS 25" was Commission Delegated Regulation (EU) 2017/574, the regulatory technical standard on the level of accuracy of business clocks, adopted under Article 50 of Directive 2014/65/EU (MiFID II). Since 2 March 2026 the same requirements live in Chapter III of Commission Delegated Regulation (EU) 2025/1155, which supplements Article 22c of MiFIR (Regulation (EU) No 600/2014).

It binds distinct populations, each governed by its own rule:

• Operators of trading venues — regulated markets, MTFs and OTFs — and, since 2025/1155, systematic internalisers. Their tier (Annex IV, Table 1) is set by the gateway-to-gateway latency of each trading system.
• Members, participants or users of a trading venue — the investment firms trading on those venues. Their tier (Annex IV, Table 2) is set by the type of trading activity.
• DPEs, APAs and CTPs — new with 2025/1155: 1 millisecond maximum divergence, 1 millisecond granularity (Articles 14 and 15).

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 0.1 microsecond since 2025/1155).

Both are anchored to UTC, and the reference is specified in Article 11 of 2025/1155 (formerly Article 1 of 2017/574):

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 Annex IV of Reg. (EU) 2025/1155 (formerly the Annex of 2017/574), are the heart of the standard. Find your row, and you have your divergence budget and granularity. Struck-through values are those of the repealed text.

Table 1 — Operators of trading venues and systematic internalisers (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, participants or users (criterion: type of trading activity)

Articles 14 and 15 — DPEs, APAs and CTPs (new with 2025/1155)

A DPE that has also acquired the status of systematic internaliser follows Article 12 instead (Table 1).

4. Traceability to UTC and the annual review

Hitting the number is not enough; you must be able to prove it on demand. Article 16 of 2025/1155 (formerly Article 4 of 2017/574) 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 16 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     │
        └───────────────────────────────────────────────┘

RTS 25 does not name a stratum: it sets a maximum divergence from UTC and asks for traceability. In practice, the 100 µs and 1 ms tiers call for a local reference (GNSS or PTP), because no public NTP service reached over the Internet proves that divergence; the 1 s tier does not. RDEM Systems operates a GNSS/PPS-disciplined stratum 1 of this kind. 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).

When the Article 16 evidence pack is the deliverable rather than a DIY task, RDEM Systems operates the synchronization and produces the documented traceability chain to UTC as a managed service — the UTC time traceability audit (fixed-fee dossier or managed annual review).

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 16 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 / 0.1 µs; 1 µs under the repealed 2017/574).
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 with its uncertainty, dual-stack reach, NTS verdict — 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