Customer Information Reporting
FINRA Rule 6840 governs a distinct stream of CAT reporting separate from the order and execution data addressed in Rule 6830: the customer and account identifying information the Central Repository needs to link every reported order back to the actual customer or account that originated it.
Where Rule 6830 captures what happened to an order, Rule 6840 captures who was behind it, and getting this identification layer right is what ultimately allows FINRA and other regulators to reconstruct a complete, customer-level picture of trading activity across the entire market rather than a disconnected sequence of anonymous order events.
The Four-Part Reporting Structure
Rule 6840 organizes an Industry Member's customer information obligations into four distinct components. Paragraph (a) requires an initial submission: each Industry Member must submit to the Central Repository the Firm Designated ID, the Transformed Value for ITIN or SSN, Customer Account Information, and Customer Identifying Information for each of its Customers with an Active Account, prior to that Industry Member's commencement of reporting to the Central Repository and in accordance with the deadlines set forth in Rule 6880. This initial submission establishes the baseline customer population the Central Repository will subsequently track and update.
Paragraph (b) requires daily updates: any changes, additions, or other updates to this same information must be submitted to the Central Repository on a daily basis, ensuring the Central Repository's customer data remains current as accounts open, close, or change rather than growing stale between periodic refreshes. Paragraph (c) adds a further layer beyond daily incremental updates: on a periodic basis designated by the Plan Processor and approved by the Operating Committee, each Industry Member must submit a complete refreshed set of this same customer information, a full-population resubmission rather than merely an incremental update, intended to catch and correct any drift or inconsistency that might otherwise accumulate through incremental daily updates alone. FINRA announces when such a periodic refresh is required through Regulatory Notice, giving firms advance notice before a refresh cycle begins.
The Distinct Correction Deadline
Paragraph (d) addresses error correction, and here Rule 6840 diverges from the parallel correction deadline found in Rule 6830 in a way candidates and practitioners should not overlook. Where errors in previously submitted Firm Designated ID, Transformed Value, Customer Account Information, or Customer Identifying Information have been identified, whether by the Plan Processor or otherwise, the Industry Member must submit corrected data to the Central Repository by 5:00 p.m. Eastern Time on T+3. This is a materially different clock time than the 8:00 a.m. Eastern Time T+3 correction deadline that applies to ordinary Industry Member Data errors under Rule 6830; a firm that mentally applies a single, uniform "T+3" correction standard across both rules risks missing the customer-information-specific 5:00 p.m. deadline while correctly meeting the 8:00 a.m. deadline for order and execution data errors, or vice versa.
The Firm Designated ID in Depth
The Firm Designated ID, or FDID, is the linchpin identifier Rule 6840 reporting is built around, and its definition, found in Rule 6810 rather than Rule 6840 itself, actually contemplates three distinct scenarios rather than a single universal identifier format. The first and most straightforward form is a unique, persistent identifier for each trading account, with one important restriction: this identifier may not simply be the account number itself, unless the account in question is a proprietary account. The second form applies where an Industry Member's order handling or execution system does not have an account number available at the time of order receipt; in that circumstance, the firm instead uses a unique, persistent relationship identifier, which must itself be masked rather than exposing underlying account details directly. The third form addresses aggregated discretionary trading: where an employee of an Industry Member exercises discretion over multiple client accounts and creates an aggregated order for which no single trading account number is available at the time of origination, the firm uses a unique, persistent entity identifier instead, again unique among all identifiers that specific Industry Member has assigned.
This three-scenario structure reflects CAT's practical need to accommodate genuinely different order-handling workflows across the industry, rather than forcing every firm into an identical account-number-based identification scheme that would not actually work for masked relationship structures or discretionary aggregated trading. A firm's own internal FDID assignment logic needs to correctly identify which of these three scenarios applies to a given order at the moment of receipt or origination, since applying the wrong FDID format, for example using a raw account number where a masked relationship identifier was actually required, itself constitutes a reporting error subject to Rule 6840's correction obligations.
Account Holder Type and FINRA's Consistency Surveillance
Alongside the FDID, Industry Members report an Account Holder Type, or AHT, reflecting the type of beneficial owner associated with a given account, such as an individual customer or a proprietary account. FINRA has built specific, dedicated surveillance tooling around the relationship between these two data elements: the AHT Consistency Interactive Report Card, which examines whether the AHT values a firm reports for a given FDID remain consistent across different CAT record types submitted for the same business day. FINRA's own published guidance illustrates this concretely: if a firm submits a new order event for a given FDID carrying one AHT value, but later submits an execution event for that same FDID carrying a different AHT value, FINRA's tooling flags that inconsistency directly, since a single account should not plausibly shift beneficial ownership classification within the same trading day under ordinary circumstances absent some genuine, documented change in the account's underlying structure.
FINRA's methodology does build in a sensible accommodation: it treats certain AHT codes, specifically those denoting member market maker or proprietary account categories, as a single group for consistency-checking purposes, meaning a firm will not be flagged for inconsistency where the specific AHT value shifts among codes within that grouped category, since these codes all describe substantively similar proprietary-style account relationships. The Report Card examines consistency only within a single business day rather than across multiple days, meaning it will not itself catch a genuine, longer-term drift in how a firm classifies a given FDID's account holder type over time, a limitation firms should factor into their own broader internal quality assurance rather than relying on this tool as a complete solution.
The Large Trader ID Connection
Rule 6840's customer and account reporting framework intersects directly with the SEC's separate Large Trader Reporting Rule, a connection worth understanding as its own distinct regulatory linkage. CAT Reporter firms are required to report all Large Trader IDs, or LTIDs, associated with their reported FDIDs as part of their customer and account reporting obligations, meaning a firm must actually obtain the LTID for each account to the extent one exists rather than treating this as an optional or supplementary data point. Where a firm, typically a clearing firm sitting in a position to observe qualifying trading volume, determines that a particular person would qualify as a large trader under the SEC's rule, but that person has not yet supplied the firm with an actual LTID, the firm must instead assign an Unidentified Large Trader ID, or ULTID, to that person and report the assigned ULTID as part of its CAT customer and account reporting until the genuine LTID becomes available. This obligation places an affirmative burden on clearing firms specifically to make large trader qualification determinations proactively, rather than passively waiting for a customer to self-identify as a large trader and supply the identifier voluntarily.
The 2025 CAIS Amendments and Reduced PII Collection
Rule 6840's underlying data collection scope has continued to narrow, following the same trajectory of reduced personally identifiable information collection discussed in the Rule 6810 entry elsewhere in this dictionary. The CAT NMS Plan's Operating Committee filed an amendment on March 13, 2025, later amended on May 28, 2025, that would eliminate the requirement for Industry Members to report customer names, customer addresses, and years of birth as part of their Rule 6840 reporting for natural persons whose tax identifiers are already reported using the Transformed Value approach, as well as for natural persons without transformed identifiers and for legal entities. The SEC separately issued exemptive relief in 2025 addressing CAIS reporting specifically for what the CAT NMS Plan refers to as Designated Natural Persons, and FINRA issued CAT Alert 2025-02 to guide firms through the reporting alternatives this relief makes available, including the option for firms to continue reporting names, addresses, and years of birth voluntarily even where the underlying requirement to do so has been relieved.
Distinguishing Rule 6840 From Rule 4512
Firms and candidates should take particular care not to confuse Rule 6840's customer reporting obligations with the substantively different, and much older, customer account recordkeeping obligations found in Rule 4512, Customer Account Information. Rule 4512 requires members to maintain a defined set of customer account records, including a customer's name and residence, whether the customer is of legal age, and the identity of associated persons responsible for the account, as part of a firm's general books-and-records obligations under the Exchange Act's broader recordkeeping framework, entirely independent of CAT. Rule 6840, by contrast, exists specifically to feed the Central Repository's own customer identification database and carries its own distinct data elements, deadlines, and correction obligations tied specifically to the CAT NMS Plan. A firm satisfying Rule 4512 does not thereby satisfy Rule 6840, and vice versa; these are two separate, independently enforced obligations that happen to both involve customer-level account information.
What FINRA's Supervisory Guidance Recommends
FINRA's 2026 Annual Regulatory Oversight Report catalogs specific supervisory practices firms should have in place to support both Rule 6840 and the broader CAT reporting framework it feeds into. FINRA has specifically recommended implementing written supervisory procedures requiring a comparative review of actual CAT submissions against a firm's own internal order and trade records, a check that applies with equal force whether the firm submits directly or relies on a third-party submitter to transmit data to CAT on its behalf. FINRA has also recommended daily review of the CAT Reporter Portal, regardless of whether a firm's measured error rate happens to be low on any given day, since a firm that only investigates its Reporter Portal activity when an error rate crosses some internally defined threshold risks missing individually low-frequency but still consequential errors that never accumulate to a rate significant enough to trigger that threshold-based review.
FINRA has further recommended that firms actively use the CAT Report Cards and published CAT FAQs as design inputs for their own supervisory processes, rather than treating these FINRA-provided tools as optional reference material consulted only when a specific question arises. For firms relying on third-party, non-broker-dealer vendors to synchronize business clocks feeding into their CAT reporting, FINRA has recommended obtaining synchronization logs from those vendors on a daily basis and reviewing them specifically to confirm clock drift remains within the acceptable fifty-millisecond threshold discussed in the Rule 6820 entry elsewhere in this dictionary, since a firm's customer and account reporting under Rule 6840 is only as reliable as the underlying timestamp accuracy the rest of its CAT reporting infrastructure depends upon.
Relevance Across FINRA's Exam Programs
The SIE, Series 63, and Series 65 do not test Rule 6840's specific reporting mechanics, since these exams do not reach into CAT's technical customer identification infrastructure. A Series 7 candidate gains only tangential benefit here, mostly in recognizing that customer-level information feeds into FINRA's broader market surveillance capability distinct from the order and execution data covered elsewhere in the CAT rules.
A Series 24 candidate supervising retail or institutional trading operations needs genuine command of Rule 6840's four-part structure and, specifically, its distinct 5:00 p.m. T+3 correction deadline, since conflating this deadline with Rule 6830's 8:00 a.m. T+3 deadline is a realistic, practically consequential error a principal's own compliance review should specifically guard against. A Series 24 candidate at a firm serving as a clearing firm for introducing brokers should also understand the ULTID obligation precisely, given the affirmative large trader determination responsibility it places on clearing firms specifically. A Series 57 candidate handling order entry needs working fluency with the three FDID assignment scenarios, since correctly identifying which scenario applies to a given order at the point of receipt directly determines what identifier format the firm's systems must generate and report.
Practical Guidance for Firms
Firms should build the 5:00 p.m. Eastern Time T+3 correction deadline into their compliance calendars as a genuinely distinct control point from the 8:00 a.m. deadline applicable to Rule 6830 corrections, rather than treating "T+3" as a single, uniform standard across CAT's various reporting streams. A firm's exception-handling workflow should route customer information errors and order/execution data errors through parallel but distinctly timed remediation tracks, given how easily a single unified T+3 tracking system could miss the meaningful time-of-day distinction between these two correction deadlines.
Firms relying on third-party CAT Reporting Agents for customer information submission should specifically confirm, through a written agreement, exactly how FDID assignment logic, AHT classification, and LTID or ULTID determination responsibilities are allocated between the firm and its Reporting Agent, since FINRA's own examination guidance emphasizes the importance of a written agreement specifying respective functions and responsibilities for exception management and error correction. A firm that has not clearly documented this allocation risks a gap where neither the firm nor its Reporting Agent is actually monitoring for a specific category of customer information error, each assuming the other bears that responsibility, a gap that often only becomes visible once FINRA identifies a pattern of uncorrected errors during a routine examination rather than through either party's own proactive monitoring.
Firms should also incorporate FINRA's AHT Consistency Interactive Report Card into their routine CAT quality assurance review, treating flagged inconsistencies as an early warning of a potential FDID or account classification error rather than waiting for a broader examination finding to surface the same underlying problem. Given that the Report Card only examines consistency within a single business day, firms should supplement this tool with their own longer-horizon internal review, specifically checking whether a given FDID's reported AHT classification has drifted gradually over a period of weeks or months in a way the daily-focused Report Card would not itself detect, since gradual drift of this kind can indicate a slow-developing systemic issue in how a firm's account onboarding or classification logic assigns AHT values over time, rather than a one-off data entry error affecting a single account in isolation.
