CAT Reporting (Consolidated Audit Trail)
The obligation under FINRA Rule 6800 Series and SEC Rule 613 for broker-dealers to report every NMS and OTC equity order event to the CAT Central Repository by 8:00 AM ET on T+1, with customer account data updated daily through CAIS.
Definition
CAT reporting is not a reporting task. It is a data integrity mandate with a cross-market surveillance capability built on top. FINRA uses the Consolidated Audit Trail to reconstruct the complete lifecycle of every NMS security and OTC equity order across every venue it touched — from the moment a customer order arrived at a broker-dealer's desk to every routing decision, every partial fill, every modification, and every post-trade allocation. The audit trail FINRA can construct from CAT data is more granular, more cross-venue, and more linkage-precise than any regulatory dataset that existed before it. For broker-dealers, this means that a data quality failure in CAT — a broken linkage, a late submission, an inaccurate account holder type, a lapsed LEI in CAIS — is not merely a technical error. It is a gap in the audit record that regulators use to assess market conduct, investigate manipulation, and evaluate the firm's supervisory effectiveness.
The CAT reporting framework rests on three obligations that are distinct in their data sources, their technical requirements, and their compliance deadlines. The first is order event reporting under FINRA Rule 6830: Industry Members must record and report every Reportable Event — original receipt or origination, routing, receipt of a routed order, modification, cancellation, execution (full or partial), and allocation — for every NMS security and OTC equity security order they handle, by 8:00 AM Eastern Time on the Trading Day following the event. The second is clock synchronization under FINRA Rule 6820: the firm's Business Clocks must be synchronized to within a 50-millisecond tolerance of the time maintained by the NIST atomic clock — at a minimum before market open each business day, with continuous NTP synchronization being the standard implementation — and material violations must be documented and reported pursuant to thresholds set by the Operating Committee. The third is the Customer and Account Information System (CAIS) under FINRA Rule 6840: daily submission of customer account identifiers, customer identifying information, and the Firm Designated ID (FDID) for every account with activity in Eligible Securities in the prior six months. Each of the three fails independently and exposes the firm independently in examination.
The Order Lifecycle and CAT-Order-ID Linkage
The technical spine of CAT compliance is the CAT-Order-ID — defined in Rule 6810 as the unique identifier that allows the Central Repository to efficiently and accurately link all Reportable Events for an order and orders resulting from aggregation or disaggregation. Every event in the order's lifecycle must carry the same CAT-Order-ID: the order receipt, every routing hop, every execution, every modification, and the final allocation. An order that was received, routed to three venues, partially filled twice, and then fully allocated must have a single, consistent CAT-Order-ID connecting every one of those events. Firms may assign the CAT-Order-ID using internal order identifiers or purpose-built mapping logic — the regulatory requirement is that linkage is preserved end-to-end, not that the identifier is derived by any specific method. In FIX-based electronic order flow — the dominant architecture at US broker-dealers — the FIX protocol trade capture system supplies the reference chain from which CAT linkage is typically anchored: FIX Tag 11 (ClOrdID), generated at order receipt and carried on every subsequent order message, and FIX Tag 37 (OrderID), assigned by the executing venue and carried on execution reports, are the persistent cross-system identifiers that maintain the event thread. When either tag is dropped at a system boundary — at a gateway handoff, during OMS enrichment, or at a clearing interface — that reference chain breaks, and the downstream event cannot be connected to its originating order in the Central Repository. A routing event without a traceable originating order receipt, or an execution that cannot be connected back to its routed order, is a linkage error. Linkage errors are both detectable in the CAT Reporter Portal and visible to FINRA examiners reviewing a firm's audit trail for a specific date or security.
CAT Reportable Events — event type, FIX anchor, and T+1 deadline
| Event Type | Trigger | FIX Anchor (Tags) | Reporting Deadline |
|---|---|---|---|
| Order Receipt / Origination | Customer order received or firm order originated | Tag 11 ClOrdID · Tag 55 Symbol · Tag 54 Side | 8:00 AM ET T+1 |
| Order Route | Order sent to exchange, ATS, or market maker | Tag 11 ClOrdID · Tag 37 OrderID | 8:00 AM ET T+1 |
| Order Execution | Full or partial fill confirmed | Tag 37 OrderID · Tag 17 ExecID | 8:00 AM ET T+1 |
| Modification / Cancellation | Order terms changed or order cancelled | Tag 11 ClOrdID · Tag 41 OrigClOrdID | 8:00 AM ET T+1 |
| Allocation | Post-execution allocation to client account | Tag 17 ExecID · Allocation ID · FDID | 8:00 AM ET T+1 |
| Error Correction | Repairable error identified post-submission | Original CAT-Order-ID | 8:00 AM ET T+3 |
CAIS: The Customer Data Layer
The Customer and Account Information System is the second tier of CAT reporting and, alongside linkage error management and timestamp accuracy, one of the most operationally demanding ongoing compliance obligations for broker-dealers in 2026. The CAIS obligation under Rule 6840 requires daily submission of the Firm Designated ID (FDID), the Transformed Value of each customer's SSN or ITIN, and full Customer Account Information and Customer Identifying Information for every account with activity in the prior six months. For legal entity customers, the required Customer Identifying Information includes the Legal Entity Identifier (LEI) — and under Rule 6893(b), firms may not knowingly submit inaccurate LEIs to the Central Repository. An LEI that has lapsed, been transferred to a different entity, or been entered with transposition errors in the account master flows into the daily CAIS submission as a CAIS error, generating a correction requirement due by 5:00 PM ET on T+3. The scale of the CAIS data governance challenge is determined by account universe size: a carrying firm with hundreds of thousands of active accounts must maintain a customer data infrastructure — FDID integrity, LEI currency, address validation, beneficial owner completeness — that can produce a clean daily update without systematic errors. Firms that inherited account records from legacy systems with inconsistent data standards, or that acquired client books through mergers without normalizing customer data, find CAIS data governance to be the most resource-intensive element of ongoing CAT compliance.
The T+1 Compression Effect
The May 2024 transition to T+1 settlement did not change the CAT reporting deadline — broker-dealers were already required to submit by 8:00 AM ET on T+1. What changed is the operational window in which that deadline must be met. Under T+2, the overnight period before the T+1 CAT deadline was available for validation, enrichment, and correction. Under T+1, that window compresses: the settlement instruction generation, affirmation, and break resolution workflows that the operations team runs on T+1 morning now run in parallel with the CAT submission deadline. The CAT deadline does not move. Same-day validation — checking linkage integrity, FDID resolution, and timestamp accuracy before the overnight batch — is the minimum operational standard, not a best practice, in a T+1 environment. Firms that validated CAT data only on the morning of T+1, relying on the settlement buffer to catch enrichment errors, now have no such buffer: a linkage break discovered at 7:30 AM on T+1 has thirty minutes to be corrected or it becomes a repairable error on a T+3 clock.
CAT event lifecycle — receipt to unified audit thread
Devancore Glossary · devancore.com
CAT event lifecycle — receipt to unified audit thread
Devancore Glossary · devancore.com
How it works
1. Synchronize Business Clocks before market open
Rule 6820 requires that all Business Clocks used for recording Reportable Events be synchronized to within 50 milliseconds of the time maintained by the NIST atomic clock, at a minimum before market open each business day. In practice, most firms achieve this through continuous Network Time Protocol (NTP) synchronization against NIST time sources — which satisfies the daily minimum and prevents incremental drift accumulation throughout the session. Clock synchronization is not a one-time infrastructure setup: it is a recurring compliance obligation with a documented audit trail. The synchronization log — recording the time and result of each sync event, and any instance of drift beyond the applicable tolerance — must be retained for at least five years under Rule 6820(b). Drift violations that exceed the threshold established by the Operating Committee must be reported to the Plan Processor and FINRA under Rule 6820(d); not every momentary deviation from the 50ms tolerance triggers a formal report, but any drift that crosses the Operating Committee's reporting threshold requires disclosure. Clocks used solely for Manual Order Events operate under a one-second tolerance. Firms that outsource clock synchronization or time infrastructure to third-party providers must obtain sufficient documentation from the vendor to evidence ongoing compliance — and must maintain written supervisory procedures that identify who is responsible for verifying vendor performance against the Rule 6820 standard.
2. Capture order events with contemporaneous timestamps
Rule 6830(b)(1) requires that Recorded Industry Member Data be captured contemporaneously with each Reportable Event — not reconstructed after the fact from settlement records or counterparty confirms. At order receipt, the trade capture system must record the FIX ClOrdID (Tag 11), the FDID for the originating customer account, the Material Terms of the Order, the department type, the account holder type, and the precise timestamp of receipt at millisecond granularity. At routing, the routing event must carry the same CAT-Order-ID as the originating receipt event — whether that identifier is maintained through the FIX ClOrdID or through an internal mapping — along with the SRO-Assigned Market Participant Identifier of both the routing and receiving firm, and the timestamp of the routing event. At execution, the execution event must carry the CAT-Order-ID, the execution price and size, the execution capacity (principal, agency, or riskless principal), and the contra-side order information. Each event is captured in the order management system as it occurs; the CAT reporting file is assembled from this event log — not constructed from a post-trade reconciliation.
3. Resolve FDID for each order and validate CAIS
Before CAT file generation, every order event must be enriched with a Firm Designated ID that is unique and persistent for the originating customer account. FDID resolution pulls from the account master: the FDID must match the identifier registered for that account in the CAIS submission. For legal entity accounts, the LEI must be current and valid — a lapsed or incorrect LEI in the CAIS submission generates a CAIS error that creates a T+3 correction obligation. Daily CAIS updates must be prepared separately from the order event file, covering any accounts whose information has changed since the prior submission, any newly active accounts, and any CAIS corrections for previously submitted errors. The CAIS correction deadline — 5:00 PM ET on T+3 — differs from the order event correction deadline of 8:00 AM ET on T+3, requiring two parallel error correction queues.
4. Generate and validate the CAT submission file
The CAT submission file is generated from the order event log and validated against the CAT Reporting Technical Specifications before transmission. Pre-submission validation checks: linkage integrity (every routing event connects to a receipt; every execution connects to a routing), FDID population for all customer orders, timestamp format conformance to Rule 6860, Material Terms completeness, and field value consistency (account holder type, side, order type, and handling instruction codes matching the permitted value set). Validation failures that are caught pre-submission are correctable at T+0 — before the file is transmitted and before the T+3 error correction clock starts. Validation failures discovered post-submission in the CAT Reporter Portal become repairable errors subject to the T+3 deadline. The economic incentive to run rigorous pre-submission validation is direct: a pre-submission fix costs nothing in regulatory terms; a post-submission error costs a T+3 correction cycle and contributes to the firm's error rate.
5. Submit to the Central Repository by 8:00 AM ET
The validated CAT file is transmitted to the Central Repository via the secure connection established under Rule 6870. Firms may use a CAT Reporting Agent to transmit data on their behalf, but remain fully responsible for timeliness and accuracy. The Plan Processor confirms receipt and acceptance or rejection; firms should check the CAT Reporter Portal daily — as both a compliance review obligation and as the primary mechanism for identifying submission or integrity errors before they age into T+3 correction obligations. Rule 6870 also addresses CAT Reporting Agent eligibility and the firm's supervisory obligations over any agent acting on its behalf.
6. Monitor the CAT Reporter Portal and manage errors
The Plan Processor makes CAT Report Cards available to each Industry Member through the CAT Reporter Portal — a view of the firm's submission history, acceptance rates, and error rates compared to aggregate industry performance. Daily review of the Portal is both a FINRA examination expectation and an operational necessity. Errors identified by the Plan Processor appear in the Portal with a repairable or non-repairable designation. Repairable errors — data that can be corrected and resubmitted — must be resolved by 8:00 AM ET on T+3. The T+3 window starts from the original reporting date, not from the date the error was detected in the Portal; a firm that checks the Portal only weekly will systematically discover T+3 deadlines that have already expired or are hours away.
7. Submit corrections by T+3 and maintain audit records
Error corrections are submitted to the Central Repository by 8:00 AM ET on T+3 for order event errors, and by 5:00 PM ET on T+3 for CAIS errors. Every submitted correction must carry the original CAT-Order-ID or account reference, the corrected field values, and an indicator that the submission is a correction. Rule 6890 (Recordkeeping) requires Industry Members to maintain CAT order records as part of the firm's books and records, consistent with SEC Rule 17a-4 WORM retention requirements. The correction history — every original submission, every error identified, every corrected submission, and the timestamps of each — is the audit trail that FINRA examiners review when assessing whether a firm's error correction process is adequate and whether late corrections are a systemic pattern or an isolated event.
Daily CAT compliance cycle — market open to submission
Devancore Glossary · devancore.com
In Devancore™
Devancore — pre-submission CAT validation path
Devancore Glossary · devancore.com
Devancore — pre-submission CAT validation path
Devancore Glossary · devancore.com
Devancore's CAT reporting module operates as a native extension of the trade capture and order management infrastructure, not as a post-trade translation layer. Because the FIX ClOrdID (Tag 11) and OrderID (Tag 37) are captured at execution and retained as first-class fields in the trade record and settlement instruction, the CAT event linkage chain is a native property of the data in Devancore's system of record — not a reconstruction task performed overnight before the 8:00 AM deadline. Every order event — receipt, route, execution, modification, and allocation — is logged with a contemporaneous timestamp at the point of occurrence, using the system clock that is synchronized against the NIST atomic clock before each market open.
Pre-Submission Validation at T+0
Before any CAT file is transmitted to the Central Repository, Devancore runs the full CAT validation logic against the assembled event file. The pre-submission check verifies linkage integrity — every routing event is connected to an originating receipt, every execution is connected to a routed order — FDID population for every customer order, timestamp format conformance to Rule 6860, Material Terms field completeness, and field value codes against the permitted value set in the CAT Reporting Technical Specifications. Validation failures that are caught in this pass are surfaced to the operations team at T+0, before the file leaves the firm, and before the T+3 error correction clock starts. The specific error category — linkage break, missing FDID, invalid account holder type, timestamp format violation — is displayed alongside the originating order record, so the operations team can trace the failure to the source system field that produced it rather than searching through the CAT Reporter Portal the following morning.
Atomic Traceability: FIX Tags as Native CAT Linkage
The structural advantage Devancore provides for CAT linkage is that FIX tags are not dropped at system boundaries. In infrastructure architectures where the OMS, the execution gateway, the clearing interface, and the CAT reporting layer are separate systems with separate data models, the ClOrdID frequently fails to propagate across handoffs — particularly at clearing interfaces that do not natively carry FIX order identifiers. In Devancore, the trade record carries the original FIX ClOrdID through the full lifecycle: from order capture through the sese.023 settlement instruction to the trade lifecycle management record. The CAT-Order-ID is derived from the ClOrdID using a deterministic mapping that is consistent across every event for the same order — not regenerated independently at each event, which would produce linkage breaks even when the ClOrdID is present.
FDID Resolution and CAIS Data Governance
FDID resolution is handled at the account master level: every trading account in Devancore carries a Firm Designated ID that is assigned at account creation, validated for uniqueness and persistence, and never reused or reassigned. When an order is captured, the FDID is resolved from the account record at the point of order receipt — not enriched downstream where the account context may be ambiguous. For legal entity accounts, the account master carries the LEI with a status field that reflects the current GLEIF validation status; a lapsed or pending LEI is flagged before the CAIS daily submission is generated, and the flagged account is surfaced in the CAIS data governance queue for review before the submission window closes. The daily CAIS update is generated from the delta between the current account master state and the last accepted CAIS submission, producing a targeted update rather than a full resend.
Error Dashboard and T+3 Countdown
Post-submission, Devancore monitors the CAT Reporter Portal and ingests error reports as they are issued by the Plan Processor. Each repairable error is entered into the error management queue with a T+3 countdown clock — the absolute deadline by which the corrected submission must reach the Central Repository. Errors are prioritized by type: linkage breaks and FDID errors are classified as higher-priority because they affect the completeness of the order audit trail; field value errors in non-linkage fields are lower-priority but still tracked against the T+3 window. The error rate for each submission is tracked against the firm's Compliance Threshold as defined by the Operating Committee — giving the compliance team advance visibility into whether the current error pattern is approaching the threshold before it becomes an examination issue. Every pre-submission validation run, every error identified, every correction submitted, and the result of each is retained in the immutable audit log under SEC Rules 17a-3 and 17a-4 and FINRA Rule 6890 recordkeeping requirements, providing the documented evidence of daily Portal review that FINRA examiners request in broker-dealer compliance technology reviews.