MiFID II Clock Synchronization: RTS 25, PTP, GPS and Audit Architecture (2026)

A regulator can ask you to prove when an order was received, and “our servers run NTP” is not an answer. MiFID II clock synchronization is a measurable engineering obligation: every reportable event must carry a timestamp that diverges from Coordinated Universal Time (UTC) by no more than a stated limit, and you must be able to show how that timestamp traces back to UTC. For the fastest participants the limit is 100 microseconds, which is about 20 kilometres of optical fibre.

There is also a 2026 twist that many articles still miss. The original RTS 25, Delegated Regulation (EU) 2017/574, was repealed with effect from 2 March 2026 and replaced by clock articles in Delegated Regulation (EU) 2025/1155. The headline tiers survived, but the granularity of the fastest tier tightened and new entities were added.

This post is an infrastructure analysis, not legal or investment advice. You will leave with the current tiers, a reference time-distribution architecture, a worked error budget, the failure modes that actually break compliance, and an evidence design that survives an audit.

What this covers: the legal baseline and what changed in 2026, the GNSS-to-PTP-to-NIC reference architecture, error budgeting and asymmetry, holdover and leap seconds, monitoring and audit evidence, and a comparison with US CAT rules.

Disclaimer: this article analyses technical architecture for educational purposes. It is not legal, compliance or investment advice. Confirm obligations with counsel and the competent authority.

Context and Background

Time matters in markets because three separate jobs depend on it: reconstructing who acted first, detecting abuse such as spoofing and layering, and testing best execution. A supervisor stitching together an order from a client, a broker, an algorithm and a venue needs timestamps from independent systems to agree. If they disagree by milliseconds, causality in a fast market becomes unreadable.

MiFID II (Directive 2014/65/EU) first imposed explicit clock rules through Article 50, with the numeric detail delegated to RTS 25. That regulation applied from 3 January 2018. In 2024 the MiFIR review moved the legal basis: Article 50 of MiFID II was deleted by Directive (EU) 2024/790, and the obligation now sits in Article 22c of MiFIR, inserted by Regulation (EU) 2024/791. ESMA’s interactive single rulebook records that Article 22c applies once the revised RTS 25 starts applying, and that the current RTS 25 applied until then. Article 22c widens the set of obliged entities to trading venues and their members, participants or users, systematic internalisers, designated publishing entities, approved publication arrangements (APAs) and consolidated tape providers (CTPs).

The revised rules were adopted by the Commission on 12 June 2025 as Delegated Regulation (EU) 2025/1155, a combined instrument covering consolidated tape input and output data, business clock synchronisation and revenue redistribution. Its Article 25 repeals Regulation 2017/574 and Article 26 states that Articles 11 to 16 apply from 2 March 2026. The engineering community still says “RTS 25” because the names stuck, and this article follows that habit while citing the new article numbers. For the legal text, use the EUR-Lex record of Delegated Regulation 2025/1155 and ESMA’s Article 22c page.

Two observations frame everything below. First, the rule regulates the clock that stamps the event, not the network that distributes time, so you have latitude in architecture as long as you can evidence the outcome. Second, the same timing problem appears in industrial systems: ordering events across distributed nodes without a shared clock is the subject of our post on hybrid logical clocks and vector clocks for event ordering. Finance simply attaches a legal penalty to the error bound.

A caveat on scope. The UK retained its own copy of 2017/574 after Brexit, and the FCA’s version is a separate legal instrument. Everything here about 2025/1155 applies to the EU regime, and UK firms should check the FCA handbook for their position.

The Reference Architecture for MiFID II Clock Synchronization

In one line: obtain UTC from satellites through redundant GNSS receivers, discipline a holdover-capable PTP grandmaster, distribute with hardware-timestamping boundary clocks, and apply timestamps in NICs or FPGAs at the point the regulation cares about. Then monitor every hop and archive the evidence.

Figure 1: Reference chain from UTC through GNSS, holdover, PTP and hardware timestamping to the audit store.

The diagram shows a single timing chain with one job per stage. UTC is realised by timing centres listed by the International Bureau of Weights and Measures (BIPM). Satellites broadcast a time scale steered to UTC, GNSS receivers recover it, a grandmaster clock distributes it by the Precision Time Protocol (PTP), and edge devices stamp events. Each stage adds error, and each stage needs its own monitoring.

The legal baseline: tiers, granularity and reference time

