FINRA Rule 6820

Business Clocks used solely for Manual Order Events, and those used solely for allocation timing on Allocation Reports, are instead held to a looser one-second tolerance, reflecting the practical reality that manually captured order information cannot realistically achieve the same millisecond-level precision that fully automated systems can.

The tolerance calculation itself is defined to include multiple contributing components rather than measuring a single isolated factor, with the difference between the NIST atomic clock and the Industry Member's own Business Clock forming the first and most direct element of that calculation. This layered approach to defining tolerance reflects the practical reality that clock drift can accumulate from several distinct sources, the underlying time provider's own accuracy, network latency in receiving time signals, and the Business Clock's own internal drift between synchronization events, all of which must collectively remain within the fifty-millisecond or one-second threshold depending on which category of clock is at issue.

Where the Fifty-Millisecond Standard Actually Originated

Candidates and practitioners often assume the fifty-millisecond standard was created specifically for CAT, but its true origin lies elsewhere. The SEC approved this standard in 2016, described in Regulatory Notice 16-23, tightening a prior one-second synchronization requirement that had applied under the Order Audit Trail System framework. 

That 2016 change relocated the underlying clock synchronization obligation out of the OATS-specific rule set entirely and into a newly created, generally applicable Rule 4590, applicable to business clocks recording events required under the FINRA By-Laws or FINRA rules generally, not merely OATS-reportable events specifically. Firms received a phased implementation window: six months, until February 20, 2017, for systems already capturing time in milliseconds, and eighteen months, until February 19, 2018, for systems that did not yet capture time at that granularity.

When FINRA later proposed the original CAT Compliance Rule Series in 2017, it adopted the identical fifty-millisecond standard for Rule 6820 rather than inventing a new tolerance from scratch, since the SEC had already determined, in approving the CAT NMS Plan itself, that this standard was reasonable for CAT's initial implementation. The SEC's own language describing this determination is worth noting precisely: the fifty-millisecond standard was deemed reasonable "for the initial implementation of the CAT," phrasing that leaves open the possibility of future tightening as the system matures, a possibility firms should keep in view rather than assuming today's tolerance is permanently fixed.

Resolving the Overlap Between Rule 4590 and Rule 6820

Because both Rule 4590 and Rule 6820 independently establish a fifty-millisecond clock synchronization standard, firms recording events in NMS securities and OTC Equity Securities found themselves technically subject to two overlapping rules covering the same underlying obligation. FINRA addressed this duplication through a filing described in a 2023 SEC release, clarifying that Rule 4590 applies only where Rule 6820 does not, meaning Rule 6820 governs business clocks used to record events for NMS securities and OTC Equity Securities, while Rule 4590 continues to apply to business clocks recording events in other security types outside CAT's scope, most notably debt securities. This 2023 clarification did not change either rule's substantive tolerance standard; it simply resolved which rule actually governs a given clock, eliminating the redundancy of two technically applicable but substantively identical requirements covering the same clock.

This jurisdictional split matters practically for firms determining which rule to cite in their own written supervisory procedures and compliance documentation. A firm's equity trading desk clocks fall under Rule 6820, tied to the CAT Compliance Rule Series, while a firm's fixed income desk clocks, recording events in debt securities outside CAT's Eligible Security scope, remain governed by Rule 4590 instead, each carrying the same numeric tolerance but sitting within different rule series with potentially different associated obligations elsewhere in the rulebook, including different examination and enforcement pathways depending on which series ultimately governs a given clock.

A Standard Adopted Across Virtually Every Self-Regulatory Organization

Rule 6820 is not unique to FINRA. Because the fifty-millisecond standard flows from the CAT NMS Plan itself, every Participant in that Plan, meaning every national securities exchange alongside FINRA, has adopted a substantively identical clock synchronization rule, frequently numbered identically as "Rule 6820" across exchange rulebooks including Nasdaq, NYSE, NYSE American, NYSE Arca, NYSE National, Cboe's various option exchanges, MIAX, MIAX PEARL, and IEX, among others. This uniformity is deliberate: the CAT NMS Plan requires consistent clock synchronization across every Participant, since CAT's ability to reconstruct a cross-market order's complete lifecycle depends on every venue and every Industry Member reporting time using a consistent, mutually reliable standard, without which timestamps recorded at one venue could not be meaningfully compared against timestamps recorded at another as an order moved between them. A firm operating across multiple markets does not face different clock synchronization tolerances depending on which exchange or facility ultimately handles a given order, a genuine convenience given how fragmented order routing across competing venues has become in modern equity and options market structure.

