Clock synchronisation is a control, not a timestamp setting

At 09:31, two brokers detect that a trading server's clock differs from its reference. One pauses order entry when the measured offset crosses 100 microseconds. The other keeps trading because its NTP client still reports synchronised. Both have made a decision about risk, but only one has tied that decision to a measured tolerance and an operational response.

The disagreement is not just about clock accuracy. A trade record can carry several times: when a packet reached a network card, when an application processed it, when an order entered a gateway and when an execution was confirmed.

Compliance teams may later compare those records with venue data, surveillance alerts and client communications. If the clocks are misaligned, or the timestamps describe different events, the resulting chronology can be unreliable.

Clock error becomes a control problem

Clock synchronisation supports order reconstruction, market-abuse surveillance and evidence that a firm followed its controls. It also helps engineers distinguish a genuine latency change from a timing artefact. A timestamp that is 500 microseconds ahead of another system can make a response appear to precede the event that caused it.

There are two separate questions: how close is a machine's clock to UTC, and what event does its timestamp represent? A host can be well synchronised while an application stamps an event after a queue delay. Conversely, a NIC hardware timestamp can capture packet arrival accurately while the host clock used to interpret it is offset. Timestamp precision, such as nanoseconds displayed in a log, does not prove timestamp accuracy.

For firms within scope, EU MiFID II RTS 25 sets maximum divergence from UTC and timestamp granularity requirements. The applicable limits depend on the activity and status of the trading venue or member or participant.

The commonly cited limits include 100 microseconds of divergence and 1 microsecond granularity for relevant high-frequency trading systems, and 1 millisecond for other covered systems. Scope and implementation should be checked against the firm's regulatory obligations, not inferred from a vendor's default setting.

Compliance evidence needs to show more than a green synchronisation indicator. It should establish the time source, measured offset, timestamping point, applicable tolerance and action taken when the tolerance is breached.

Choose a clock path that fits the tolerance

NTP is operationally simple and can be sufficient where millisecond-level accuracy meets the requirement. PTP, defined by IEEE 1588, can support tighter timing when deployed with compatible network equipment and hardware timestamping.

Neither protocol guarantees a result on its own. Network asymmetry, virtualisation, queueing, source failure and poor configuration can all affect the measurement.

The figures below are typical market ranges, not guaranteed performance. Actual results depend on topology, hardware, load and measurement method.

A PTP deployment often uses a GNSS-disciplined grandmaster, boundary clocks in switches and NIC hardware timestamping. That can reduce error, but it adds dependencies. GNSS reception can fail, a grandmaster can enter holdover, and a misconfigured switch can disrupt distribution. Build independent references where justified, and alert on loss of source, offset, frequency error and holdover state. A second source is useful only if failover behaviour is understood and tested.

• Use UTC as the common reference, and document any local time conversion at system boundaries.
• Use a monotonic clock for elapsed-time measurements. Do not calculate durations by subtracting wall-clock timestamps that can step or slew.
• Record whether a timestamp comes from the NIC, kernel, gateway or application, and whether it marks receive, processing, send or acknowledgement.
• Check leap-second and leap-smear policy across connected systems. Different policies can create a temporary offset even when each system reports healthy synchronisation.

Teams reviewing broker and prop-firm infrastructure often treat clock distribution as part of the same control design as market-data and order-gateway observability. Trading Technology's infrastructure coverage provides further context on those operational dependencies.

Reconcile events before sorting them

Do not reconstruct an order lifecycle by sorting every log line by its displayed timestamp. First classify the event and the clock that produced it. A venue's matching-engine time, a broker's gateway receive time and a strategy's decision time are different observations. They may be comparable, but they are not interchangeable.

Keep the original timestamp and add normalised fields rather than overwriting source data. A reconciliation record should preserve the raw value, time zone or UTC offset, clock identifier, timestamping method and any estimated uncertainty.

Where available, retain exchange sequence numbers, packet sequence numbers, order IDs and causal references. Those fields can establish ordering when two events fall within the combined uncertainty of their clocks.

A practical reconciliation process is:

1. Define the event model. Specify which system owns each event and which capture point supplies its timestamp. Separate exchange time, network arrival, application processing and client-facing confirmation.
2. Measure each clock. Collect offset and source-health telemetry from the host, NIC and time service. Record sampling frequency and measurement method, not just a pass or fail state.
3. Set budgets by use. Allocate an error budget across the reference, network, host and application. Set warning and action thresholds below the applicable regulatory limit so the response has room to operate.
4. Normalise without hiding uncertainty. Convert timestamps to UTC for comparison, retain raw values and attach an uncertainty range. Do not imply microsecond certainty when the source measurement is only accurate to a millisecond.
5. Resolve order with independent fields. Use sequence numbers and causal links where timestamps overlap within their uncertainty. Flag contradictions for review rather than silently forcing a total order.
6. Test failure and recovery. Simulate reference loss, grandmaster failover, host restart and clock correction. Verify that alerts fire, order controls behave as designed and logs identify the change.

These steps expose a common source of false surveillance alerts: two feeds show the same market event with different delivery paths, while a clock offset makes one appear to lead the other. Reconciliation should preserve that distinction and pass the uncertainty to the surveillance rule. If a rule assumes exact ordering, the assumption needs testing against recorded clock and feed behaviour.

Keep evidence usable after an incident

Clock health is time-dependent. A dashboard showing current offset cannot prove the state of a host during an earlier execution. Retain synchronisation telemetry alongside trading records, with consistent host identifiers and timestamps. That includes source selection, offset, frequency correction, leap status, PTP grandmaster identity and relevant configuration changes.

Set alert thresholds around operational budgets, not merely protocol limits. A warning might trigger investigation when offset consumes half the firm's allowed budget; a higher threshold could block new activity or move traffic to a tested standby path.

The right response depends on the system's role and the cost of interruption. A market-data collector, order gateway and surveillance pipeline do not necessarily need the same action.

Useful evidence typically includes:

• Time-service and PTP logs, including source changes, loss of lock and holdover periods.
• Host and NIC configuration, software versions, timestamp modes and approved tolerance values.
• Alert history, operator actions and any trading restrictions applied during a timing fault.
• Reconciliation output showing raw and normalised times, uncertainty and the sequence fields used.

Retention periods should follow the records applicable to the firm and jurisdiction. Protect the evidence from alteration, control access and test that it can be replayed with the same configuration assumptions. A timing incident is difficult to explain if the firm can show that a clock was healthy today but cannot establish what it reported when the order was sent.

Trading systems measure time in microseconds; regulatory reviews often measure it in folders.

#trading clock synchronisation #PTP time synchronisation #NTP clock drift #MiFID II RTS 25 #trading timestamps #timestamp reconciliation #trade surveillance systems #UTC traceability