Article 11 of 2025/1155 requires that business clocks be synchronised with UTC from timing centres listed in the BIPM database; satellite-disseminated UTC is allowed if any offset is removed from the timestamp. That second clause matters: GPS time is not UTC. It runs on a continuous scale without leap seconds and currently sits 18 seconds ahead of UTC, so a raw GPS timestamp is non-compliant unless the offset is applied.

The accuracy tiers, as published in Annex IV of 2025/1155 (verified against the EUR-Lex text):

Entity and activity	Max divergence from UTC	Granularity
Venue or systematic internaliser, gateway-to-gateway latency above 1 ms	1 ms	1 ms or better
Venue or systematic internaliser, latency 1 ms or less	100 µs	0.1 µs or better
Member or participant using high-frequency algorithmic trading	100 µs	0.1 µs or better
Voice trading, human-intervention RFQ, negotiated transactions	1 s	1 s or better
DPEs, APAs and CTPs (Articles 14 and 15)	1 ms	1 ms or better

The 2017 text used 1 microsecond granularity for the 100 microsecond tier; the 2025 annex says “0,1 microseconds or better”. The 2017 Table 2 also contained an “any other trading activity” row at 1 ms; that row does not appear in the Annex IV text I retrieved, and I could not confirm how the new regime treats that residual activity, so check the official text for your case. Note also that the tier for a venue is chosen per trading system by its gateway-to-gateway latency, and that firms running several activities must meet each applicable level.

Granularity and accuracy are separate requirements. A system that records 0.1 microsecond resolution but is 300 microseconds off UTC fails the accuracy test while passing the granularity one. A frequent engineering mistake is to buy nanosecond-capable timestamping hardware and never measure absolute offset.

Traceability to UTC

Article 16 requires venue operators and their members, participants or users to establish a system of traceability to UTC, document the design, functioning and specifications of that system, identify the exact point where a timestamp is applied, and review compliance at least once a year. Traceability here is metrological in spirit: an unbroken chain of comparisons, each with a stated uncertainty, connecting your clock to a UTC realisation.

For a GNSS-based design, the chain is usually: UTC(k) at a national lab, to the satellite constellation’s system time, to your receiver, to your grandmaster, to each endpoint. The practical evidence is a document naming each link, its specified uncertainty, and logs showing the live offset between neighbouring links. Some firms add an independent terrestrial reference, such as a fibre-delivered time service, so that GNSS is not the only link. I label this a design choice rather than a requirement: the regulation does not mandate a particular source.

Where the timestamp is applied

Article 16 requires identifying the exact point at which the timestamp is applied. This is the most under-appreciated sentence in the regulation. A timestamp on a packet capture tap, a timestamp inside the application after a kernel hop, and a timestamp in the FPGA at the wire are different quantities. They can differ by tens of microseconds under load.

Pick the point that matches your reportable event, document it, and be consistent. For a venue it is typically the gateway ingress, the matching decision and the egress. For a participant it is the moment the order is created or sent. If a measurement point sits after a queue, then queueing delay becomes part of your timestamp error, which leads to the budgeting discussion below.

Why PTP and not NTP for the 100 microsecond tier

Network Time Protocol (NTP) typically achieves millisecond-class accuracy over a wide area network, and perhaps tens to hundreds of microseconds on a quiet local network with a good server. That is adequate for the 1 millisecond and 1 second tiers but marginal for 100 microseconds once software timestamping jitter is counted. PTP, defined in IEEE 1588, uses hardware timestamps taken at the network interface, plus switches that correct for their own residence time, and can reach sub-microsecond offsets on suitable hardware. For the fast tier, PTP with hardware timestamping is the practical choice; for lower tiers a well-run NTP service with documented measurements can be defensible.

How PTP, GNSS and Hardware Timestamping Fit Together

This section explains the mechanisms that decide whether you meet the limit, with worked numbers. The numbers in the budget tables are illustrative, chosen to show the method, not measured results from any product.

The PTP exchange and why asymmetry is the enemy

PTP computes offset using four timestamps. The grandmaster sends a Sync message at t1, the follower receives it at t2, the follower sends a Delay_Req at t3, and the grandmaster receives it at t4. If the path delay is the same in both directions, offset = ((t2 – t1) – (t4 – t3)) / 2 and mean path delay = ((t2 – t1) + (t4 – t3)) / 2.

Figure 2: The PTP timestamp exchange. Any difference between forward and return delay appears as clock offset error.