Documentation and Certification Obligations

Rule 6820 imposes specific recordkeeping and reporting obligations beyond the raw synchronization standard itself. Industry Members must document and maintain their synchronization procedures, and must keep a log recording each synchronization event's time and outcome, including notice of any occasion when a Business Clock drifted beyond the applicable tolerance. This log must cover a period of not less than five years ending on the current date, or the entire period the Industry Member has been subject to this rule if that period is shorter than five years, giving FINRA a substantial historical record to examine if questions arise about a firm's clock synchronization practices over time.

Separately, each Industry Member must periodically certify to FINRA that its Business Clocks satisfy these synchronization requirements, following the certification schedule the CAT NMS Plan's Operating Committee establishes. This certification obligation functions as an affirmative, recurring attestation rather than a passive recordkeeping requirement alone, meaning a firm cannot simply maintain internal logs and wait to be asked; it must proactively confirm compliance to FINRA on the schedule the Operating Committee sets, a schedule that has historically included both an initial certification and annual recertification thereafter.

Self-Reporting Obligations for Significant Drift

Beyond the baseline synchronization and logging requirements, Industry Members must separately report certain categories of clock drift to the Plan Processor and to FINRA when specified thresholds, established by the CAT NMS Plan's Operating Committee, are breached. Under the Operating Committee's published parameters, a "large drift" violation requiring self-reporting occurs when a device or server handling CAT Reportable Events drifts out of compliance by two times the applicable standard, meaning one hundred milliseconds for systems subject to the standard fifty-millisecond tolerance, or two seconds for systems subject to the one-second Manual Order Event and Allocation Report tolerance. A "persistent drift" violation, by contrast, requires self-reporting when a device or server drifts out of compliance ten separate times within a single rolling twenty-four hour period, capturing a pattern of repeated, shorter drift episodes that might not individually reach the large-drift threshold but collectively suggest a systemic synchronization problem.

This two-tiered self-reporting framework reflects a deliberate design choice: rather than requiring firms to report every minor, momentary drift excursion, which would generate an overwhelming volume of largely uninformative notifications, FINRA and the Operating Committee calibrated the thresholds to surface genuinely significant drift events, either a single large excursion or a recurring pattern, while leaving isolated, minor, quickly corrected drift within the routine logging obligation rather than escalating it to an affirmative reporting duty. Firms should understand that meeting the baseline logging requirement under Rule 6820 does not by itself satisfy this separate self-reporting obligation when a large-drift or persistent-drift threshold has actually been crossed; the two obligations operate in parallel rather than one substituting for the other, and a firm that only maintains its logs without actively monitoring for these specific threshold breaches risks missing a genuine self-reporting obligation entirely.

The Underlying Technical Infrastructure

Achieving and maintaining fifty-millisecond synchronization in practice depends on the underlying time infrastructure a firm deploys, typically built around Network Time Protocol servers referencing a Stratum 1 time source, commonly a GPS-disciplined clock capable of tracing its accuracy directly back to the NIST standard with only a few milliseconds of inherent deviation from that authoritative reference. Firms relying on a properly configured Stratum 1 NTP source generally have substantial margin within the fifty-millisecond tolerance, since a well-implemented GPS-referenced time server can typically achieve accuracy in the low single-digit milliseconds under normal operating conditions, well inside the regulatory threshold FINRA requires.

The greater practical risk usually lies not in the time source itself but in how reliably that source's signal actually propagates to every individual Business Clock across a firm's technology estate. Network latency, server load, virtualization layers, and the sheer number of distinct systems requiring synchronization can each introduce drift between the authoritative time source and any given downstream system's actual recorded time, particularly for systems that synchronize periodically rather than continuously. A firm's clock synchronization architecture should account for this propagation risk explicitly, rather than assuming that deploying an accurate central time source alone guarantees every downstream Business Clock remains within tolerance without additional monitoring.

