Monitoring A Clock vs Proving A Clock: MiFID II, DORA, CAT

Two claims that sound similar but are not

A firm's compliance team can make two different claims about its timing infrastructure, and regulators increasingly treat them as different compliance products. The first is: 'our clocks are monitored, and the monitoring shows they were synchronised within tolerance'. The second is: 'our clocks are attested, and the attestation can be independently verified by any regulator without contacting us'. Both claims can be true simultaneously — a firm can monitor and attest — but the second requires the first and is a superset of it.

The distinction matters when a regulator wants to verify the claim. For a monitoring claim, the regulator asks the firm to produce the monitoring records — the log files, the dashboard exports, the vendor platform reports. The regulator reviews the records and makes a judgement. The verification is fundamentally an exercise in trust: the firm provides the evidence, the regulator accepts or rejects it based on how coherent the evidence looks. There is no independent verification because there is no independent verifier.

For an attestation claim, the regulator asks the firm to produce the attestation fragment — a cryptographically-signed record covering the period in question. The regulator runs the fragment through a standalone verifier tool using a public key the regulator holds independently of the firm. The verifier returns PASS or FAIL. The verification is not an exercise in trust; it is an exercise in mathematics. The firm is not asked to vouch for its own records; the records vouch for themselves.

Why ESMA, FCA and SEC guidance is moving towards proving

The direction of travel in supervisory statements and technical standards is consistent across jurisdictions, even though the specific instruments are different. ESMA guidance on MiFID II RTS 25 has progressively clarified that 'documented traceability' means auditable traceability — evidence that a regulator can evaluate, not evidence the firm asserts. The FCA's supervisory statements on operational resilience have used similar language. The SEC's Consolidated Audit Trail specifications explicitly require NIST-traceable timestamps with attestation; the word 'attestation' is not decorative.

There are three reasons for the shift. The first is a series of enforcement proceedings across the last five years in which firm-produced log-file evidence has been contested, with firms unable to conclusively demonstrate that their records were unmodified. Regulators have responded by tightening the evidentiary standard rather than relaxing it. The second is the technical capability of modern regulatory teams — which now include engineers who understand that a log file produced and stored by the firm is not structurally different from any other record the firm maintains about itself, and who are not willing to accept 'we have records' as equivalent to 'the records are provably accurate'.

The third is pragmatic. As reporting obligations scale (CAT has produced petabytes of data per quarter since 2020, DORA will produce comparable volumes from 2025 onwards), manual reconciliation of log-file evidence is not tractable at the regulator's end. Attestation chains verify programmatically at any scale — a regulator can bulk-verify every firm's submissions against a single public key, producing PASS/FAIL results across the entire reporting population in minutes. This is the mechanism that regulators will increasingly use because it is the only mechanism that scales.

What log-file compliance actually produces

A typical incumbent timing platform emits log files at 15- or 60-second intervals — host identifier, timestamp, claimed offset to UTC, claimed source of reference, status text. When a regulator requests evidence of UTC synchronisation for a specific trade date, the firm runs a query against these log files, filters to the relevant host and time window, exports the result in whatever format the regulator asked for, and submits.

Three structural problems surface at the moment of verification. First: authenticity. The log file was generated and stored by the firm's own systems. Nothing about the file structurally prevents post-hoc modification, and the regulator has no independent way to verify that the submitted version matches what was originally recorded. Second: traceability. The log records that the clock claimed to be synchronised at 15-second intervals; it does not record that the clock was within UTC tolerance at the specific microsecond-level moment at which a trade was timestamped. Third: independence. The regulator's verification of the log depends on trusting the firm's process — it is not possible to verify the log in isolation, using only the log and public information.

These are not cosmetic problems. In the event of an enforcement proceeding, each of the three gaps becomes a ground for challenging the evidence. A firm with a strong operational record and well-managed infrastructure may still struggle to defend a log-file-only evidence trail against a regulator who is not willing to accept the evidence at face value. The firm is not being treated with suspicion; the regulator is applying the evidentiary standard that is becoming the norm across financial records domains.

What attestation actually produces

UTC Verification signs the clock state of each attested host once per second. Every signed record contains the host's identifier, the measured offset to its reference, the path delay, the GNSS quality indicator, the holdover status, and the chain identifier that traces back to the national UTC reference (NPL, NIST or PTB depending on jurisdiction). The record is signed with TimeBeat's attestation key and includes the cryptographic hash of the previous signed record — forming the chain.

Verification is the inverse operation. A regulator presented with an attestation fragment — a sequence of consecutive signed records covering some period — uses the published public attestation key and a standalone verifier tool to check: every record in the fragment is validly signed (using the public key), the chain of hashes is internally consistent (using a standard hash function), the records fall within the claimed date range, the host identifier matches what the firm submitted, and the reference chain terminates at the expected national UTC reference. Any mismatch is immediate and unambiguous.