The weakness is the symmetry assumption. If forward delay exceeds return delay by D, the computed offset is wrong by D/2, and no amount of averaging removes it because the error is systematic. Light in optical fibre travels at roughly 5 nanoseconds per metre (refractive index about 1.47 gives about 4.9 ns/m). A 10 metre difference in the lengths of the transmit and receive fibres therefore creates about 50 ns of asymmetry and 25 ns of offset error. That is trivial against 100 microseconds.

The dangerous asymmetries are not cable lengths. They are queueing, store-and-forward switches that do not correct PTP, optical transceivers or media converters with different transmit and receive latencies, and wavelength-division multiplexing (WDM) links where the two directions use different wavelengths with different dispersion. A 10 microsecond asymmetry produces a 5 microsecond error, silently, and appears in no log unless you measure it with a calibrated reference. This is why the ITU-T telecom profile G.8275.1 mandates full on-path support, where every switch is a boundary or transparent clock, and why you should not run financial PTP through unmanaged hardware.

Boundary clocks, transparent clocks and profiles

A boundary clock terminates PTP on each port and regenerates it, so a chain of switches does not accumulate queueing noise. A transparent clock measures residence time of PTP packets through the switch and writes it into a correction field. Both approaches remove the dominant variable, switch queueing, provided the switch timestamps in hardware.

IEEE 1588-2019 introduced a High Accuracy default profile, which incorporates the ideas of White Rabbit, the CERN-originated extension that combines PTP with Synchronous Ethernet and phase measurement to reach sub-nanosecond accuracy over fibre. I mention White Rabbit because exchanges and some proprietary-trading shops use it or similar techniques for short, tightly controlled links. For compliance with a 100 microsecond limit you do not need sub-nanosecond accuracy, and chasing it increases cost and operational fragility. The benefit of the tighter technology is margin: it buys room in the budget for everything else.

Hardware timestamping NICs and the host clock

A PTP-capable network interface card records a timestamp in its own hardware clock (the PTP hardware clock, PHC) when a packet crosses the physical layer. On Linux, a daemon such as linuxptp disciplines the PHC from the network, and a second step synchronises the system clock (CLOCK_REALTIME) to the PHC. That second step is where many deployments lose accuracy.

If your application reads the system clock with a software call, it inherits the system clock’s servo error, interrupt jitter and the cost of the call itself. Better designs have the NIC stamp the packet on ingress and on egress, and have the application record the hardware timestamp (for example through SO_TIMESTAMPING) rather than reading the clock afterwards. For latency-critical gateways, some firms stamp in FPGA logic at the wire and carry the stamp with the message. Our discussion of low-latency market data feed handler design covers where in a pipeline those stamps are taken, and the exchange matching engine architecture post explains why venues care about the gateway-to-gateway latency that selects their tier.

One more property deserves attention: the tier threshold for a venue is its gateway-to-gateway latency. A venue that cuts latency below 1 millisecond moves from the 1 ms tier to the 100 microsecond tier. Faster matching therefore raises the compliance bar, and that coupling belongs in capacity planning.

A worked error budget

Suppose a participant using high-frequency algorithmic trading techniques must keep its order timestamps within 100 microseconds of UTC. The method is to allocate the limit across independent error sources, then keep a safety margin. All values below are illustrative.

Stage	Illustrative worst-case error
GNSS receiver to UTC, including antenna cable delay calibration	100 ns
Grandmaster oscillator and servo	50 ns
Two boundary-clock hops	200 ns
Residual path asymmetry after calibration	2 µs
NIC PHC to application timestamp point	1 µs
Host system clock servo, if used	10 µs
Sum, linear worst case	about 13.4 µs

Even with generous host-clock error, the linear sum is a small fraction of 100 microseconds. The point is where the margin goes: the budget is dominated by the host and by unmeasured asymmetry, not by the satellite. A firm that finds only 3 microseconds of margin after a test usually has an unmodelled item, such as a virtual machine clock, a time-stamping point after a queue, or a failover event.

Because the limit is on divergence from UTC and not on a statistical average, the budget should be built for worst case during a defined set of events: grandmaster failover, GNSS loss, link flap and load peaks. Averages in a quiet period prove little.

Holdover: what happens when GNSS disappears

Holdover is the period during which a grandmaster keeps time after losing its reference. The drift depends on the oscillator and its temperature stability. As an illustration with assumed numbers, a frequency error of 1 part in 10^9 (1 ppb) accumulates 1 microsecond per 1,000 seconds, or 3.6 microseconds per hour. A cheaper oscillator at 1 ppm drifts 1 microsecond every second and exhausts a 100 microsecond budget in 100 seconds. A temperature-compensated crystal (TCXO), an oven-controlled crystal (OCXO) and a rubidium reference sit at progressively better stability classes, but the real figures depend on the model, ageing and temperature, so read the datasheet and test on your own rack.