Relevance Across FINRA's Exam Programs

The SIE, Series 63, and Series 65 do not test Rule 6820's specific tolerance figures, since these exams do not reach into the technical infrastructure underlying market-wide surveillance systems. A Series 7 candidate is unlikely to encounter this rule directly, though a general awareness that accurate, synchronized timekeeping underlies FINRA's ability to reconstruct market activity provides useful context for understanding why FINRA's technology-focused rules exist at all.

A Series 24 candidate supervising trading operations needs working command of the fifty-millisecond and one-second tolerance distinction, since a principal reviewing a firm's technology infrastructure should be able to identify which category a given Business Clock falls into and confirm the firm's synchronization procedures actually match the applicable standard. A Series 57 candidate should understand precisely why Manual Order Event clocks receive the more forgiving one-second tolerance rather than assuming the fifty-millisecond standard applies universally across every timestamp a firm records, since misapplying the stricter standard where the rule does not actually require it can create unnecessary operational friction, while failing to apply it where required creates genuine compliance exposure.

Practical Guidance for Firms

Firms should treat the five-year log retention requirement as a genuine, ongoing recordkeeping obligation rather than an incidental byproduct of routine system operations, ensuring their synchronization logs are actually preserved in a readily accessible format for the full required period rather than allowed to age out of active system storage informally. A firm unable to produce five years of synchronization history during a FINRA examination faces a recordkeeping deficiency independent of, and in addition to, any actual synchronization accuracy problem the firm's clocks may or may not have had during that period.

Firms should also build periodic internal review of the Rule 4590/Rule 6820 jurisdictional split into their own compliance documentation, ensuring written supervisory procedures correctly cite Rule 6820 for equity-side clocks and Rule 4590 for fixed income clocks rather than treating the two rules interchangeably now that FINRA has clarified their respective scopes. A firm's technology infrastructure often spans both equity and fixed income business lines using shared or overlapping systems, and confirming which specific clocks fall under which rule, rather than assuming uniform treatment across the firm's entire technology stack, helps ensure the firm's documentation accurately reflects its actual regulatory obligations.

Given the SEC's own acknowledgment that fifty milliseconds was deemed reasonable specifically for CAT's "initial implementation," firms should treat this tolerance as a standard that could tighten over time rather than a permanently fixed figure, and should build technology infrastructure with some margin of capability beyond the current minimum requirement where practical. A firm whose systems can already synchronize well within the fifty-millisecond tolerance, rather than merely at the edge of compliance, is better positioned to absorb a future tightening of this standard without requiring an entirely new infrastructure investment on short notice.

Firms should also incorporate the large-drift and persistent-drift self-reporting thresholds directly into their automated monitoring infrastructure rather than relying on manual log review to catch a qualifying event after the fact. A monitoring system configured to flag any device crossing the hundred-millisecond or two-second threshold in real time, and separately to flag any device accumulating ten drift episodes within a rolling twenty-four hour window, allows a firm to satisfy its self-reporting obligation promptly rather than discovering a reportable event only during a periodic manual review of historical logs, by which point the reporting window may already have been missed.

Firms evaluating or upgrading their clock synchronization infrastructure should specifically assess propagation risk across their full technology estate, not merely the accuracy of their central time source, given that this propagation gap is typically where real-world drift problems actually originate. A firm with dozens or hundreds of individual servers, trading applications, and order management systems requiring synchronized time should map out how frequently each system actually re-synchronizes against the central source, since infrequent synchronization intervals allow more opportunity for drift to accumulate between checks, even where the underlying central time source itself remains highly accurate throughout.

Finally, firms should recognize that clock synchronization compliance under Rule 6820 is not a standalone technical concern isolated from the firm's broader CAT reporting accuracy. A Business Clock that drifts outside tolerance does not merely create a Rule 6820 violation in isolation; it also potentially corrupts the timestamp accuracy of every Reportable Event that clock records during the period of drift, creating downstream Rule 6830 reporting accuracy problems layered on top of the underlying synchronization failure. Firms should therefore treat clock synchronization monitoring as an upstream control protecting the integrity of their entire CAT reporting program, not merely a discrete, isolated compliance checkbox to be satisfied independently of the firm's broader order and trade reporting obligations.