The verifier is a command-line tool, not a cloud service. It runs on the regulator's own infrastructure, takes the fragment and the public key as inputs, and produces PASS or FAIL. There is no network call, no dependency on TimeBeat, no dependency on the firm's systems. The regulator's review of the evidence is a mathematical check that completes in seconds per fragment. At scale — across a population of firms — the verification runs in bulk with no additional tooling.

Why the attestation chain has to be unbroken

A single signed record proves the clock state at a moment. A chain of signed records proves that the records themselves have not been modified since they were signed — because any modification to an earlier record changes its hash, which invalidates the chain link in every subsequent record. The chain property is what turns attestation from 'here is a signed record' into 'here is a record, and here is proof that the record has not been altered since the moment it was signed'.

This matters operationally because the evidence window is not a single moment; it is a period. A regulator asking for evidence of UTC synchronisation during the period a trade was executed wants to see the sequence of clock states around that trade — the moments before, the moment of, the moments after. The chain gives them that sequence with integrity guarantees on every record.

Breaking the chain is detectable. If a firm tried to edit one clock-state record in the middle of a week's attestation — to paper over a brief holdover event, for example — the hash of that modified record would differ from the hash referenced by the next record in the chain. The regulator's verifier tool would return FAIL at the exact record where the chain broke. The firm cannot selectively edit history without the edit being mathematically visible.

What the three big regulators each ask for

ESMA under MiFID II RTS 25 Article 2 requires HFT business clocks to remain within 100 microseconds of UTC with documented traceability. The documented traceability has to be available at all times, not on request — supervisory statements have been explicit that firms should be able to produce the evidence without a preparation window. Sync Insight's MiFID II report template is designed for daily auto-scheduled delivery, which satisfies the availability requirement structurally.

DORA Articles 9, 10 and 11 require accurate ICT records (Art 9), continuous monitoring (Art 10), and documented business continuity (Art 11). Article 9's 'accurate, complete and consistent' standard is the one attestation chains are directly designed for — the chain is inherently accurate, it covers the entire reporting period, and the per-second cadence is inherently consistent. Article 10's continuous monitoring is satisfied by the 167-field telemetry stream; Article 11's business continuity is a topology question that attestation does not solve on its own but does evidence continuously.

SEC CAT requires NIST-traceable timestamps within 1 millisecond. The attestation chain is rooted in NIST for US deployments — the reference chain identifier in each signed record is NIST's published UTC reference, and the chain-root verification is a standard CAT submission requirement. Pre-built CAT compliance reports export from Sync Insight in one click, structured to match the CAT reporting format with the attestation fragment attached. FINRA OATS and Rule 6030 follow similar patterns with their own report templates.

The gap that is not about accuracy

The most important point about the move from monitoring to proving is that it is not primarily about accuracy. Incumbent timing hardware — OCXO-grade grandmasters, vendor monitoring platforms, well-established PTP distribution — meets the published accuracy tolerances comfortably under normal conditions. MiFID II RTS 25's 100 microsecond tolerance is not a tight number; most deployments operate with two or three orders of magnitude of headroom.

The gap is not at the hardware layer. It is at the evidence layer. A perfectly accurate clock that can only be evidenced through log files has the same compliance exposure under DORA Article 9 as an inaccurate clock that can only be evidenced through log files — because the Article 9 requirement is about the records, not about the clock. A firm with excellent timing hardware and no attestation has an open compliance gap; a firm with ordinary timing hardware and full attestation has no gap at all.

This is why the Sync Insight deployment motion in finance is almost always 'install Sync Insight first, discuss hardware second'. Sync Insight on existing incumbent infrastructure closes the evidence gap at the software layer without touching the hardware. A 30-day Sync Insight trial on PAYG at £1.12/device/day produces attestation-ready evidence of the firm's existing clocks — which is sufficient for most Article 9 purposes even before any hardware conversation happens. The hardware conversation, when it happens, is about improving the attested clock rather than producing the attestation in the first place.

What to do this quarter

Three practical next steps, specifically framed for a CCO or compliance-owning stakeholder.

• ●Commission a 30-day Sync Insight trial alongside your existing timing infrastructure. PAYG at £1.12/device/day for 1–20 devices, no procurement approval needed at that scale. First attestation within 24 hours. Compare against your current vendor platform's output and share both with the compliance team.
• ●Request a 45-minute CCO compliance briefing. We walk through the gap between your current platform's output and a verifiable attestation chain, using your own data. Output is a one-page DORA / MiFID II gap assessment and a specific technical recommendation.
• ●If the trial and briefing surface a material gap, move to Enterprise at £2,495/month — the compliance layer with UTC Verification, MiFID II / DORA / CAT reports and 90-day retention is activated from day one. For multi-site tier-1 deployments, the path is Enterprise+ with bespoke retention and RBAC.