The design consequence is that holdover duration times drift rate must stay below the unused budget. If you plan for a four-hour GNSS outage and have 80 microseconds of spare budget, you need a drift rate under 80 µs / 14,400 s, about 5.6 ppb. Anything worse needs a second reference such as a fibre-delivered time feed or a second site.

Leap seconds and the future of UTC

UTC is a time scale with occasional leap seconds so that it tracks Earth rotation. Leap seconds are a hazard for software, because a day can have 86,401 seconds and many systems mishandle the repeated or smeared second. For clock compliance the rule is unambiguous: your timestamps must be UTC, not a smeared approximation, so smearing can create divergence of up to half a second in some schemes, far outside any tier below 1 second. The last leap second was inserted at the end of 2016. In 2022 the General Conference on Weights and Measures decided, in its Resolution 4, to increase the maximum allowed UT1-UTC difference “in, or before, 2035”, and asked for a plan, with a draft due at the 28th CGPM in 2026. Until the plan lands, treat leap-second handling as a test case and rehearse it.

Resilience, Monitoring and Audit Evidence

Meeting the tier on a good day is the easy part. The regulation requires traceability, documentation and an annual review, and an auditor will ask what happens when the reference is wrong. This section covers the failure paths and the evidence design.

Failure mode one: GNSS jamming and spoofing

GNSS signals arrive at the antenna at extremely low power, so jamming with cheap devices is feasible, and spoofing, where a counterfeit signal steers the receiver to a false time, is documented in research and in operational incident reports in several regions. Jamming is loud: the receiver loses lock and alarms. Spoofing is quiet: the receiver reports a healthy lock with a wrong time.

The defence is not a single product but a comparison. A receiver that tracks multiple constellations (GPS, Galileo and others) with a multi-frequency front end is harder to deceive with a single simulator. Beyond that, an independent source is what exposes a coherent spoof: a second receiver on a separate antenna at another location, a fibre-delivered time feed, or an atomic reference that cannot be steered quickly. The comparator rejects a source that moves away from the others faster than any oscillator physically could.

Figure 3: Two GNSS references and a terrestrial source feed a comparator. Disagreement raises an alarm and moves the grandmaster into holdover with a running drift budget.

Figure 3 encodes the policy that matters operationally. When sources agree, the grandmaster serves PTP. When they disagree, you do not guess which is right; you alarm, flag the period in logs, and ride the holdover oscillator while a drift budget timer runs. When the budget is spent, events are marked as out of tolerance. That last step is an honest record rather than a silent breach, and it is far easier to explain to a supervisor than an unflagged error.

Failure mode two: asymmetry that nobody measured

As discussed, PTP cannot see asymmetry. Common triggers include a switch firmware upgrade that changes cut-through behaviour, a new optical module with a different latency, a patch through a wavelength-multiplexed circuit, or rerouting of a metro link after a carrier maintenance event. The symptom is a step change in the offset between two sites, with no alarm on either grandmaster.

The control is calibration plus cross-checks. Calibrate every link once with a reference instrument, store the asymmetry correction in the PTP configuration, and compare timestamps against an independent path such as a pulse-per-second (PPS) signal on a sample of hosts. A drifting PPS-versus-PTP delta is an early warning that something changed in the network.

Failure mode three: grandmaster failover and the best master clock algorithm

PTP elects its source using the best master clock algorithm (BMCA), comparing clock class, accuracy and priority fields. During a failover, followers may step or slew, and for a while the offset can be bad. A follower that steps its clock backwards produces timestamps that go back in time, which breaks sequence assumptions in applications and in audit queries.

Design rules: forbid backward steps in production by slewing only after the initial synchronisation, define explicit clock class values for holdover so downstream devices know the source degraded, and test failover under load. Check the application’s behaviour when the clock offset jumps, because a trading system that panics on a negative interval is a separate incident waiting to happen.

Failure mode four: virtual machines, containers and cloud

The tier applies to the clock used to record the reportable event, wherever it runs. A virtual machine’s clock is derived from the hypervisor, and its accuracy depends on the clock source and the virtualisation layer. Some cloud providers publish time services with stated accuracy and PTP hardware clocks on certain instance types, but you must read the provider’s specification for the instance you use and then measure it. I make no general claim about cloud accuracy here, because it varies by provider, region and instance type.

Monitoring architecture

Monitoring has two layers. The control layer measures how well each clock tracks its parent: offset, mean path delay, servo state, grandmaster class and the source of each GNSS lock. The evidence layer measures what matters for the regulation: how far each timestamp point is from UTC, measured independently of the system being measured.

Figure 4: Probe, telemetry and event timestamps feed a metrics store and a write-once evidence archive, which support alerting, incident records and the annual review.

Independence is the key design principle. If the monitoring reads the same system clock it is trying to verify, it will agree with the clock even when the clock is wrong. Use a separate reference, such as a monitoring probe with its own GNSS receiver or a PPS input, so the measurement is not circular.

A practical probe records, for each monitored host, the offset to a reference every second, the PTP servo state and the identity of the active grandmaster. An alert rule compares the offset to a fraction of the tier limit, for example paging at 50% of the allowed divergence to leave time to react. That 50% figure is a suggestion for illustration, not a regulatory number.

What evidence to keep

The regulation asks you to document the system, identify the timestamp point, review annually and keep traceability. It does not give a retention period for clock logs in the text I read. Many firms align clock-evidence retention with the transaction-record retention they already carry under MiFID II record-keeping, but that is an interpretation to confirm with compliance, not something the clock article states.

A defensible evidence set contains: a design document with a diagram of the chain, a list of timestamp points, calibration certificates and asymmetry corrections, configuration snapshots of grandmasters and switches, time-series offsets for each endpoint, incident records for every out-of-tolerance period with cause and fix, and the annual review report with sign-off. Store it with immutability, for example object-lock storage, so that the record cannot be quietly edited after the fact.

Comparison with US CAT rules

The US Consolidated Audit Trail has a much looser clock rule. FINRA Rule 6820 requires most business clocks to be synchronised within 50 milliseconds of the NIST atomic clock time, and clocks used solely for manual order events or allocation times to be within one second. The tolerance covers the offset, the transmission delay from the time source and clock drift. Firms must synchronise before market open each business day, check against NIST during the day, keep a log of synchronisation times and results for at least five years, certify periodically and report violations. The FINRA page I read shows the rule effective 15 March 2017 with no later amendments listed; confirm the current text, because CAT rules have been the subject of exemptive relief and proposals.

Aspect	EU 2025/1155	US CAT, FINRA 6820
Fastest tier	100 µs from UTC, 0.1 µs granularity	50 ms from NIST
Reference	UTC via BIPM timing centres	NIST atomic clock time
Distribution that fits	PTP with hardware timestamps	NTP is generally enough
Evidence	Traceability system, documented design, annual review	Sync log, five-year retention, certification

The contrast is roughly 500 to 1 on the fastest tier (50 ms versus 100 µs). A firm that already meets EU HFT requirements will satisfy CAT’s tolerance by a wide margin, but the reverse is false. Global firms usually design for the strictest regime and document against each.

Trade-offs, Gotchas, and What Goes Wrong

Every design here trades money, complexity and risk. The right question is how much margin you need and how you will prove it.

Over-engineering versus margin. A White Rabbit-class network gives nanosecond-level accuracy, and it costs more in hardware, fibre and operations. If your tier is 100 microseconds and your budget lands at 15 microseconds, you have a large margin and extra precision buys little. Spend instead on independence of references and on monitoring, which prevents the failures that actually produce findings.

Single-vendor monitoring. If the same vendor supplies the grandmaster and the monitor, a shared bug or shared assumption can make both agree on a wrong answer. Diversity in the measurement chain is cheap insurance.

Confusing synchronisation with latency measurement. Clock synchronisation tells you whether a timestamp is right in absolute terms. One-way latency between two systems requires both ends to be correctly synchronised, and its uncertainty is the sum of both clocks’ errors. Using unsynchronised timestamps to claim sub-microsecond latency is a common error.

Applying the wrong tier. Firms sometimes apply the 1 millisecond tier to a system that qualifies for the high-frequency tier, or fail to notice that a venue’s latency improvement moved it across the 1 millisecond boundary. Revisit the classification whenever the architecture changes, and write down the reasoning.

Software upgrades and drift. Kernel updates, NIC driver changes and switch firmware have each altered timestamping behaviour in production deployments. Regression-test timing as part of every release, using a reference instrument.

Annual review treated as paperwork. The review requirement exists because networks change. A review that only re-signs last year’s document misses a new site, a new carrier link or a changed timestamp point.

Compliance is not the same as accuracy. Meeting a legal threshold is a floor. Surveillance quality, internal reconciliation and post-trade forensics benefit from tighter clocks than the law requires, so the business case for better time often comes from operations rather than from regulation.

Unverified claims. Be sceptical of vendor numbers that omit conditions: temperature range, number of hops, load, and whether the figure is accuracy to UTC or merely precision between two devices of the same brand. The two are very different quantities.

Practical Recommendations

Start by establishing which tier applies to each system and activity, and write the reasoning down. For venues this means measuring gateway-to-gateway latency per trading system; for participants it means determining whether the activity uses high-frequency algorithmic trading techniques. Then fix the timestamp point for each reportable event and record it in the design document.

Next, build the reference chain with redundancy at the source: at least two independently located GNSS receivers or one GNSS plus an independent terrestrial reference, a holdover oscillator sized to your drift budget, and a documented offset from GPS time to UTC. Distribute with PTP using hardware timestamping and boundary or transparent clocks on every hop, and calibrate asymmetry on each link. Prefer NIC or FPGA timestamps over software clock reads.

Finally, measure independently and keep evidence. Probes with their own reference should record offset continuously, alerts should fire well before the limit, and every out-of-tolerance period should have an incident record. Run a yearly review that actually tests failover, GNSS loss and a leap-second rehearsal.

A short checklist:

Classify each system against Annex IV and document why.
Define and document the exact timestamp point for each reportable event.
Use at least two independent time references with a comparator.
Size holdover so drift times outage duration stays under spare budget.
Use hardware-timestamping PTP with boundary or transparent clocks, and calibrate asymmetry.
Prohibit backward clock steps in production.
Monitor with an independent reference, alert at a fraction of the limit.
Keep immutable evidence and run a real annual review.
Confirm legal interpretation, including the residual activity row and retention, with counsel.

Frequently Asked Questions

What is MiFID II clock synchronization?

It is the requirement that trading venues, their members and participants, systematic internalisers and certain publication entities keep the business clocks used for reportable events synchronised to UTC within set limits. The detailed accuracy levels sit in the regulatory technical standard, and since 2 March 2026 they are in Delegated Regulation (EU) 2025/1155 under MiFIR Article 22c. You must also show traceability to UTC and review compliance annually.

What is the RTS 25 accuracy requirement for high-frequency trading?

For firms using high-frequency algorithmic trading techniques, business clocks must not diverge from UTC by more than 100 microseconds. The published Annex IV granularity is 0.1 microseconds or better, tighter than the 1 microsecond in the original 2017/574. Venues and systematic internalisers with gateway-to-gateway latency of 1 millisecond or less face the same 100 microsecond limit. Other tiers allow 1 millisecond or 1 second.

Is RTS 25 still in force in 2026?

Not in its original form. Delegated Regulation (EU) 2017/574 was repealed with effect from 2 March 2026, and Articles 11 to 16 of Delegated Regulation (EU) 2025/1155 now apply. The headline divergence values carried over, so many engineering requirements look familiar, but the article numbers, scope and fastest-tier granularity changed. The UK retained its own version, which is governed separately.

Do I need PTP for MiFID II, or is NTP enough?

The regulation does not mandate a protocol; it mandates an accuracy outcome and traceability. For the 100 microsecond tier, hardware-timestamped PTP is the practical route because software timestamping jitter and network variation consume the budget. For the 1 millisecond and 1 second tiers, a well-managed NTP service with documented measurements may be sufficient, provided you can evidence the accuracy.

Can I use GPS time directly for trade timestamps?

Not without correction. GPS time is a continuous scale that does not include leap seconds and is currently 18 seconds ahead of UTC. The regulation allows satellite-disseminated UTC if any offset is removed from the timestamp, so your chain must apply the GPS-to-UTC offset reliably, including at leap-second events, and document it as part of traceability.

How does MiFID II timestamping differ from US CAT?

CAT’s FINRA Rule 6820 requires most clocks to be within 50 milliseconds of NIST time and manual or allocation clocks within one second, with daily synchronisation and logs kept for at least five years. The EU fastest tier is 100 microseconds from UTC with annual review and a traceability system. Designing to the EU tier generally satisfies CAT’s tolerance, but not the reverse.

MiFID II RTS 25 Clock Synchronization: Trade Timestamping, PTP, GPS and Audit Architecture (2026)