FAQs

As of August 29, 2019, the Participants conduct activities related to the CAT through Consolidated Audit Trail, LLC, a Delaware limited liability company that is jointly owned by the Participants on an equal basis. The limited liability company agreement of Consolidated Audit Trail, LLC serves as the current CAT NMS Plan.

Prior to August 29, 2019, the Participants conducted the activities related to the CAT through a different Delaware limited liability company, CAT NMS, LLC, which the Participants jointly owned on an equal basis. Prior to August 29, 2019, the limited liability company agreement of CAT NMS, LLC served as the CAT NMS Plan.

The CAT NMS Plan provides that the Consolidated Audit Trail, LLC will be managed by its Operating Committee. Each Participant appoints one member of the Operating Committee and each Participant appointee has one vote. The CAT NMS Plan sets forth certain provisions relating to the Operating Committee, including identification of those actions requiring a Majority Vote, a Supermajority Vote or a unanimous vote, and the management of conflicts of interest.

The CAT NMS Plan requires the establishment of an Advisory Committee charged with advising the Participants on the implementation, operation and administration of the CAT. Under the Plan, the Advisory Committee has the right to attend Operating Committee and Subcommittee meetings (unless they are held in Executive Session) and submit its views prior to a decision by the Operating Committee. The composition of the Advisory Committee includes: (a) broker-dealers of varying sizes and types of business, including a clearing firm; (b) an individual who maintains a securities account; (c) an academic; and (d) institutional investors.

The CAT NMS Plan requires the Consolidated Audit Trail, LLC to appoint a Chief Information Security Officer (CISO) and Chief Compliance Officer (CCO), each of which is an employee of the Plan Processor, reporting directly to the Operating Committee and with fiduciary duties to the Consolidated Audit Trail, LLC. The CISO is David Yacono, and the CCO is Duer Meehan.

The Participants began reporting Participant Data on November 15, 2018.

In light of the SEC’s recent exemptive order, there are new dates by which Large Industry Members (which are Industry Members other than Small Industry Members) are required to begin reporting to the CAT.  Large Industry Members are required to begin reporting Phase 2a Industry Member Data to the CAT by June 22, 2020, and are required to begin reporting Phase 2b Industry Member Data to the CAT by July 20, 2020.   However, Large Industry Members were permitted, but not required, to begin reporting Industry Member Data to the CAT as of April 20, 2020.  Phase 2a Industry Member Data and Phase 2b Industry Member Data are described in detail in the Industry Member Technical Specifications.

In light of the SEC’s recent exemptive order, there are new dates by which Small Industry Members are required to begin reporting to the CAT.  There are two different dates for the commencement of CAT reporting for Small Industry Members with regard to Phase 2a Industry Member Data, depending on whether the Small Industry Member records or reports information to FINRA’s Order Audit Trail System:

•    Small Industry Members that are required to record or report information to FINRA’s Order Audit Trail System pursuant to applicable SRO rules (referred to as “Small Industry OATS Reporters”) are required to begin reporting Phase 2a Industry Member Data to the CAT by June 22, 2020.  

•    Small Industry Members that are not required to record or report information to FINRA’s Order Audit Trail System pursuant to applicable SRO rules (referred to as “Small Industry Non-OATS Reporters”) are required to begin reporting Phase 2a Industry Member Data to the CAT by December 13, 2021. 

All Small Industry Members are required to begin reporting Phase 2b Industry Member Data to the CAT by December 13, 2021.  However, Small Industry Members were permitted, but not required, to begin reporting Industry Member Data to the CAT as of April 20, 2020.  Phase 2a Industry Member Data and Phase 2b Industry Member Data are described in detail in the Industry Member Technical Specifications.

The CAT NMS Plan describes the responsibilities of the Plan Processor for the CAT. Consolidated Audit Trail, LLC has entered into an agreement with FINRA CAT, LLC obligating FINRA CAT, LLC, as the Plan Processor, to perform the functions and duties contemplated by the Plan, including the management and operation of the CAT.

FINRA CAT, LLC, a subsidiary of FINRA, is the Plan Processor for the CAT.

This FAQ has been archived and moved to Archived FAQs.

On September 6, 2023, the Commission approved an amendment to the CAT NMS Plan which established a revised funding model (“CAT Funding Model”) that allocates CAT costs among Participants and Industry Members through the use of executed equivalent share transaction-based fees that will be assessed by CATLLC.  The operation of the CAT Funding Model is described in more detail in the Billing FAQs.

The Plan Processor will provide CAT Reporters access to their submitted data for error correction purposes only.

Yes, the CAT is required to collect SIP and OPRA data. Specifically, the CAT NMS Plan requires that the CAT collect (from a Securities Information Processor (“SIP”) or pursuant to an NMS Plan) and retain on a current and continuing basis, in a format compatible with the Participant Data and Industry Member Data, all data, including the following: (1) information, including the size and quote condition, on quotes, including the National Best Bid and National Best Offer for each NMS Security; (2) Last Sale Reports and transaction reports reported pursuant to an effective transaction reporting plan filed with the SEC pursuant to, and meeting the requirements of, Rules 601 and 608; (3) trading halts, Limit Up/Limit Down price bands and Limit Up/Limit Down indicators; and (4) summary data or reports described in the specifications for each of the SIPs and disseminated by the respective SIP.

No, clearing data is not within the scope of SEC Rule 613 or the CAT NMS Plan.

The CAT NMS Plan requires the Plan Processor to provide the SEC and Participants access to the CAT for regulatory and oversight purposes and to create a method of accessing CAT Data that includes the ability to run complex searches and generate reports. The CAT NMS Plan requires regulator access by two different methods: (a) an online targeted query tool with predefined selection criteria to choose from; and (b) extractions of data via a query tool or language allowing querying of all available attributes and data sources. Appendix D of the CAT NMS Plan sets forth additional requirements concerning regulator access.

The CAT NMS Plan requires that the Plan Processor keep CAT Data online in an easily accessible format for six years.

The CAT NMS Plan requires the CAT to support a minimum of 3,000 regulatory users and at least 600 such users accessing the CAT concurrently without an unacceptable decline in performance.

The CAT NMS Plan requires the Plan Processor to store and retain Raw Data submitted by CAT Reporters. Such Raw Data will be available to the SEC and Participants for regulatory purposes.

The CAT NMS Plan requires the Participants to submit rule filings to eliminate or modify any rules or systems that would be redundant of the CAT. In May 2017, certain Participants filed with the SEC rule filings to eliminate or modify certain redundant rules and systems, including rule filings related to FINRA’s Order Audit Trail System (“OATS”) and the Electronic Blue Sheets (“EBS”). In light of the delay in the commencement of CAT reporting, these rule filings were withdrawn. In August 2020, FINRA filed with the SEC a proposed rule change to eliminate the OATS Rules once members were effectively reporting to the CAT. The filing states that the proposed rule change only addresses the elimination of the OATS Rules and that amendments to the EBS Rules would be subject to a separate FINRA rule filing made in conjunction with SEC rulemaking to amend Rule 17a-25 under the Exchange Act. FINRA removed the OATS Rules on September 1, 2021 and retired the system on September 16, 2021 (See Regulatory Notice 21-21). 

The CAT NMS Plan requires the appointment of an appropriately qualified Independent Auditor of national recognition, subject to the approval of the Operating Committee by Supermajority Vote. Among other things, the Independent Auditor, in collaboration with the CCO, is required to create and implement an annual audit plan (subject to the approval of the Operating Committee) which shall at a minimum include a review of all Plan Processor policies, procedures and control structures.

Additionally, data centers housing CAT Systems (whether public or private) must, at a minimum, be AICPA SOC 2 certified by a qualified third-party auditor that is not an affiliate of any of the Participants or the Plan Processor. The frequency of the audit must be at least once per year.

This FAQ has been archived and moved to Archived FAQs.

Yes, Small Industry Non-OATS Reporters may voluntarily choose to begin reporting prior to December 2021, the date on which Small Industry Non-OATS Reporters are required to begin reporting to the CAT. However, if a Small Industry Non-OATS Reporter begins reporting at such earlier date, (1) it must report all CAT Data required to be reported by Industry Members in accordance with the CAT Compliance Rules, the CAT NMS Plan and the Industry Member Technical Specifications, as if it were required to report such CAT Data; and (2) it may not cease to report to the CAT once it begins reporting to the CAT.

According to each of the Participant’s CAT compliance rules, information required to be reported to the CAT must be maintained in accordance with SEC Rule 17a-4(b). This rule states that these records must be preserved for at least three years, the first two years in an accessible place. Records are not required to be retained in an electronic format; they may be retained in a paper format. However, with respect to Business Clock synchronization logs, such logs must include synchronization results for a period of not less than five years ending on the then current date, or for the entire period for which the Industry Member has been required to comply with this requirement if less than five years.

No. Although data is permitted to be transmitted to CAT at any time, including during or after market hours, subject to certain deadlines, it is not required to be submitted in real-time.

No, primary market transactions, as defined in Section 1.1 of the Plan, are not subject to CAT reporting. The Participants analyzed whether to include primary market transactions in the CAT, and concluded doing so was premature and that such an analysis would benefit from actual experience with the CAT. See Discussion of the Potential Expansion of the Consolidated Audit Trail Pursuant to Section 6.11 of the CAT NMS Plan (May 15, 2017) (available at Expansion Report).

Starting in Phases 2a (equities) and 2b (options), orders received or originated prior to the date on which an Industry Member is required to begin reporting to the CAT and any subsequent events related to such orders, including those occurring on or after the required reporting date, are not required to be reported to the CAT. However, Industry Members may submit to the CAT events related to orders received or originated prior to the required reporting date and they will not be rejected.

For Phase 2a/2b reporting, if an Industry member chooses to optionally report subsequent events related to such orders, the orderKeyDate field must be populated with a date prior to the date on which the Industry Member is required to begin reporting to CAT, and the Industry Member will receive a warning that the Order Key references a date prior to CAT go-live. If the Industry Member populates the orderKeyDate field with a date on or after the date on which the Industry Member is required to begin reporting to CAT, the Industry Member will receive an error that the Order Key is not found.

For Phase 2a/2b reporting, if the sending firm chooses not to report the activity, but the receiving firm reports an MEOA to CAT, both parties will receive a linkage error as the CAT Plan Processor would have no way to distinguish that the original order was received by the receiving firm prior to CAT go-live. In this case, both parties that received an error should contact the FINRA CAT Help Desk. Industry Members should note that this issue will only impact CAT Reportable Events for orders received prior to the start of CAT reporting (June 22, 2020 for equities and July 20, 2020 for simple electronic options), which are routed on or after the date when interfirm linkage processing becomes effective (July 27, 2020 in Industry Test Environment and August 10, 2020 in the Production Environment).

Starting in Phase 2c, for orders that originated/generated prior to April 26, 2021 and that remain open on April 26, 2021, Industry Members would be required to report any subsequent events in accordance with applicable Phase 2c reporting requirements. For example, if a trailing stop order received on March 3, 2021 remains open on April 26, 2021, then the Industry Member would be required to report an Order Effective event when all underlying conditions are met (e.g., the trailing stop is triggered) in accordance with Phase 2c requirements instead of via an Order Modified event (MEOM), as was required in Phase 2a. (See FAQ B62 for information related to the reporting requirements for Trailing Stop and Trailing Stop Limit orders.)

Starting in Phase 2d, for orders that originated/generated prior to December 13, 2021 and that remain open on December 13, 2021, Industry Members would be required to report any subsequent events in accordance with applicable Phase 2d reporting requirements. For example, on December 14, 2021, a customer requests a modification or cancellation to a GTC order that was originally generated on October 5, 2021. In this example, the Industry Member must also capture the time that the cancellation or modification request was received from the customer either in the requestTimestamp field in the Order Modified event (MEOM) or Order Cancelled event (MEOC), as applicable, or in separate Order Modification Request event (MEOMR) or Order Cancel Request event (MEOCR), as outlined in the Reporting Technical Specifications for Industry Members document.

For orders that remain open on or after December 13, 2021, and that were not required to be reported prior to Phase 2d, then the subsequent events associated with such orders are not required to be reported if the primary event(s) associated with such activity was not reportable prior to Phase 2d. The Industry Member may choose to optionally report such secondary events to the CAT, but must populate the orderKeyDate field with a date prior to December 13, 2021, and the Industry Member will receive a warning that the Order Key references a date prior to CAT go-live. If the Industry Member populates the orderKeyDate field with a date on or after December 13, 2021, then the Industry Member will receive an error that the Order Key is not found.

For example, a Multi-Leg Order was generated on December 9, 2021and was not required to be reported to CAT prior to Phase 2d. The order remains open on December 14, 2021, when the Industry Member routes the Multileg Order to an exchange. The route is not required to be reported, as it relates to an order that was originated/generated and not reportable prior to Phase 2d. The Industry Member may optionally choose to report the route to an exchange via the Multi-Leg Order Route event (MLOR), but must populate the orderKeyDate field with December 9, 2021, the Order Key of the primary event which is being routed. The same guidance would apply to any other subsequent events on the multi-leg order.

Industry Member testing for Phase 2a of CAT reporting is scheduled to begin in December 2019.

If an Industry Member CAT Reporter employs a Series 24 Registered Principal, then that Registered Principal must be named on the CAT Registration Form. However, if an Industry Member CAT Reporter does not employ a Series 24 Registered Principal and instead employs one or more Limited Principals (e.g., Series 26), then the Industry Member CAT Reporter should name a Limited Principal on the CAT Registration form.

On April 20, 2020, the Commission granted the Participants’ request to exempt broker-dealers that do not qualify as Small Industry Members solely because they satisfy Rule 0-10(i)(2) under the Exchange Act and, as a result, are deemed affiliated with an entity that is not a small business or small organization (“Introducing Industry Member”) from the requirements in the CAT NMS Plan applicable to Industry Members other than Small Industry Members (“Large Industry Members”).  Instead, such Introducing Industry Members would comply with the requirements in the CAT NMS Plan applicable to Small Industry Members.  In light of this exemptive relief, a Small Industry Member would be defined as an Industry Member that qualifies as a small broker-dealer as defined in Rule 0-10(c) under the Securities Exchange Act of 1934, as amended, without reference to Rule 0-10(i)(2) for purposes of Rule 0-10(c)(2).

Rule 0-10(c) under the Exchange Act states that the term small business or small organization shall,

[w]hen used with reference to a broker or dealer, mean a broker-dealer that:

• 1. Had total capital (net worth plus subordinated liabilities) of less than $500,000 on the date in the prior fiscal year as of which its audited financial statements were prepared pursuant to § 240.17a-5(d) or, if not required to file such statements, a broker or dealer that had total capital (net worth plus subordinated liabilities) of less than $500,000 on the last business day of the preceding fiscal year (or in the time that it has been in business, if shorter); and
• 2. Is not affiliated with any person (other than a natural person) that is not a small business or small organization as defined in this section. 

Rule 0-10(i) under the Exchange Act further states that

[f]or purposes of paragraph (c) of this section, a broker or dealer is affiliated with another person if:

• 1. Such broker or dealer controls, is controlled by, or is under common control with such other person; a person shall be deemed to control another person if that person has the right to vote 25 percent or more of the voting securities of such other person or is entitled to receive 25 percent or more of the net profits of such other person or is otherwise able to direct or cause the direction of the management or policies of such other person; or
• 2. Such broker or dealer introduces transactions in securities, other than registered investment company securities or interests or participations in insurance company separate accounts, to such other person, or introduces accounts of customers or other brokers or dealers, other than accounts that hold only registered investment company securities or interests or participations in insurance company separate accounts, to such other person that carries such accounts on a fully disclosed basis.

No. A firm is a Small Industry Member for purposes of reporting to CAT if its total capital is less than $500,000 on the date on which its audited financial statements were prepared. If the firm’s total capital subsequently exceeds $500,000 prior to the Small Industry Member implementation deadline of December 2021, the firm is not required to begin reporting as a Large Industry Member; rather, the firm must still comply with the Small Industry Member reporting deadline. Please see FAQ A29 for additional information on what broker-dealers are considered “Small Industry Members” for purposes of reporting to the CAT.

No.  Mandatory CAT reporting for Industry Members does not commence until June 22, 2020 (with regard to Phase 2a Industry Member Data) and July 20, 2020 (with regard to Phase 2b Industry Member Data), as described above in FAQ A6 and A7.  The exchanges and FINRA have indicated that they will not commence enforcement of their CAT Compliance Rules with regard to Industry Member CAT reporting until these reporting compliance dates.  The exchanges and FINRA, however, will continue to enforce CAT Compliance Rules other than those related to Industry Member CAT reporting prior to these reporting compliance dates.  For example, while Industry Members have been required to, and will continue to be required to, synchronize their Business Clocks, Industry Members will not be required to report clock synchronization violations related to Reportable Events until the compliance dates for mandatory CAT reporting.

Firms that meet the definition of a Small Industry Member and do not report to OATS have a CAT reporting obligation beginning on December 13, 2021, which is simultaneous to the commencement of Phase 2d. As such, Small Industry Members that do not report to OATS and plan to start reporting on December 13, 2021 should code their CAT reporting systems to the Phase 2d CAT Reporting Technical Specifications for Industry Members. Small Industry Members that choose to report early must code to the version of the Technical Specifications effective at the time the Small Industry Member begins reporting. 

No, order events occurring prior to an IPO symbol’s inclusion on the CAT Reportable Securities List are not required to be reported to CAT in Phases 2a/2b/2c. In Phases 2a/2b/2c, secondary events that occur after an IPO symbol’s inclusion on the CAT Reportable Securities List that are reported to CAT and are marked unlinked for parent not found will not be considered a CAT Reporting violation if at the time of the parent event, the symbol was not on the CAT Reportable Securities List.

Guidance for reporting order events occurring prior to an IPO symbol’s inclusion on the CAT Reportable Securities List in Phase 2d is still under consideration. The participants intend to make any necessary filings in order to defer this activity to Phase 2d. 
 

The CAT NMS Plan requires Industry Members to “submit to the Central Repository” information  “including CRD number and LEI, if such LEI has been obtained.” “Central Repository” means the repository responsible for the receipt, consolidation, and retention of all information reported to the CAT pursuant to SEC Rule 613 and this Agreement. 
 
The CAT NMS Plan requirement does not require Industry Members to obtain an LEI, but rather to provide its LEI to the Plan Processor (FINRA CAT) if the Industry Member does have an LEI. 

The collection of the Industry Member’s LEI via the CAIS Registration Form and CAT Registration Form (Transaction Reporting) is separate from the reporting of customer account LEI data requirements.(For additional information pertaining to the LEI for customer accounts, see FAQs Q1 and Q4).

Yes, market maker quotes are required to be reported to the CAT. Under the CAT NMS Plan, an Options Market Maker’s quotes in Listed Options will be reported to the CAT by the relevant Options Exchange in lieu of reporting by the Options Market Maker. Options Market Makers will not need to separately report these quotes, although they will be required to report to the Options Exchange the time at which a quote in a Listed Option is sent to the Options Exchange (and, if applicable, the time of any subsequent quote modification and/or cancellation where such modification or cancellation is originated by the Options Market Maker). The Options Exchanges are required to report such time information to the CAT in lieu of reporting of such time information by the Options Market Markers to the CAT. Equity market makers, however, are required to report their quotes to the CAT themselves.

Except as otherwise provided, the CAT NMS Plan requires CAT Reporters to report CAT Data to the CAT in milliseconds. To the extent that a CAT Reporter’s order handling or execution systems utilize timestamps in increments finer than milliseconds, then such CAT Reporter is required to utilize such finer increments up to nanoseconds when reporting CAT Data to the CAT.  CAT Reporters that capture timestamps in increments more granular than nanoseconds are required to truncate the timestamps after the nanosecond level--and must not round up or down--for submission to CAT.

No, neither IOIs nor RFQs are reportable to CAT, as neither falls within the definition of an "order" as set forth in the CAT NMS Plan. For CAT purposes, an IOI is a non-firm expression of trading interest that contains one or more of the following elements: security name, side, size, capacity and/or price. 

No. CAT Reporters are not required to record and report information related to non-Eligible Securities to the CAT. CAT Reporters only are required to report information related to Reportable Events in Eligible Securities – that is, NMS Securities and OTC Equity Securities. (See Section 1.1 of the CAT NMS Plan (definition of Eligible Security) available at SEC Approved CAT NMS Plan (11/15/2016))

No, only CAT Reporters that are ATSs are required to submit NBBO information to the CAT. Specifically, ATSs would be required to report certain NBBO information upon the receipt and execution of an order. 

No. CAT Reporters are not required to report to the CAT quotes received via subscriptions to receive market data from market data vendors. Under Sections 6.3(d)(iii) and 6.4(d)(i) of the CAT NMS Plan, CAT Reporters are required to report certain data to the CAT “for the receipt of an order that has been routed.” Although such quotes may fall within the definition of an “order” under the CAT NMS Plan (and SEC Rule 613(j)(8)) as “bids” and “offers,” such quotes have not been routed to the CAT Reporter, and therefore, not subject to the reporting requirement.

This FAQ has been archived and moved to Archived FAQs.

To the extent that any Industry Member’s order handling or execution systems utilize timestamps in increments finer than milliseconds for a given Reportable Event, such Industry Member shall record and report that Reportable Event to the CAT with timestamps in such finer increment up to nanoseconds. To the extent that an Industry Member has order handling or execution systems that utilize timestamps with varying increments, the Industry Member shall use the timestamps associated with each relevant system and Reportable Event when reporting CAT Data to the Central Repository, provided that in all instances such timestamps meet the minimum requirement of one millisecond for non-Manual Order Events.

No. Industry Members only are required to report the “details for each order and each Reportable Event, as applicable,” as set forth in Section 6.3(d) of the CAT NMS Plan, as applied to Industry Members by Section 6.4(d)(i) of the CAT NMS Plan. The definitions of “orders” and “Reportable Events” are set forth in Section 1.1 of the CAT NMS Plan. If a message in an order routing protocol does not meet the definition of an order or a Reportable Event, then details related to that message do not have to be reported to the CAT. For additional information on reporting to the CAT, please see the CAT Reporting Technical Specifications for Industry Members. 

CAT will accept reports involving fractional shares; please refer to the Industry Member Technical Specifications for additional details.

Industry Members will be required to report to the CAT details for each Order and Reportable Event involving an Eligible Security. Under the CAT NMS Plan, “Eligible Security” includes: (1) all NMS Securities, meaning “any security or class of securities for which transaction reports are collected, processed, and made available pursuant to an effective transaction reporting plan, or an effective national market system plan for reporting transactions in Listed Options”; and (2) all OTC Equity Securities, meaning “any equity security, other than an NMS Security, subject to prompt last sale reporting rules of a registered national securities association and reported to one of such association’s equity trade reporting facilities.” While the CAT NMS Plan does not define “prompt last sale reporting rules,” the Operating Committee has determined that transactions in restricted securities (as defined by SEC Rule 144(a)(3)) are not reportable to CAT because they are not subject to prompt last sale reporting rules. However, transactions in direct participation programs (DPPs) must be reported to CAT in Phase 2c of Industry Member reporting. FINRA CAT, LLC, the Plan Processor for the CAT, will publish daily lists of Eligible Securities.

The reporting obligation for the equity legs of complex orders beginning in Phase 2a is as follows. If a complex order includes an equity leg and the terms and conditions of the order are contingent upon the related option trade, the equity leg must be reported using the handlingInstructions value of ‘OPT’ starting in Phase 2a. This reporting obligation applies regardless of whether the complex order is split or not split into components.

Specifically, for a complex order that is routed or received as a complex order and not split into its constituent equity and option legs, the Industry Member must report the equity leg to the CAT in Phase 2a with the ‘OPT’ handlingInstructions value. For a complex order that is routed or received as a complex order and then split into its constituent equity and option legs and routed, the Industry Member must report the equity leg to the CAT in Phase 2a with the ‘OPT’ handlingInstructions value.

In Phases 2a and 2c, if the complex order contains a net price, Industry Members may report the receipt and route of the equity leg as either a market order, or as a limit order with a price of ‘0’ in accordance with FAQ B58 so long as the handlingInstructions field is populated with a value of ‘OPT’ (refer to FAQ E13 for additional information regarding the handlingInstructions requirements on Order Route events for the equity leg of a complex order). In Phases 2a and 2c, CAT will interpret the combination of a market order with a handlingInstructions value of ‘OPT’, or a limit order with a price of ‘0’ and a handlingInstructions value of 'OPT' as an order with a net price. In Phase 2d, a net price will be required. Refer to the Industry Member Reporting Scenarios document for additional information.

Industry Members will be required to report any simple option leg of a complex order in Phase 2b if the complex order has been split and is being worked as individual legs. Industry Members will be required to report complex orders that include both equity and option components to the CAT in Phase 2d. These reporting obligations apply to both FINRA and non-FINRA members that are Industry Members.

Any broker-dealer that is a member of a national securities exchange or FINRA and receives, originates and/or handles orders in NMS Securities, which includes NMS stocks and Listed Options, and/or OTC Equity Securities must report to CAT. There are no exemptions for any such broker-dealer for any reason.

Because the RIA is part of the same legal entity as the US registered broker-dealer, orders received or originated by the RIA are subject to all applicable CAT reporting rules and the US registered broker-dealer must report to CAT all orders that the RIA receives or originates. If the RIA were a separate legal entity that was not a member of a US registered broker-dealer, the RIA would not have an obligation to report orders originated and routed by the RIA to the CAT (also see FAQ B55).

No. The CAT NMS Plan is independent from SEC Rule 17a-3 and does not replace or otherwise alter Rule 17a-3 or any other SEC rules.

Yes. Any broker-dealer that is a member of a national securities exchange or FINRA and receives and/or handles orders in NMS Securities, which includes NMS stocks and Listed Options, and/or OTC Equity Securities – regardless of whether they operate in a foreign country — must report to CAT and satisfy clock synchronization requirements.

No. The CAT NMS Plan does not require CAT Reporters to maintain data submitted to CAT in the CAT format. CAT Reporters are required to retain the data in a format that it could be retrieved and provided to an SRO or the SEC upon request. CAT Reporters are not required to store the data in an electronic system; it could be stored in a manual format.

Market makers are subject to the same reporting requirements as any other Industry Member depending on the type of order received and how it was handled. There are no carve outs or exemptions for orders received or originated by a market maker.

No. An IOC order, by definition, is subject to an immediate partial or full execution. Otherwise, it is automatically partially or fully cancelled. An FOK order, by definition, is subject to either an immediate execution or immediate cancellation. Therefore, it is not necessary to submit to CAT a Cancel Event for an unexecuted order with instructions to be handled as IOC or FOK.

As a general matter, a broker-dealer is considered to be the executing broker in any transaction where its client (either a customer or broker-dealer client) is only able to effect the trade by virtue of the firm’s membership with the applicable market center. Thus, if a client would not be able to effect trades without the firm’s SRO membership, the firm providing the sponsored or direct market access is considered to have received an order from its client and routed it to the market center to which it provides access for the client. Accordingly, such orders must be reported to CAT by the firm providing such access.

When an Exchange for Physical order has been received or originated, a New Order event must be reported with a handlingInstructions value of ‘EW’. If the transaction is affected through an ATS or other crossing system, an Order Route event must be reported by the sender, and an Order Accepted event must be reported by the receiver. If the order is executed via a direct negotiation with the counterparty, the Industry Member must follow the guidance outlined in the Industry Member Scenarios Document for reporting a negotiated trade. If an EFP transaction was originated in response to solicitation, the guidance outlined under B45 would apply.

With respect to the Industry Members’ reporting obligations, when two broker-dealers have entered into a sponsored access agreement whereby one broker-dealer sponsors the other broker-dealer into a specific market center (such as a national securities exchange) by providing use of the sponsoring broker-dealer’s SRO-assigned identifier, both broker-dealers have separate and distinct CAT reporting obligations. For example, if BD A sponsors access into a national securities exchange for BD B, the CAT reporting obligation for each broker-dealer would be as follows:

Sponsored Broker-Dealer BD B (under the SRO-assigned identifier of BDBB)
New Order Event
Order Route Event indicating order was routed to BDA

Sponsoring Broker-Dealer BD A (under the SRO-assigned identifier of BDAA)
Order Accepted Event indicating the order was received from BDBB
Order Route Report indicating order was routed to a national securities exchange

The CAT reporting obligations outlined above are the same regardless of the type of connection used by the sponsored broker-dealer to access the applicable market center. For example, the CAT reporting obligations for each broker-dealer would be the same whether the sponsored broker-dealer used a direct market connection provided by the sponsoring broker-dealer, a third party service provider connection provided by the sponsoring member, or its own proprietary connection to the subject market center.

Industry Members must use the "proxy price" format established by Nasdaq, and not the final trade price, when reporting orders for ETMFs to CAT. 

A. No. These codes apply to ATSs and are not required to be reported by non-ATSs. However, CAT will not prevent the reporting of such codes by a non-ATS.

Proprietary trading firms are subject to the CAT NMS Plan and SEC Rule 613. As such, proprietary trading firms that originate orders and route them out to other market centers have an obligation to report the origination of the order as a New Order Event (MENO) and the Route of the order as a Route Event (MEOR). Additionally, such firms are required to report any other related events in accordance with the CAT Reporting Technical Specifications for Industry Members.

A. No.  All CAT Reporters are required to obtain an SRO assigned identifier for the purposes of reporting IMIDs to CAT.

CAT will accept files 24 hours a day, 7 days a week. Reports for events that occur during a particular Trading Day must be reported by 8:00 a.m., ET the following Trading Day or they are marked late by CAT.

All timestamps submitted in STRING format must be reported to CAT in Eastern Time. Timestamps submitted in UTC must not be adjusted for Eastern Time. For additional information, refer to the CAT Reporting Technical Specifications for Industry Members.

An order submitted by a customer who gives the broker discretion as to the price and time of execution is denoted as a "Not Held" order. For CAT, the definition of a "trader" in the context of a "Not Held" order is extended to the broker.

No."DAY" orders that remain unexecuted at the close of a market day are assumed to be canceled and no Cancel Event is required.

Adjustments to orders as the result of a corporate action are not required to be reported to CAT; however, if an order is canceled as a result of a corporate action, you must report the cancellation to CAT via a Cancel Event.

CAT allows for the reporting of fractional shares in decimal format. In this example, the share quantity for the New Order Event should be 100.5, the Order Route Event should be 100, and the share quantity on the Trade Event for the fractional principal execution should be 0.5.

If the Leaves Quantity totals a fractional number of shares, it may be reported in decimal format. For example, a Leaves Quantity of 500-1/2 shares should be reported as “500.5”.

A New Order or Order Accept Event and an Order Canceled Event are required to be reported.

Yes. All proprietary orders originated in the normal course of market making are reportable to CAT.

All prices must be in decimal format. The price fields are 18 numeric characters (including 8 decimal places). A price is not required to contain all 18 characters. In any price, no more than 9 characters can appear without a decimal and no more than 8 characters can appear after the decimal. For example, the following prices are valid: “125”, “000000125”, “000000125.00000000”. Any price that contains more than 18 characters, 9 characters before a decimal, or 8 characters after a decimal will be rejected.

Buy-ins required by SEC or SRO rules (e.g., to comply with the close out requirements of Regulation SHO or FINRA Rule 4320, or the buy-in requirement of SEA Rule 15c3-3) must be reported to CAT using the Buy-In handlingInstructions value (BIN).  

Buy-ins originated pursuant to Regulation SHO or applicable SRO rules (e.g., FINRA Rule 4320), whether executed or unexecuted, must be reported by the clearing firm as a proprietary order of the clearing firm with the FDID of the clearing firm’s proprietary account in which the buy-in originated. The order must be reported with the ‘BIN’ handlingInstructions value to indicate the order represents a buy-in. If the clearing firm allocates the buy-in responsibility to a correspondent broker-dealer pursuant to Regulation SHO or applicable SRO Rules (e.g., FINRA Rule 4320(c)), the correspondent broker-dealer must report the buy-in as a proprietary order with the FDID of the correspondent firm’s proprietary account in which the buy-in occurred. The order must be reported with the 'BIN' handlingInstructions to indicate the order represents a buy-in.
 

No. The changes to Rule 606 do not modify what is reportable to CAT. Under the CAT, broker-dealers must determine whether trading interest falls within the definition of “order” for CAT purposes. As noted in CAT FAQB3, for CAT purposes, an IOI is a non-firm expression of trading interest that contains one or more of the following elements: security name, side, size, capacity and/or price. If trading interest is firm, that trading interest is reportable under CAT (regardless of how it is labeled).

No. Journals and other non-trading, internal position transfers between accounts within the same legal entity generally are not reportable, as they do not involve the receipt or origination of an order or a bid or offer under Rule 613(j)(8), or other Reportable Event. However, position transfers are subject to applicable SRO rules, and if an exchange rule requires a position transfer to be transacted on an exchange, orders originated to effect a transfer and related Reportable Events would be reportable to CAT. In addition, while position transfers within the same entity generally are not reportable to CAT, the origination and internal routing of an order by one part of an Industry Member to a different desk or department for subsequent handling and any related Reportable Events are reportable to CAT.

Under CAT, Industry Members must determine whether trading interest falls within the definition of an “order” for CAT purposes. Specifically, CAT Reporters must consider the definition of an order under Exchange Act Rule 613(j), and any related SEC guidance. As stated in FAQs B3 and B38, non-firm expressions of trading interest that contain one or more of the following elements: security name, side, size, capacity and/or price, are not reportable to CAT. Thus, a key consideration in determining whether trading interest is reportable to CAT is whether it is firm. For example, certain trading interest, sometimes referred to as “conditional orders,” available on some alternative trading systems (ATSs) must have their terms and conditions “firmed up” or otherwise confirmed by the sender before they can be executed against a potential contra-side. Such trading interest would not be reportable to CAT by either the sender or the receiving ATS until it was firmed up/confirmed by the sender. The conditional order becomes reportable once it is firmed up/confirmed and the time of receipt/origination for the sender would be the time the order was firmed up/confirmed by the sender and the time of receipt for the ATS would be the time the ATS receives the firmed up/confirmed order from the sender.

If an Industry Member receives an order and executes the order from the Industry Member’s inventory in one of its proprietary accounts, in whole or in part, rather than through the generation of a proprietary order, the Industry Member will not be required to record and electronically report to the Central Repository the origination of a proprietary order pursuant to Section 6.3(d)(i) as applied to Industry Members by Section 6.4(d)(i). Instead, when the Industry Member reports the execution of the order pursuant to Section 6.3(d)(i)(v) as applied to Industry Members by Section 6.4(d)(i), the Industry Member will record and electronically report to the Central Repository: (1) the Firm Designated ID of the proprietary account; and (2) the account type of the proprietary account. If, however, the Industry Member generates a proprietary order to execute against the order, then the Industry Member would be required to report to the CAT a new order report for the proprietary order.

Industry Members are not required to report an Order Modification Request or Order Cancel Request event to CAT to the extent the order is terminal at the time of the request (i.e., the order has already been fully executed or cancelled) in Phase 2d. This activity may be required in future phases of CAT. 

However, starting in Phase 2d, Industry Members must report a Route Modified (MEMR) or Route Cancelled (MECR) event if the Industry Member modifies or cancels a route. If the route modification or cancellation is rejected by the destination venue, the Industry Member must also populate the routeRejectedFlag with ‘true’. The Industry Member may alternatively report a Route Modified Supplement (MEMRS) or Route Cancelled Supplement (MECRS) event with the routeRejectedFlag populated with ‘true’.

Additionally, if a modification or cancellation request was received that was too late to modify/cancel, and the order was not terminal (e.g., the order was “in-flight” and the sending Industry Member did not receive a modification/cancellation confirmation), the request must be reported as an Order Modification/Cancellation Request event.
 

No. In accordance with the SEC’s July 28, 2023 order granting a temporary conditional exemption relating to the reporting of certain on and off (including in the over-the-counter market) floor activities, Industry Member CAT Reporters are not required to report the following during Phases 2a, 2b, 2c or 2d: (1) floor broker verbal announcements of firm orders on an exchange that are otherwise reported as systematized orders; (2) market maker verbal announcements of firm quotes on an exchange trading floor; (3) telephone discussions between an Industry Member and a client that may involve firm bid and offer communications; and (4) unstructured electronic and verbal communications that are not currently captured by Industry Member order management or execution systems. 

However, this verbal and manual activity will be required to be reported in future phases of CAT, as the SEC’s order expires on July 31, 2026. See CAT FAQ C-7 for additional information on orders considered “manual” or “electronic” for purposes of reporting to the CAT.
 

The answer is divided into two sections: one section for verbal or manual bids or offers and one section for electronic bids or offers.

• 1. Verbal and Manual Bids and Offers: As stated in FAQ B43, pursuant to the SEC’s July 28, 2023 order granting a temporary conditional exemption, verbal or manual quotes on an exchange floor or in the over-the-counter market are not reportable during Phases 2a, 2b, 2c or 2d. However, this activity will be required to be reported in future phases of CAT, as this temporary exemptive relief expires on July 31, 2026. See CAT FAQ C-7 for additional information on orders considered “manual” or “electronic” for purposes of reporting to the CAT. The CAT reporting requirements for verbal and manual quotes for later phases remains under discussion by the SROs.
• 2. Electronic Bids and Offers: Electronic quotes which are provided by or received in a CAT Reporter’s order/quote handling or execution systems in CAT reportable securities and are provided by an Industry Member to other market participants off a national securities exchange are reportable in Phase 2d for both equities and options under these three conditions:
  • a) An equity bid or offer is displayed publicly or has been communicated (1) for listed securities to the Alternative Display Facility (ADF) operated by FINRA; or (2) for unlisted equity securities to an “inter-dealer quotation system” as defined in FINRA Rule 6420(c);
    
    There are a few important notes about quotes in OTC Equity Securities:
    • i. OTC Equity Securities quotes which are received by an Industry Member CAT Reporter operating an inter-dealer quotation system are reportable in Phase 2a by the operator of the inter-dealer quotation system.
    • ii. OTC Equity Securities quotes sent by an Industry Member to an inter-dealer quotation system operated by an Industry Member CAT Reporter are reportable by the Industry Member sending them in Phase 2d.
    • iii. OTC Equity Securities quotes sent by an Industry Member to a quotation venue not operated by an Industry Member CAT Reporter or SRO are reportable in Phase 2a by the Industry Member. Note that as of this writing, the Participants are not aware of the operation of any such quotation venue.
       
  • b) Or, an equity bid or offer which is accessible electronically by customers or other market participants and is immediately actionable for execution or routing; i.e., no further action is required by the market participant providing the quote before a trade or route can occur.
  • c) Or, a listed option bid or offer which is accessible electronically by customers or other market participants and is immediately actionable for routing to another broker-dealer or to an exchange or exchange floor for execution/representation; i.e., no further action is required by the market participant providing the quote before routing to another broker-dealer or an exchange or exchange floor can occur.

Note that as stated in FAQ B6, CAT Reporters are not required to report to the CAT quotes received via subscriptions to receive market data from market data vendors.

As stated in FAQ B44, any equity bid or offer that is accessible electronically by customers or other market participants and is immediately actionable (i.e., no further manual or electronic action is required by the responder providing the quote in order to execute or cause a trade to be executed) is reportable starting in Phase 2c; and any listed option bid or offer which is accessible electronically by customers or other market participants and is immediately actionable (i.e., no further action is required by the responder providing the quote in order to execute or cause a trade to be executed ) is reportable starting in Phase 2d. Accordingly, any response to an RFQ or other form of solicitation response provided in a standard electronic format (i.e. FIX) that meets this definition would be reportable starting in Phase 2c for equities and Phase 2d for options.

Responses communicated in standard electronic format are reportable by both the CAT Reporter issuing the RFQ or solicitation (solicitor) and the CAT Reporter responding to the RFQ or solicitation (responder). Specifically, the solicitor must report the receipt of all responses, even those that were not ultimately selected. 

It is important to note that regardless of the form (electronic or manual) of any RFQ or solicitation response, all orders received or originated as the result of such RFQ or solicitation process must be reported as set forth in the CAT Reporting Technical Specifications for Industry Members. For equities, both manual and electronic orders must be reported starting in Phase 2a. For options, simple, electronic orders must be reported starting in Phase 2b and all other orders, including manual, complex and paired orders, are reportable starting in Phase 2d.

Example 1:

A CAT Reporter issues an RFQ through a 3rd party vendor RFQ platform not operated by a broker-dealer. In response to the RFQ, multiple CAT Reporters respond by sending FIX messages directly to the requesting CAT Reporter. Upon selection of a response (either by the trader or automatically by the firm’s trading system), the FIX order from the winning bidder is executed (manually or electronically) OR is routed (manually or electronically) to another broker-dealer or exchange for execution without any further action required by the winning bidder.

The electronically provided responses are reportable by all bidders, even those that were not selected, starting in Phase 2c for equities and Phase 2d for options. Further, the CAT Reporter that issued the RFQ would report the receipt of all responses, as well as any subsequent actions taken to process the order starting in Phase 2a for equities, Phase 2b for simple, electronic orders and Phase 2d for all other options orders.

Example 2:

A CAT Reporter issues an RFQ and receives several quotes in response through a 3rd party vendor RFQ platform not operated by a broker-dealer. Upon selection of a response, the CAT Reporter either:

• initiates and routes an order electronically to the winning bidder,
• the RFQ platform automatically sends a routed order to the winning bidder, or
• the winning bidder has standing instructions to create a new order acceptance once it receives a message from the RFQ platform that it has won.

Because the RFQ responses were sent through an RFQ platform and not via standard electronic format directly to the solicitor/CAT Reporter, none of the responses are reportable in 2c.

However, the origination of the new order by the solicitor/CAT Reporter, the route of that new order to the winning bidder, and the acceptance of that order by the winning bidder are all reportable events in the phase that order would otherwise become reportable. The solicitor/CAT Reporter would report the new order and route events; the winning bidder would report the order acceptance, as well as any subsequent actions taken to process the order.

Example 3

A CAT Reporter issues an RFQ through a 3rd party vendor RFQ platform not operated by a broker-dealer. In response to the RFQ, multiple CAT Reporters respond by sending FIX messages directly to the requesting CAT Reporter’s OMS. Upon selection of a response, the solicitor CAT Reporter either:

• initiates and routes an order electronically to the winning bidder,
• the RFQ platform automatically sends a routed order to the winning bidder, or
• the winning bidder has standing instructions to create a new order acceptance once it receives a message from the RFQ platform that it has won.

Although the RFQ responses were sent via standard electronic format directly to the solicitor/CAT Reporter’s OMS/EMS, the responses are not reportable in Phase 2c because the CAT Reporters sending the responses would be required to take additional action by accepting a separate order from the requestor before any execution can occur, and would therefore not be considered immediately actionable.

However, the origination of the new order by the solicitor/CAT Reporter, the route of that new order to the winning bidder, and the acceptance of that order by the winning bidder are all reportable events in the phase that order would otherwise become reportable. The solicitor/CAT Reporter would report the new order and route events; the winning bidder would report the order acceptance, as well as any subsequent actions taken to process the order.

Example 4

An Asset Manager (non-CAT Reporter) issues and receives several quotes in response through a 3rd party vendor RFQ platform that is not part of any CAT Reporter’s OMS/EMS. Upon selection of a response, the Asset Manager either:

• sends a new order request electronically to the winning bidder,
• the RFQ platform automatically sends the new order request to the winning bidder, or
• the winning bidder has standing instructions to create a new order for this Asset Manager once it receives a message from the RFQ platform that it has won.

Because the RFQ responses were sent through an RFQ platform and not via standard electronic format directly to or from a CAT Reporter’s OMS/EMS, none of the responses are reportable in Phase 2c or Phase 2d.

However, the receipt of the order from the Asset Manager, as well as any subsequent actions taken by the winning bidder to process the order are reportable events in the phase that order would otherwise become reportable.
 

This FAQ has been archived and moved to Archived FAQs.

In Phases 2a or 2b, events subsequent to an internal route modification may be populated with any orderID that allows the event to be linked to the order lifecycle. For example, an order that was internally routed from a sales desk to a trading desk is subsequently modified at both the sales and trading desks, and ultimately executed at the trading desk. The sales desk and trading desk maintain different orderIDs. In this example, in Phase 2a the orderID on the related Trade event may link to either the MEIR reported by the trading desk or the MEOM reported by the sales desk. Starting in Phase 2c, the Trade event must link to the MEIM reported by the trading desk.  Additionally, beginning on December 5, 2022, if an order is partially routed internally and a new orderID is not assigned, the deskOrderID field is required to be populated in the Order Internal Modified event (MEIM, MOIM or MLIM). If a new deskOrderID is assigned, the deskOrderID of the event being modified must be reported in the priorDeskOrderID field.

Proprietary equities orders that are simultaneously entered into an OMS/EMS upon origination are always considered electronic. 

This FAQ has been archived and moved to Archived FAQs.

No.  Conversion of convertible bonds into the underlying equity are not orders, as defined by SEC Rule 613. Therefore, such conversions are not required to be reported to CAT.

No.  ETF creations and redemptions are not orders, as defined by SEC Rule 613.  Therefore, ETF creations and redemptions are not required to be reported to CAT.

No. ADR creations and cancellations are not orders, as defined by SEC Rule 613. Therefore, ADR creations and cancellations are not required to be reported to CAT.

No. Transfers of securities during an account transfer between broker-dealers (e.g. ACATS transfers, transferring a Registered Investment Advisor (RIA) book of business from one Industry Member to another Industry Member and for a clearing firm when a correspondent firm changes to another clearing firm) are not orders, as defined by SEC Rule 613. Therefore, such account transfers are not required to be reported as Transaction activity to CAT. The same guidance would apply to a firmDesignatedID (FDID) representing a Relationship ID or Entity ID. Also, see FAQ Q53.

This FAQ was archived and moved to Archived FAQs.

Since the RIA is placing the order directly in the customer account at BD2, BD2 is required to report a New Order event (“MENO”) with a Firm Designated ID (“FDID”) that represents the customer/client account number. BD2 is also required to report any subsequent actions taken on the order (e.g., executing, routing, canceling, etc.). BD1 does not have an order in this scenario and therefore does not have a CAT reporting obligation.

Industry Members undergoing an organizational change should contact FINRA CAT, LLC to ensure that proper registrations, entitlements and reporting relationships are established in CAT, so that there are no interruptions in the Industry Member’s ability to report to CAT upon the completion of the transaction. Industry Members undergoing organizational changes should also pay particular attention to open limit orders established prior to the completion of any transaction. If the predecessor firm has open limit orders on its books that will be executed or otherwise resolved under the successor firm, the successor firm must populate the originatingIMID field on any events related to a New Order or Order Accept Event originated by the predecessor with the CATReporterIMID of the predecessor firm to support linkage. Industry Members undergoing an organizational change as described above may notify the FINRA CAT Helpdesk at 888-696-3348 or help@finracat.com prior to the completion of the transaction.

The orderType field for orders received/originated or routed as Stop orders must be populated as ‘MKT’, and the orderType field for orders received/originated or routed as Stop Limit orders must be populated as ‘LMT’. The following chart contains a description and usage examples for the handlingInstructions required for Stop, Stop Limit, Stop on Quote, Stop Limit on Quote, Trailing Stop, and Trailing Stop Limit orders. If the stop price is known (the stop price in these examples is $1.00), then the handling instruction of STOP denotes the stop price and requires a numeric value representing the stop price (e.g., STOP=1.00). In instances where there is a Stop order, but the exact stop price is unknown because it is either based on an underlying condition or will be determined by the destination venue, then the Industry Members may populate a handlingInstructions value of ‘STOPF’ (See FAQ B67).

* If the stop price is not known at the time of order receipt or origination or receipt, Industry Members must populate a handlingInstructions value of STOPF instead of STOP.  All additional required handlingInstructions values outlined above (i.e., SLQ, SOQ) would also be required to be reported in conjunction with STOPF. See FAQ B67 for additional information.

See also:

• See FAQ B66 regarding when the Order Effective event/Option Order Effective event (MEOE/MOOE) is required to be reported to CAT.
• See FAQ B59 for information related to the reporting requirements when a Stop, Stop Limit, Stop on Quote, or Stop Limit on Quote order is triggered.
• See FAQ B60 regarding which party has the obligation to report the Order Effective event/Option Order Effective event (MEOE/MOOE) to CAT.
• See FAQ B61 for information on reporting requirements for Stop Stock orders.
• See FAQ B62 for information related to the reporting requirements for Trailing Stop and Trailing Stop Limit orders.
• See FAQ B67 for information related to Stop orders when the exact stop price is unknown because it is either based on an underlying condition or will be determined by the destination venue.

If an order is received/originated or routed without a specific limit price but includes handlingInstructions that may include certain pricing criteria, such as a ‘PEG’ or options related order, the orderType field may be populated as either ‘MKT’, or ‘LMT’ with a price of ‘0’. The ‘PEG’ or other instruction must be included in the handlingInstructions field on the event. If an order is not a market order but is received or originated without a specific limit price and does not have handlingInstructions that include pricing criteria, such as an order that is originated to represent multiple customer orders but does not have a set limit price, the orderType field must be populated as ‘LMT’ and the price must be ‘0’. 

This guidance does not apply to Stop or Stop Limit orders - refer to FAQ B57 for additional information on the orderType field for Stop, Stop Limit, Stop on Quote, Stop Limit on Quote, Trailing Stop, and Trailing Stop Limit orders.

In Phase 2a (equities) and Phase 2b (options), Industry Members are required to report a New Order event or New Option Order event (MENO or MONO) representing receipt or origination of the order with applicable handlingInstructions, as well as any subsequent actions taken on the order (e.g., executing, routing away or canceling).  

Beginning in Phase 2c (equities) and Phase 2d (options), in addition to reporting the receipt or origination of the order with applicable handlingInstructions, Industry Members will be required to report an Order Effective event or Option Order Effective event (MEOE or MOOE) when all underlying conditions of an order (i.e., the Stop) are met such that the order becomes and remains effective until it is fully executed or cancelled. Refer to the Industry Member Reporting Scenarios document for additional information.

Additionally, beginning December 5, 2022, the Multi-Leg Order Effective event (MLOE) is required to be reported to indicate that a multi-leg order, or an underlying condition of a multi-leg order, has become effective.

See also:  

•    See FAQ B57 regarding how the orderType and handlingInstructions fields must be populated for Stop, Stop Limit, Stop on Quote, Stop Limit on Quote, Trailing Stop, and Trailing Stop Limit orders.
•    See FAQ B60 regarding which party has the obligation to report the Order Effective event/Option Order Effective event/Multi-Leg Order event (MEOE/MOOE/MLOE) to CAT.
•    See FAQ B61 for information on reporting requirements for Stop Stock orders.
•    See FAQ B62 for information related to the reporting requirements for Trailing Stop and Trailing Stop Limit orders.
•    See FAQ B67 for information related to Stop orders when the exact stop price is unknown because it is either based on an underlying condition or will be determined by the destination venue.
 

Beginning in Phase 2c (equities) and Phase 2d (options), the party that is holding the order at the time the order or all underlying conditions are met (such that the order becomes and remains effective until it is fully executed or cancelled) has the obligation to report to CAT the Order Effective event or Option Order Effective event (MEOE or MOOE). Refer to the Industry Member Reporting Scenarios document for additional information.

Additionally, beginning December 5, 2022, the Multi-Leg Order Effective event (MLOE) is required to be reported to indicate that a multi-leg order, or an underlying condition of a multi-leg order, has become effective.

See also:  

•    See FAQ B57 regarding how the orderType and handlingInstructions fields must be populated for Stop, Stop Limit, Stop on Quote, Stop Limit on Quote, Trailing Stop, and Trailing Stop Limit orders.  
•    See FAQ B59 for information related to the reporting requirements when a Stop, Stop Limit, Stop on Quote, or Stop Limit on Quote order is triggered.
•    See FAQ B62 for information related to the reporting requirements for Trailing Stop and Trailing Stop Limit orders.
•    See FAQ B67 for information related to Stop orders when the exact stop price is unknown because it is either based on an underlying condition or will be determined by the destination venue.
 

In Phase 2a, Industry Members are required to report a New Order event (MENO) with a handlingInstructions value of ‘SW’ (Stop Stock Transaction) indicating that the transaction resulted from an order for which a member and another party agreed that the order will be executed at stop stock price or better. The ‘SW’ handlingInstructions must be paired with a numeric value representing the agreed upon stop stock price (e.g., SW=35.00). The Industry Member would also be required to report any subsequent actions taken on the order (e.g., executing, routing away or canceling).

Starting in Phase 2c, Industry Members will still be required to report the ‘SW’ handlingInstructions paired with the stop stock price (e.g., $35.00); however, for Stop Stock orders where the entire shares quantity of the order is not being stopped, then the handlingInstructions field must also be populated with a value of ‘SWQ’ paired with the quantity of shares being stopped (e.g., SWQ=100). When a handlingInstructions value of ‘SWQ’ is populated, the value of ‘SW’ paired with the stop stock price must also be populated, otherwise the record will reject for invalid handlingInstructions.

Refer to the Industry Member Reporting Scenarios document for additional information.
 

For CAT reporting purposes, a Trailing Stop order allows the stop price to increase (or decrease) by a predetermined amount or formula (e.g., a specified dollar amount, a percentage of the market price, or some other predetermined criteria) as the market price of the security advances (or declines). Once the Trailing Stop price is triggered, the sell (or buy) order becomes either an executable market order or a limit order (e.g., a Trailing Stop Limit order). 

In Phase 2a/2b, Industry Members are required to report a New Order event or New Option Order event (MENO or MONO) with a handlingInstructions value of ‘TS’ (Trailing Stop) representing receipt or origination of the Trailing Stop order. When the market price hits or goes through the highest (or lowest) calculated Trailing Stop Price, Industry Members are also required to report an Order Modified event or Option Order Modified event (MEOM or MOOM) with applicable updates to the price field. The MEOM/MOOM must not have a handlingInstructions value of ‘TS’ since the underlying condition of the order was triggered and the order is no longer a Trailing Stop order. Industry Members are not required to report additional MEOM/MOOM events each time the predetermined amount or formula is recalculated. The Industry Member is also required to report any subsequent actions taken on the order (e.g., executing, routing away or canceling). 

In Phase 2c (equities) and Phase 2d (options), Industry Members will still be required to report a New Order event or New Option Order event (MENO or MONO) with a handlingInstructions value of ‘TS’ representing receipt or origination of the Trailing Stop order. Industry Members will also be required to report an Order Effective event or Option Order Effective event (MEOE or MOOE) when all underlying conditions (i.e., the Trailing Stop) are met and the order becomes and remains effective instead of an MEOM/MOOM (as required in Phase 2a/Phase 2b). Additionally, beginning December 5, 2022, the Multi-Leg Order Effective event (MLOE) is required to be reported to indicate that a multi-leg order, or an underlying condition of a multi-leg order, has become effective. The triggerPrice field on the MEOE/MOOE/MLOE event must be populated at the highest (or lowest) calculated trailing stop price. Refer to the Industry Member Reporting Scenarios document for additional information.

See also:  

•    See FAQ B57 regarding how the orderType and handlingInstructions fields must be populated for Trailing Stop and Trailing Stop Limit orders.
•    See FAQ B60 regarding which party has the obligation to report the Order Effective event/Option Order Effective event/Multi-Leg Order Effective event (MEOE/MOOE/MLOE) to CAT.
•    See FAQ B63 for information on how the initiator field should be populated if an Industry Member modifies or cancels an order based on implicit customer instructions communicated with the order.
 

In an Order Modified and Cancel/Replace event (MEOM), the initiator field indicates who initiated the order modification. In an Order Cancelled event (MEOC), the initiator field indicates who initiated the order cancellation. If an implicit, unsolicited modification or cancellation action is taken by an Industry Member based on inferred customer instructions (e.g., Industry Member cancels an order associated with a particular ATS Order Type that articulates an expiry time), then the initiator field must be populated with a value of ‘F’ (Initiated by the firm).

Similarly, for actions initiated by the Industry Member unilaterally as a direct result of customer modifications or cancellations, such the cancellation of a representative order following the customer’s cancellation of the associated client order held at the firm, or the modification of an Internal Route following the customer’s modification of the associated client order held at the firm, then the initiator field must likewise be populated with a value of ‘F’ (Initiated by the firm). 

• For example, a customer requests that Industry Member Broker 1 cancel an order for which Broker 1 had previously generated an associated representative order. While the Order Cancelled event (MEOC) associated with the client order held at Broker 1 would be denoted with ‘C’ (as the cancellation was initiated by the customer), the cancellation of the corresponding representative order by Broker 1 would be denoted with ‘F’, as the cancellation was initiated by the Industry Member.

The same guidance applies for Trailing Stop and Trailing Stop Limit orders routed between Industry Members in Phase 2a. For example, Industry Member Broker 1 originates a Trailing Stop order, which is then routed to and accepted by Market Maker 2. Market Maker 2 monitors the market conditions and is holding the order at the time the market price hits or goes through the highest (or lowest) calculated Trailing Stop Price, at which point Market Maker 2 unilaterally routes the order to an exchange for execution based on the implicit instructions communicated with the Trailing Stop order upon receipt. In this example, Market Maker 2 reports the triggering event in Phase 2a via an MEOM event, with the initiator flag populated with ‘F’, and the receiverIMID, senderIMID, senderType, routedOrderID left blank, as Broker 1 did not communicate modification instructions to Market Maker 2 at the time of trigger. Note, reporting requirements for Trailing Stop orders change in Phase 2c (see FAQ B62).

No. A single Order Fulfillment reflecting the final average price fill to the client order is required.  A Fulfillment Amendment would only be appropriate if the fill to the client was changed after the final fulfillment had been provided to the client. Some systems may provide intraday transparency to the progress of executing an order as informal information that is not considered by the firm to be ‘final’ fulfillments, and these should not be reported to CAT as fulfillments and fulfillment amendments.

This FAQ was moved. See FAQ E31.

Beginning in Phase 2c (equities) and Phase 2d (options), the Order Effective event/Option Order Effective event (MEOE/MOOE) is required to be reported to CAT when all underlying conditions of an order are met such that the order becomes and remains effective until it is fully executed or cancelled. Examples of orders requiring the MEOE/MOOE event include:

• Stop, Stop Limit, Stop on Quote, Stop Limit on Quote, Trailing Stop, and Trailing Stop Limit orders. 
• Conditional Orders wherein an order is contingent on the execution of another order.
• Orders contingent on the occurrence of a market condition (e.g., once symbol ABCD trades X# of shares, the order becomes executable).

In all of the above examples, one and only one MEOE/MOOE would be reported by the Industry Member holding the order at the time all underlying conditions are met (i.e., the stop).

The MEOE/MOOE should not be used in instances when an order has conditions that can become activated and inactivated multiple times throughout the day. Examples of the types of orders where the MEOE/MOOE should not be used include:

• Orders originated or generated utilizing a specific Trading Algorithm, as defined in the Industry Member Technical Specifications, that may cause it to move in and out of specific conditions or parameters. 
• Orders with spread conditions. For example, an Industry Member receives or originates Order A to purchase 200,000 shares of XYZ with the instructions that the order only be acted upon when the market price of security XYZ is within a $10.00 spread from the price of security ABC. 

In both of the above examples, Industry Members would not report an MEOE/MOOE event. 

See also:

• See FAQ B57 regarding how the orderType and handlingInstructions fields must be populated for Stop, Stop Limit, Stop on Quote, Stop Limit on Quote, Trailing Stop, and Trailing Stop Limit orders.  
• See FAQ B59 for information related to the reporting requirements when a Stop, Stop Limit, Stop on Quote, or Stop Limit on Quote order is triggered.
• See FAQ B60 regarding which party has the obligation to report the Order Effective event/Option Order Effective event (MEOE/MOOE) to CAT.
• See FAQ B62 for information related to the reporting requirements for Trailing Stop and Trailing Stop Limit orders.
• See FAQ B67 for information related to Stop orders when the exact stop price is unknown because it is either based on an underlying condition or will be determined by the destination venue.
• See FAQ D26 regarding ‘CND’ and ‘CMC’ handlingInstructions.

B57 and the Stop Orders section of Industry Member Technical Specifications note that the handling instruction of ‘STOP’ denotes the stop price and requires a numeric value representing the stop price (e.g., STOP=1.00). In instances where it is known that the order is a stop order, but the exact stop price is unknown because it is either based on an underlying condition or will be determined by the destination venue, Industry Members may populate a handlingInstructions value of ‘STOPF’.
 
Starting in Phase 2c (equities) and 2d (options), in scenarios where the trigger price was not explicitly captured in the handlingInstructions field on the related new order or in order accepted events (e.g. Stop Formula, Trailing Stop), then the triggerPrice field must be populated on the Order Effective event/Option Order Effective event (MEOE or MOOE) to reflect the stop price.  

Example 1: 
Conditional Order A is originated by Industry Member Broker 1 specifying that a stop price be calculated only after Order B is executed.  In this example, Broker 1 reports a New Order event (MENO) event with the ‘STOPF’ and ‘CND’ handlingInstructions values. Broker 2 is holding the order at the time all underlying conditions of the order (Order B being executed and then the triggering of the Stop) are met, at which point Broker 1 would report an MEOE event with the stop price in the triggerPrice field.

Example 2:
A stop order is originated by Industry Member Broker 1 and routed to Industry Member Broker 2 with instructions communicated that the stop price be set at Ask-5 (Ask minus $5.00). Broker 1 relies on Broker 2 to calculate the stop price. Upon order acceptance, Broker 2 uses its market data feeds to determine that $5.00 from the current market price of the security is $10.00. In this example, Broker 1 reports a New Order event (MENO) event with the ‘STOPF’ handlingInstructions value, and Broker 2 would report an Order Accepted event (MEOA) with the stop price determined by Broker 2 upon acceptance of the order (e.g., STOP=10.00). Broker 2 is holding the order at the time the stop was triggered and (starting in Phase 2c) reports the MEOE event. Since the stop price was captured on the MEOA event, the MEOE event does not require a triggerPrice.

See also:

• See FAQ B57 regarding how the orderType and handlingInstructions fields must be populated for Stop, Stop Limit, Stop on Quote, Stop Limit on Quote, Trailing Stop, and Trailing Stop Limit orders.  
• See FAQ B59 for information related to the reporting requirements when a Stop, Stop Limit, Stop on Quote, or Stop Limit on Quote order is triggered.
• See FAQ B60 regarding which party has the obligation to report the Order Effective event/Option Order Effective event (MEOE/MOOE) to CAT.
• See FAQ B62 for information related to the reporting requirements for Trailing Stop and Trailing Stop Limit orders.
• See FAQ B66 regarding when the Order Effective event/Option Order Effective event (MEOE/MOOE) is required to be reported to CAT.
• See FAQ B67 for information related to Stop orders when the exact stop price is unknown because it is either based on an underlying condition or will be determined by the destination venue.
• See FAQ D26 regarding ‘CND’ and ‘CMC’ handlingInstructions.
   

For order events (new order, new quote, trade and fulfillment events), if an Industry Member uses the same account for both market making and non-market making proprietary activity, the accountHolderType must be populated on an order-by-order basis. Orders meeting the definition of market making activity pursuant to FAQ C5 should be reported with the accountHolderType of 'O'. All other orders must be reported with the accountHolderType of 'P'.

Per FAQ U5, allocations to firm owned or controlled accounts are not required to be reported but may optionally be reported. For allocation events (post-trade allocation and amended allocation events) that are being optionally reported, if the Industry Member’s system is able to determine the accountHolderType on an allocation-by-allocation basis, the same guidance applies: allocations related to orders meeting the definition of market making activity pursuant to FAQ C5 should be reported with the accountHolderType of 'O' and allocations related to all other orders must be reported with the accountHolderType of 'P'. However, if the Industry Member’s system is unable to determine if the allocation is related to an order that was market making or non-market making proprietary activity, the Industry Member must populate the accountHolderType on its allocation events with the allowable value ('P' or 'O') according to its books and records. 

For NAVs with no offset, if the calculated NAV price is not known until after 4:15:00 pm ET on the date of origination/receipt, the MENO/MEOA should be marked as a market order, or as a limit order with a price of ‘0’, and handlingInstructions of ‘NAV'. Beginning in Phase 2d, for NAVs with an offset, the MENO/MEOA should also be marked with the handlingInstructions of ‘OFF’. The eventTimestamp on the MENO/MEOA should reflect the date and time that the terms and conditions of the order (with the exception of the calculated NAV) were recorded in the firm’s books and records. 

The MENO/MEOA must be reported to CAT by 8 am ET on T+1, where T represents the CAT Trading Day that the order was originated/received.  

For guidance on reporting price on order events in ETMFs or “NextShares,” see FAQ B23.
 

For NAVs, the eventTimestamp on the MEOT should reflect the date and time of execution of the trade at the calculated NAV and should match the date and time of execution reported in the trade report submitted to the FINRA trade reporting facility. The price should be the calculated NAV.

The MEOT must be reported to CAT by 8 am ET on T+1, where T represents the CAT Trading Day that the order was executed. For example, if the NAV is determined after 4:15:00 pm ET on Monday and the order is executed at that time, the MEOT must be reported to CAT by 8 am ET on Wednesday. 
 

If an equity order is tied to stock, fixed income, futures, or another product that is not reportable to CAT at a net price (or other formula such as a specific delta no later than Phase 2d), Industry Members must populate the appropriate handlingInstructions value of ‘TTS’, ‘TTF’, ‘TTO’, ‘TTU’, or ‘FUT’. This activity does not meet the definition of a multi-leg order, as these trading strategies do not contain an option leg, and must continue to be reported to CAT as equity order events in Phase 2d.

If a simple equity is tied to a simple option at a net price (or other formula such as a specific delta no later than Phase 2d) as part of a pairs trading strategy that does not meet the definition of a multi-leg order, the equity order must contain a handlingInstructions value of ‘TTSO’, and the option must contain a handlingInstructions value of ‘TTS’.

The equity leg of a multi-leg order is reportable in Phase 2a/2b/2c, and must include the handlingInstructions value of 'OPT', as outlined in FAQ B12. This activity will be reported to CAT as multi-leg order events in Phase 2d, and the handlingInstructions values ‘OPT’ and ‘TTSO’ will not be required to be captured on multi-leg order events. 

If a single, simple option order is tied to futures, fixed income, or another product that is not reportable to CAT, Industry Members must populate the appropriate handlingInstructions values of ‘TTF’, ‘TTO’, or ‘FUT’ in Phase 2b.

If an option order is tied to stock and meets the definition of a multi-leg order, Industry Members will be required to report this activity to CAT in Phase 2d. The handlingInstructions value of ‘TTS’ will not be required to be captured on multi-leg order events. 

While this multi-leg activity may be optionally reported to CAT beginning in Phase 2b, the option legs must be reported as simple option events with a handlingInstructions value of ‘CMPX’.  The handlingInstructions value of ‘TTS’ is not required. 

Beginning in Phase 2d, Industry Members will be required to populate the netPrice field on equity or simple option order events with the net price of the order if the order is tied to stock, fixed income, futures, or another product that is not reportable to CAT at a net price. The netPrice field will not be required if the order is tied to stock, fixed income, futures, or another product that is not reportable to CAT with another formula such as a specific delta.
 

No. In Phase 2a/2b, any response to an RFQ or other solicitation process is not required to be reported as a MENO or MONO no matter the method of response (electronic or manual).  In addition, while the Responder is not required to report its response to CAT, it may optionally do so using the handlingInstructions value of ‘SR’ on the appropriate CAT events.

However, once a winning bid(s) has been selected, any subsequent reportable activity must be reported to CAT.  For example, if the Solicitor must send an order to the Responder, then both the Solicitor and Responder have CAT reporting obligations. 

The reporting requirements for Phases 2c and 2d are different. Please refer to FAQ B45 for more details. 

In a scenario where a customer order is received and executed, and an Industry Member makes an accommodation to the customer due to a customer error (such as an incorrect quantity entered), Industry Members must report to CAT in accordance with what is captured in their books and records. 

For example, if the firm’s books and records reflect the accommodation as a correction to the order, the accommodation must be reported to CAT as an order correction event (actionType value of ‘COR’) with a handlingInstructions value of ‘CAC’ (Customer Accommodation Correction). If the firm’s books and records reflect the accommodation as a modification to the order, the accommodation must be reported to CAT as an Order Modified event. If the firm’s books and records reflect the accommodation only as a correction to the trade, no order correction event or Order Modified event is required, and the Industry Member is only required to report the trade correction as outlined in FAQ E29.
 

If an issue symbol is delisted and is no longer tradable on any market because the security is no longer valid, then no MEOC is required for GTC orders in that symbol, as this scenario would be considered an implicit cancellation. Industry Members choosing to optionally report this activity should be mindful that any errors received as a result of the symbol having been delisted on the Event Date would not be repairable.

Similarly, if a corporate action (e.g., merger/acquisition) occurs in which a security is no longer valid, and the symbol becomes associated with a new security, no MEOC would be required for the original security. For example, if there is an open GTC order in symbol ABC and ABC is acquired and no longer trades on any market, no MEOC is required.

However, explicit cancellations are required for any cancelled GTC orders and are reportable using the symbol on the list in the following scenarios. 

•    If the issue symbol changed and there is no change to the underlying security. For example, if a security trades under symbol ABC and changes its symbol to XYZ.  A cancel event is not required for ABC (the original order) but would be required for the new symbol, XYZ.

•    The symbol was delisted from one market and continued to trade on another market (either under the same symbol or a different symbol). For example, ABC traded over-the-counter and then listed on an Exchange under a new symbol XYZ.  A cancel event is not required for ABC (the original order) but would be required for the new symbol, XYZ.

Industry Members are responsible for identifying material changes to an underlying security from corporate action announcements and taking appropriate action to ensure compliance with their books and records and CAT transaction reporting requirements.

No. Starting in Phase 2d, Industry Members must capture and report the date and time they received a request from a customer or another Industry Member to modify or cancel an order in the requestTimestamp field. This requirement is also applicable to requests received from an internal desk to modify/cancel an existing order. The requestTimestamp is not required on modify/cancel events initiated by the firm or by a receiving desk but can be optionally reported. 

Industry Members may report the requestTimestamp by either capturing it in the modify/cancel event or by capturing it in a separate modify/cancel request event. If the Industry Member is able to capture the requestTimestamp in the modify/cancel event, a separate modify/cancel request event must not be reported.

Example 1 (requestTimestamp required)

Industry Member receives request to modify order from a customer. The firm must capture time the request was received from the customer.

Example 2 (requestTimestamp required)

Desk 2 receives a request to modify from Desk 1 who originally routed the order. Desk 2 must capture the time the request to modify was received from Desk 1. 

Example 3 (requestTimestamp NOT required)

Desk 2 receives an order from Desk 1. Desk 2, at some point thereafter, modifies the order. Desk 2 is not required to capture and report a request time. 

Example 4 (requestTimestamp NOT required)

Industry Member modifies a firm initiated order. Industry Member is not required to capture and report the request time.

A mass cancellation is any process by which an execution venue (such as an ATS or exchange) automatically cancels all open orders or a group of open orders resulting from the receipt of a single mass cancellation message, whether communicated electronically or manually. Industry Members are not required, but may optionally choose, to report Route Cancelled events to CAT resulting from a mass cancellation message if the execution venue receiving the mass cancellation instruction is a CAT Reporter. If the mass cancellation instruction is sent to a foreign destination or other destination that is not a CAT Reporter, the Industry Member must report the Route Cancelled events to CAT.

All orders routed to an execution venue and subsequently cancelled by the sender without the use of a mass cancellation message/instruction must be reported to CAT as individual Route Cancelled events. 

Example 1: Exchange Member 1 routed orders to Exchange A on session EX1 and Exchange A accepted them all. Due to a connectivity issue, Exchange Member 1 must call Exchange A to cancel all open orders routed on session EX1. Exchange A verifies verbally that all orders on this session are cancelled but Exchange Member 1’s OMS cannot generate Route Cancelled events for the non-electronic/manual mass cancellation. Exchange Member 1 is not required to report Route Cancelled events in this case.

Example 2: Exchange Member 1 routed orders to Exchange A on session EX1 and Exchange A accepted them all. For expediency, Exchange Member 1 sends an electronic mass cancel request to Exchange A to cancel all open orders routed on session EX1. Exchange A electronically cancels all open orders on this session. Exchange Member 1 is not required to report Route Cancelled events in this case.

Example 3: US Broker-Dealer 2 routed orders to Foreign Exchange B on session EX2 and Exchange B accepted them all. For expediency, Broker Dealer 2 sends an electronic mass cancel request to Foreign Exchange B to cancel all open orders routed on session EX2. Foreign Exchange B electronically cancels all open orders on this session. In this case, Broker Dealer 2 is required to report all Route Cancelled events in CAT reportable symbols.
 

Subsequent events (for example, MEOM, MEOC) for any open orders in the original security prior to the corporate action are not required to be reported and if reported, will result in a linkage error that cannot be repaired. 

If the customer/client wants to trade in the new security, the Industry Member must create a new order for the issue symbol with a new orderID.

Industry Members are responsible for identifying material changes to an underlying security from corporate action announcements and taking appropriate action to ensure compliance with their books and records and CAT transaction reporting requirements.

The Operating Committee has determined that “Trading Day” shall have the following meaning for all Eligible Securities. For Participant CAT Reporters the Trading Day is defined as beginning after midnight on one trade date and ending at midnight the next trade date. For Industry Member CAT Reporters, Trading Day is defined as beginning immediately after 4:15:00 p.m. and no fractions of a second Eastern Time on one trade date and ending at exactly 4:15:00 p.m. and no fractions of a second Eastern Time on the next trade date.

For purposes of reporting to the CAT, the Participants have adopted the definition of “foreign broker-dealer” as set forth in SEC Rule 15a-6(b)(3). In particular, SEC Rule 15a-6(b)(3) states: “The term foreign broker or dealer shall mean any non-U.S. resident person (including any U.S. person engaged in business as a broker or dealer entirely outside the United States, except as otherwise permitted by this rule) that is not an office or branch of, or a natural person associated with, a registered broker or dealer, whose securities activities, if conducted in the United States, would be described by the definition of ‘broker’ or ‘dealer’ in sections 3(a)(4) or 3(a)(5) of the [Securities Exchange Act of 1934].”

For purposes of CAT Account Type Code, "institution" has the same meaning as the term "institutional account," as defined in FINRA Rule 4512(c).

For purposes of the affiliateFlag, an "affiliate" of the firm would include a person or entity that (i) directly or indirectly controls the firm, (ii) is controlled by the firm, or (iii) is under common control with the firm. Employees of the firm would not be considered "affiliates" for purposes of CAT.

For CAT reporting purposes, the accountHolderType value of market maker (value ‘O’) is used to identify orders originated by registered market makers or firms displaying quotes on an IDQS in their market making account. The value of ‘O’ must be used for all activity in the firm’s market making account for a security in which it is registered, regardless of where the order is ultimately routed or executed, or whether the activity is directly related to maintenance of a firm’s market making obligations. For example, block facilitation and hedging activity in the market making account in a security the firm is a registered market maker should also be reported as ‘O’.

Because options market making is currently defined and identified through use of the OCC clearing range, a separate CAT reporting guideline for the use of the accountHolderType of 'O’ for options orders has been mandated.

The accountHolderType value of 'O’ is not intended to identify all forms of market making under various rules, such as short sales rules, Volker, etc. Further, it is not intended to identify all trading in any proprietary account that may be used for market making activity, including hedging activity in securities for which a firm is not a registered market maker or block positioning in securities for which the firm is not a registered market maker. It is also not intended to identify proprietary activity in securities in which a firm is registered as a market maker that originate from desks other than the Market Making Desk. For example, activity occurring on a program desk that is walled off from the market making desk in securities that a firm is a registered market should be marked with an ‘accountHolderType’ value of ‘P’ (Other Proprietary).

Specifically:

For CAT reporting purposes only, the accountHolderType value 'O' (Market Making) should be used as follows:

Simple Equities: The value 'O' should be used for any order originated in an Industry Member’s market making account in a security for which the Industry Member is registered as a market maker, designated market maker, lead market maker or similar capacity on a national securities exchange or in which the Industry Member displays quotations on an IDQS in an unlisted stock.

Simple Options: The value 'O' should be used for any order originated in an account of the Industry Member that clears in the OCC clearing range of 'M'.

Complex Options: The value ‘O’ should be used for any order originated in an account of the Industry Member where the option leg(s) clear(s) in the OCC clearing range of ‘M’. This guidance is also applicable to the equity leg of a complex option in Phase 2d when complex orders become reportable to CAT. 

In Phases 2a, 2b and 2c, the values of ‘P’ (Other Proprietary) or ‘O’ (Market Making) are both acceptable for the accountHolderType value for the equity leg of the complex order. 

See FAQ B68 for more information on how to populate the accountHolderType field if an Industry Member uses the same account for both market making and non-market making proprietary activity.

The “orderType” field when used in reference to Exchange-listed options in the CAT Reporting Technical Specifications for Industry Members provides that the type of order being submitted may be, for example, a market, limit or cabinet order. For purposes of the “orderType” field, a “cabinet” order designation would be applicable for an order that is represented on/routed to a given Options Exchange as a cabinet order under the rules of that Options Exchange. See, for example, Cboe Options Rule 5.85(h) for cabinet orders represented on/routed to the Cboe Options Exchange.

Orders received or routed outside of an electronic order handling or execution system, such as via telephone, IM or email, are considered to be manual for purposes of reporting to the CAT. For purposes of reporting to CAT, electronic receipt of an order refers to the initial receipt of an order by an Industry Member directly into an electronic system for further routing and execution. Electronic routing of an order refers to the routing of an order directly from a firm’s electronic system to the routing destination.

Please note that the above general definition of electronic order is broader than the Phase 2b options electronic order definition that states that an order must be received in a standard format (e.g., FIX) directly into an order handling or execution system. The general definition includes all electronically received orders, such as an order entered online by a customer that is captured directly into an electronic order handling and execution system, and not just those received in a standard format. See also CAT FAQs G1 to G4 regarding manual orders.

For CAT reporting purposes, “other forms of solicitation” include any specific invitation to take the contra-side of an existing order. Any response to “other forms of solicitation” that meet this definition and meet the reportability criteria outlined in Section 3.4 of the IM Technical Specifications must be reported to CAT and must be marked with a solicitationFlag as ‘true’.

Any activity that is CAT reportable but does not meet the above definition of “other forms of solicitation”, such as responses to general postings of interest through an IOI that are not related to a specific order, must have the solicitationFlag populated as ‘false’.
 

If the Industry Member receives an order, the Industry Member must report the receipt of the order to the CAT. The details that must be reported for the receipt of an order are set forth in Sections 6.3(d)(i) (for the original receipt of an order) and 6.3(d)(iii) (for the receipt of an order that has been routed) of the CAT NMS Plan, as applied to Industry Members by Section 6.4(d)(i) of the CAT NMS Plan.

If an Industry Member receives an order, the Industry Member must report the time of order receipt pursuant to Sections 6.3(d)(i) (for the original receipt of an order) and 6.3(d)(iii) (for the receipt of an order that has been routed) of the CAT NMS Plan, as applied to Industry Members by Section 6.4(d)(i) of the CAT NMS Plan. The time of order receipt for Sections 6.3(d)(i)(E) and 6.3(d)(iii)(C) is the time that the Industry Member receives the order.

In Phase 2a, BD A will be required to report a single 10,000 share order with the time of receipt being the time the registered representative creates the order and that includes the Firm Designated ID (FDID) of the account that the shares will be held in until the registered representative determines the allocations to the 10 individual customer accounts. In Phase 2c, the firm performing the allocation will be required to report Post-Trade Allocation events for each allocation to the individual customer accounts that includes the FDID for each individual customer account.

BDA would be required to report each of the individual customer orders. Since the registered representative did not have discretion in the accounts, but instead received orders for these accounts, each order must be reported separately; therefore, you would be required to send 10 New Order Events to CAT. Additionally, BD A must report a separate New Order Event for the aggregated 10,000 share order created to represent the 10 customer orders.

No. accountHolderType "E" should only be used for orders received for employee accounts, not for accounts of employees’ family members.

No. accountHolderType "E" should only be used for orders received for accounts of a broker-dealer’s current employees, not for orders received for the accounts of former or retired employees or employees of any other broker-dealer.

No. The accountHolderType represents the type of beneficial owner of the account and, since the employee is not a beneficial owner, the accountHolderType "E" would not be appropriate. If the beneficial owner of the account was an institution, for example, an accountHolderType "A" (Institutional Customer) should be used even if an employee of the firm has discretion over the account.

Yes. Routed Order IDs must be reported in the same format in which they were received or the audit trail will be broken. For instance, if CAT Reporter A routes an order with a Routed Order ID of AB_0001, the receiving CAT Reporter must also report a Routed Order ID of AB_0001. In this instance, a Routed Order ID of AB001, AB_001 or anything other than the exact format of the original Routed Order ID will cause the audit trail to break and the Route Event will be marked as Unlinked.

In Phases 2a/2b/2c, these orders must be reported to CAT with a handlingInstructions value of ‘CNH’, denoting Cash Not Held. Starting in Phase 2d, these orders must be reported to CAT with a handlingInstructions value of ‘CASH’, denoting the “cash” order. If the order was also Not Held, the handlingInstructions value of ‘NH’ must also be populated.

Additionally, until December 5, 2022, they must be reported to CAT with a quantity equal to the number of shares that could be purchased with the specified dollar amount based on the best available market at the time of order receipt. For example, if an Industry Member receives a “cash” order for $1,000 when the best available market is $20, then the Industry Member must report a quantity of 50 in the New Order event or Order Accepted event. 

Starting December 5, 2022, Industry Members must begin reporting the ‘CASH’ handlingInstructions with the notional value of the order and may report a quantity value of ‘0’ instead of a calculated quantity. Industry Members should note that the option to report a calculated quantity for “cash” orders will be eliminated starting December 11, 2023, and Industry Members will be required to report a quantity value of ‘0’.

Industry Members need not submit an Order Modified event to reflect a change in share quantity due to market fluctuations during the life of the order. However, if a customer changes the dollar amount resulting in a partial cancellation, then an Order Modified event with a handlingInstructions value of ‘CASH’ must be reported to CAT to reflect that change. Order Cancelled and Order Adjusted events may not be used to report a change in dollar amount. Full cancellations of a “cash” order must be reported using an Order Cancelled event with a cancelQty of ‘0’ and leavesQty of ‘0’. 

The tradingSession field identifies the specific market session(s) during which an order is eligible to trade either based on instructions received by the Industry Member from its customer or based on communication by the Industry Member to the customer on when the order will be eligible for execution. The tradingSession field will be used in surveillance patterns to identify when orders may be eligible for execution.

Since the customer instructions were to acquire shares during regular market hours and the order is executed as agent or riskless principal at the same price that the Industry Member accumulated the shares during regular market hours, the order should be reported with a tradingSession value of "REG".

Since the Industry Member executed the trade on a net basis, the tradingSession field should be based on when the net trade can be executed. If the execution can take place either during regular market hours or in the after hours session, the tradingSession field should be populated with "REGPOST".

Since the original order was received with instructions to trade only during regular market hours, the tradingSession field must be populated with "REG". If the Industry Member records the subsequent instruction to complete the order as an order modification on its books and records, an Order Modified Event with the tradingSession of “POST” for the remaining share quantity must be reported. If the Industry Member does not record a modification to the order on its books and records, then no Order Modified Event is required.

Yes. The tradingSession field must be populated on all orders. However, if because of the specific nature of the handling instruction (e.g., Fill or Kill), the customer does not provide further information on the trading sessions in which the order may trade, it would be acceptable for the tradingSession field to be populated with "ALL" since no specific Trading Session was communicated by the customer to the Industry Member. This guidance to use the code of "ALL" includes scenarios where the handling instructions received with the order dictate the trading session in which order is eligible to trade, such as "Market on Open", but where no other specific instructions regarding the trading session were received from the customer.

In instances where an Industry Member does not receive specific instructions from its customer as to which session an order may trade, and the Industry Member does not otherwise communicate to the customer that the order will only be traded during specific market sessions, but, there is an understanding between the Industry Member and customer that the order is eligible to trade in a particular session(s), the tradingSession field must be populated with the code representing the specific trading session(s) in which the order is eligible to trade. For example, if an Industry Member receives orders from a particular customer or client with the understanding that orders will only be executed during regular market hours, the tradingSession field should be populated with "REG".

If an Industry Member receives an order for a security that is dually listed with specific instructions that the order is to be executed on the foreign market, then the Industry Member should populate the tradingSession field with the code “FOR” (to be executed only on a Foreign Market). It is important to note that the FOR value may only be used in instances where the order can only be executed on the foreign market. If it is possible that the order could be executed in the US, then the tradingSession field should be populated with the Trading Session value that reflects the sessions during which the order is eligible to trade in the US.

Yes. The tradingSession field must be populated on all orders, including proprietary orders originated by the Industry Member. If an Industry Member’s trading system does not generate specific instructions with respect to when the order is eligible to trade, the code “ALL” should be used.

"Fill or Kill" orders with limit prices should have the timeInForce field populated with "DAY".

The accountHolderType field is only available on the New Order Event which reflects receipt of a Customer order or origination of an order by the Industry Member. Since the type of beneficial owner for orders received from a customer or originated by the Industry Member is known, "U" (Unknown) is not an allowed value.

If an order is placed by an employee of the Industry Member and the account also meets the definition of an institutional account according to FINRA Rule 4512(c), then the Industry Member must use the accountHolderType value of ("E") on the related CAT New Order Event to identify that the beneficial owner of the account is an employee of the Industry Member.

The infoBarrierID field allows firms to uniquely identify on an order-by-order basis each information barrier that meets the criteria of the “no-knowledge” exception for certain proprietary trading activity under FINRA Rule 5320. By identifying specific information barriers that are in place with respect to individual orders, both customer and proprietary, Industry Members will provide CAT with information that can be used when conducting reviews of compliance with FINRA Rule 5320. Specifically, on all events for orders received or originated at a desk or department with an information barrier in place, Industry Members must populate the infoBarrierID with the value assigned by the Industry Member to the specific information barrier in instances where the firm is claiming the “no-knowledge” exception. The use of this field allows each customer and proprietary order to be identified with a particular information barrier.

For example, if an Industry Member has two or more separate desks or departments that share a single information barrier, orders received or originated at these separate desks or departments may be reported to CAT with the same unique infoBarrierID. If, alternatively, an Industry Member has separate desks or departments that are not within the same information barrier, orders received or originated at these desks or departments would be reported to CAT with different Information Barrier IDs. Finally, if an order is received or originated within an Industry Member that has no information barriers in place, those orders must be reported to CAT with the inforBarrierID field left blank. To the extent that Industry Members populate the infoBarrierID field, the use of values must remain consistent. Therefore, once used, a value may not be reassigned to identify a different information barrier.

Reporting Scenarios

Scenario #1 – Desks or Departments Sharing an Information Barrier
• Example: Firm A has a customer facing desk (Desk 1) and a proprietary desk (Desk 2) within the same information barrier that the firm has named “AB12”. Desk 1 receives an order from a customer and Desk 2 originates a proprietary order. The CAT reporting would be as follows:

Scenario #2 – Desks or Departments Separated by Information Barriers
• Example: Firm A has a customer facing desk (Desk 1) that is within an information barrier the firm has named “U89T” and a proprietary desk (Desk 2) that is within an information barrier the firm has named “4RYH”. Desk 1 receives an order from a customer and Desk 2 originates a proprietary order. The CAT reporting would be as follows:

Scenario #3 – Desks or Departments with No Information Barriers Example:
• Example: Firm A has a customer facing desk (Desk 1) and a proprietary desk (Desk 2), neither of which have information barriers in place. Desk 1 receives an order from a customer and Desk 2 originates a proprietary order. The CAT reporting would be as follows:

The accountHolderType must represent the type of beneficial owner of the account for which an order was received or originated. If the firmDesignatedID (“FDID” or “Firm Designated ID”) is based on a relationship (“Relationship ID”), the accountHolderType must represent the relationship with the IA/money manager and must not represent the IA/money manager’s client.

For example, if an order is received from a registered Investment Advisor (“RIA”) and the account is held in the RIA’s name, including DVP/RVP and omnibus accounts, the account would be considered “institutional” (as defined under FINRA Rule 4512(c)), and the order should be reported to CAT with an accountHolderType of 'A' (Institutional Customer) to reflect the status of the RIA.

If an order is received from an RIA and the account is held in the client’s name or in the RIA’s name for the benefit of a disclosed client, the account would not be considered institutional (as defined in FINRA Rule 4512(c)), and the order should be reported to CAT with an accountHolderType of 'I' (Individual Customer) to reflect the status of the client, unless the client itself qualifies as “institutional” under FINRA Rule 4512(c). If the client qualifies as “institutional” under FINRA Rule 4512(c), then the order should be reported to CAT with an accountHolderType of ‘A’ (Institutional Customer).
 

Firms providing direct market access to non-broker-dealer customers must populate the deptType field with the value of 'DMA' (Direct Market Access). The value of Sponsored Access ('SA') is only used for market access orders involving another broker-dealer.

The Exchange ATI values are separate and distinct from the accountHolderType values. The ATI values required to be submitted to the Exchange primarily are used to identify whether an Exchange member is entering an order into Exchange systems for its account or the account of some other entity, while the CAT accountHolderType values are used to identify the type of account originating an order. CAT captures capacity and other information in fields separate and distinct from the accountHolderType. Consequently, the Exchange ATI values will have no impact on a firm’s population of the accountHolderType in CAT.

The below chart that reflects the most common combinations of Exchange ATIs and CAT accountHolderType.

The ‘CND’ handlingInstructions value indicates that an order is contingent on the execution of another order. The ‘CMC’ handlingInstructions value indicates that an order is contingent on the occurrence of a market condition (e.g., once symbol ABCD trades X# of shares, the order becomes executable). Industry Members may populate both values if applicable to the order.

The time of receipt for such orders is the date and time the Industry Member determines it has an order and records such in its books and records. Beginning in Phase 2c (equities) and 2d (options), Industry Members populating ‘CMC’ and/or ‘CND’ in their CAT events will be required to report an Order Effective event or Option Order Effective event (MEOE or MOOE) when all underlying conditions are met such that the order becomes and remains effective until it is fully executed or cancelled. The triggerPrice field is not required for orders conditioned on the occurrence of a market condition and/or contingent on the execution of another order.

The ‘OET’ (Order Effective Time) handlingInstructions value has been removed and will not be incorporated in the Phase 2c (equities) and Phase 2d (options) CAT Reporting Technical Specifications for Industry Members.

See also:

• See FAQ B60 regarding which party has the obligation to report the Order Effective event (MEOE) to CAT.
• See FAQ B66 regarding when the Order Effective event/Option Order Effective event (MEOE/MOOE) is required to be reported to CAT.
   

An Industry Member providing sponsored access or direct market access must populate the deptType on its New Order or Order Accept event with SA (sponsored access) or DMA (direct market access) as prescribed in the Technical Reporting Specifications to indicate the Industry Member was acting as an SA or DMA provider and no other handling instructions are required to be reported on the New Order or Order Accept event. An Industry Member CAT Reporter being sponsored would be required to report relevant handling instructions on its CAT New Order or Order Accept event in Phases 2a and 2b, and on its Order Route event in Phases 2c and 2d, to the Industry Member providing the sponsored access as well. The receiving market center would report all relevant handling instructions received from the sponsored party on its Order Accept event to CAT. Reporting of specific handling instructions on new order events and order route events by SA and DMA providers will be evaluated by regulators during Phases 2a and 2b and may become reportable in Phase 2d for both equities and options.

This FAQ has been archived and moved to Archived FAQs.

In Phase 2a, if an order is received or originated with instructions to work the order using a Trading Algorithm as defined in the Industry Member Technical Specifications, a handlingInstructions value of 'ALG' should be populated on the New Order or Order Accepted event submitted to CAT along with any additional relevant handlingInstructions. For example, customer orders received with a counterparty restriction instruction and instructions to work using a trading algorithm should be reported to CAT using handlingInstructions values of ‘CPR’ and ‘ALG.’ Additionally, customer orders received with instructions to execute at TWAP or VWAP would be considered instructions to work the order using a trading algorithm and therefore any orders received with these instructions should be reported to CAT using a handlingInstructions value of ‘ALG.’ Firms should note that more granular handlingInstructions values may be required in future phases of CAT.

Starting in Phase 2c, Industry Members will be required to populate the ‘ALG’ handlingInstructions value on Order Route events for orders that were sent to another broker-dealer with instructions to handle the order using a specific trading algo. The ‘ALG’ handlingInstructions value must not be used on routes that are sent by an algo. The same guidance for Order Route events outlined above applies to the ‘ALGMod’ handlingInstructions value. Specifically that the ‘ALGMod’ value should not be used on routes that are sent resulting from the use of a different trading algorithm or a change in the settings of the algorithm. 

Example 1: Broker 1 receives a customer order with instructions to handle the order using a specific proprietary algo. Broker 1 then sends the order through its algo, and the algo routes the orders to the street. In this example, Broker 1 is required to report ‘ALG’ on its MENO from the customer. ‘ALG’ must not be populated on the routes made by the algo. 

Example 2: Broker 1 receives a customer order with instructions to handle the order using a specific algo at another broker-dealer. Broker 1 routes the order to Broker 2, who sends the order through its algo. In this example, Broker 1 is required to report ‘ALG’ on its MENO and MEOR (in Phase 2c) to Broker 2. Broker 2 is required to report ‘ALG’ on its MEOA. ‘ALG’ must not be populated on the MEORs for the routes made by the algo. 

Example 3: Broker 1 receives a Not-Held customer order. The trader uses discretion and determines to route the order through a specific proprietary algo. ‘ALG’ must not be populated on the MENO in this scenario, since the order was not received with the instruction to handle the order via an algo. At a future date, a new field will be added to the MENO to indicate that an Industry Member applied discretion to use an algorithm in the absence of a customer instruction. ‘ALG’ must not be populated on the MEORs for the routes made by the algo. 

Example 4: Broker 1 receives a Not-Held customer order. The trader uses discretion and determines to route the order to a specific algo at another broker-dealer. Broker 1 routes the order to Broker 2, who sends the order through its algo. ‘ALG’ must not be populated on Broker 1’s MENO in this scenario, since the order was not received with the instruction to handle the order via an algo. ‘ALG’ must be populated on Broker 1’s MEOR and Broker 2’s MEOA, as the instruction to handle the order using a specific algo was applied and passed by the trader who had discretion over the order. ‘ALG’ must not be populated for the routes made by the algo.

Yes, for each order, the “material terms of the order” (as that term is defined in SEC Rule 613(j)(7)), including those material terms that may be defaulted at a port or connection level, must be reported to CAT. This includes implicit or default instructions agreed to between the Industry Member and its customer or client that are material terms.

Under SEC Rule 613(j)(7) “material terms of the order” includes, but is not limited to, “the NMS security symbol; security type; price (if applicable); size (displayed and non-displayed); side (buy/sell); order type; if a sell order, whether the order is long, short, short exempt; open/close indicator; time in force (if applicable); if the order is for a listed option, option type (put/call), option symbol or root symbol, underlying symbol, strike price, expiration date, and open/close; and any special handling instructions.”

If the beneficial owner of an account is a non-broker-dealer foreign affiliate or non-reporting foreign broker-dealer, then the Industry Member must use the accountHolderType value of ("F") on the CAT New Order event even if the beneficial owner also meets the definition of another accountHolderType value.

The "ALL" tradingSession means that the order can trade in any available session at the venue where it is sent. For example, if an exchange only has REG tradingSession, the order may be reported with a tradingSession of “REG” or "ALL". If an exchange has multiple sessions, and the order is not allowed to trade in all sessions based on a customer instruction or understanding, then the specific trading sessions in which the order is allowed to participate must be identified.

Most options orders are currently only eligible to trade during regular market hours sessions (generally from 9:30 am to 4:00 pm or 4:15 pm Eastern Time) on the options exchanges and, as a result, the tradingSession field must be populated with 'REG' (Regular Only) or 'ALL' (All Sessions).  Note that option orders eligible to trade during a regular market hours session’s opening or closing rotation must also be populated with 'REG' or 'ALL.'  (See also FAQ D32.) 

An exception to the general requirement above applies for certain options that are eligible to trade on the Cboe Exchange, Inc. during extended global market hours sessions (generally from 8:15 pm T-1 to 9:15 am Eastern Time) and/or regular market hours sessions.  For those orders in those options, the tradingSession field must be populated with:

-    'REG' (Regular Only), for orders only eligible to trade during regular market hours; or 
-    'ALL' (All Sessions), for orders eligible to trade during extended global market hours, regular market hours, and the Curb session.
-    'REGPOST' (Regular and Post Market), for orders eligible to trade during regular market hours and the Curb session.

Other values for the tradingSession field identified in the specifications (FOR, POST and PREPOST) are not currently applicable to options orders.
 

As a general rule, the party who applies the default or implicit handling instruction to the order is required to report any material terms in that instruction to CAT.

Some examples:  

• If an Industry Member explicitly sets or configures their system to default and send specific instructions are applied when it routes an order, then material terms contained in those instructions are reportable by the sending firm on the Order Route Event (MEOR / MOOR).
• If standing or default instructions are maintained and applied by a receiving party (another Industry Member, ATS or Exchange) when the order is received, then material terms contained in those instructions are reportable by the receiving party on the Order Accepted Event (MEOA / MOOA).
• If the standing or default instructions are maintained and applied by an Industry Member, ATS or Exchange at the time of some other reportable event, then the material terms contained in those instructions are reportable by the party applying the instruction.  

Note that the materials terms of an order associated with a given CAT reportable event are reported in the applicable field (e.g., prices are reported in the ‘price’ field, and special handling instructions are generally reported in the ‘handlingInstructions’ field unless another field applies). 

Some examples:  

• If an Industry Member routes an order and sets a default instruction of “STP” on all outbound orders, the Industry Member would be required to report this instruction (which is a material term) to CAT on its Order Route beginning in Phase 2c. However, if the sending firm does not explicitly include the  instruction on the route to the receiving firm, but it is implicitly assumed by the receiving firm when the order is accepted (based on standing agreement, port level settings, etc.), then the receiving firm’s MEOA/MOOA would require the “STP” handlingInstructions.
• If an Industry Member has an agreement with a customer, such that all orders from that customer should be treated as “NH” or defaulted to ”WRK”, the Industry Member must include the “NH” or “WRK” handlingInstructions on the MENO/MONO or MEOA/MOOA event. This is effective in Phase 2a (equities) / 2b (options).
• If an Exchange cancels all of an Industry Member’s pending orders based on a technical disconnect parameter (e.g., loss of heartbeat over a period of time), whether the parameter is set by the Exchange unilaterally or by the Exchange based on instructions from the Industry Member, then the Exchange’s Order Canceled Event would note the special cancel instructions (in the cancelReason field).  

In Phases 2a/2b/2c, the ‘SMT’ handlingInstructions value is only applicable to Order Route events (MEOR/MOOR) and is used to indicate that an order is routed out via a Smart Order Router. Thus, Industry Members must not populate the ‘SMT’ handlingInstructions value on New Order events (MENO/MONO) or Order Accepted events (MEOA/MOOA) when an order is originated or received with instructions to use a specific Smart Order Router, and must not populate the ‘SMT’ handlingInstructions value on Order Route events (MEOR/MOOR) when an order is routed to another Broker-Dealer with instructions to use a specific Smart Order Router, as the ‘SMT’ value is only intended to identify Order Route events sent by a Smart Order Router.

While the handlingInstructions field is not required to be populated on Order Route events until Phase 2c (equities) and Phase 2d (options), the ‘SMT’ value may optionally be populated in this field on Order Route events in Phase 2a (equities) and Phase 2b (options).

Beginning in Phase 2d, the ‘SMT’ handlingInstructions value is being retired and will no longer be accepted.  
 

No, the handlingInstructions value of ‘CSC’ (Contingent on Spread Condition), introduced in the November 2020 Industry Member Technical Specifications, must not be reported on the New Order or Order Accepted events submitted to CAT if such spread conditions are associated with a particular algorithm. For example, if an order is received with instructions to work the order using a specific trading algorithm, and the algorithm works the order in a way similar to a spread condition, then these instructions must be reported to CAT using a handlingInstructions value of ‘ALG’ rather than ‘CSC’.  The Industry Member must not report both ‘ALG’ and ‘CSC’ handlingInstructions in this example, as it would be erroneous reporting. 

Firms should note that more granular handlingInstructions values may be required in future phases of CAT.
See also:

• See FAQ B66 regarding when the Order Effective event/Option Order Effective event (MEOE/MOOE) is required to be reported to CAT.
• See FAQ D29 regarding how Industry Members should populate handling instructions for orders received or originated with instructions to work the order using a trading algorithm.
   

No. Sponsored Access and Direct Market Access providers must not populate the ‘DIR’ handlingInstructions value on Order Accepted or New Order events. Further, Sponsored Access and Direct Market Access providers must correctly populate the deptType field with either ‘SA’ (for sponsored access) or ‘DMA’ (for direct market access).

For purposes of Section 6.3(d)(ii) of the CAT NMS Plan, an order is considered to have been routed internally at the Industry Member when the Industry Member originates or receives an order and then subsequently transmits that order to another desk or department within the Industry Member. A desk or department is interpreted as a place or system within the Industry Member where an order can be executed, either automatically or with the assistance of traders. Examples of a desk or department include an agency desk, sales desk or arbitrage desk. The Industry Member, however, is not required to report information regarding an order’s movement between two systems within the same desk or department as an internal route. 

Yes, if the Industry Member routes an order to another Industry Member or a Participant, the Industry Member must report the routing of the order to the CAT. The details that must be reported for the routing of an order are set forth in Section 6.3(d)(ii) of the CAT NMS Plan, as applied to Industry Members by Section 6.4(d)(i) of the CAT NMS Plan. While all routes are required to be reported to CAT, Order Route events for orders that were rejected by the Industry Member or Participant to which the order was routed are not required to be reported in Phases 2a (equity) or 2b (options).

Beginning in Phases 2c (equity) and 2d (options), Industry Members will be required to report an Order Route event with the routeRejectedFlag populated as 'true.' An Order Route Supplement Event may be used in Phase 2c or 2d to populate the routeRejectedFlag. Further, beginning in Phase 2d, if a request to modify or cancel a route that was sent to another broker-dealer, exchange or ATS is rejected, Industry Members are required to report a Route Modified (MEMR)/Route Cancelled (MECR) event with the routeRejectedFlag populated as 'true.' A Route Modified Supplement (MEMRS)/Route Cancelled Supplement (MECRS) event may optionally be used to populate the routeRejectedFlag.

If an Industry Member chooses to optionally report an Order Route event for a rejected route early in Phases 2a or 2b, the routeRejectedFlag must be populated as ‘true’. As with all data reported to the CAT, Phase 2c or 2d activity voluntarily reported in Phase 2a or 2b must be timely, accurate and complete and will be included in the firm’s error rate. Any Order Route event representing a rejected route that is optionally reported in Phase 2a or 2b with a routeRejectedFlag of ‘false’ will result in an unlinked event that must be corrected and resubmitted accordingly.

In Phase 2a, firm modifications of a previously routed order are not required to be reported to CAT if the destination to which the order was routed is a CAT Reporter. As a result, in the given example, the modification of the 2,000 share order sent to Exchange A would not be reportable by BD A, but would be reported to CAT by Exchange A. If the order had been routed to a foreign destination or other destination that is not a CAT Reporter, BD A would be required to report the modification to CAT.

Beginning in Phase 2d, these modifications, as well as cancellations of a route initiated by the firm, and not the client, must be reported to CAT.  

Orders entered directly into a Nasdaq Workstation would be considered manual. If the orders are routed into ACES Pass-Thru via an electronic order handling system, the orders would be considered electronic and a Routed Order ID must be passed through via the Branch/Sequence Number field in ACES.

This FAQ has been archived and moved to Archived FAQs.

Yes. Members are required to link the .RA transaction report submitted to a FINRA trade reporting facility to the related CAT Trade Event. Industry Members should reference the CAT Reporting Technical Specifications for Industry Members for the applicable matching criteria.

Yes. The CAT Trade linkage process will allow a single Trade Event to match to more than one trade report provided that the execution time, tapeTradeID, MPID and issue symbol on all related trade reports are identical to those reported on the CAT Trade Event.

This FAQ has been archived and moved to Archived FAQs.

This FAQ has been archived and moved to Archived FAQs.

Yes. If an Industry Member receives a Short Sale order prior to the triggering of a circuit breaker, the Industry Member would populate the side field with ‘SS’ (Short Sale). If, at the time the order is routed, a circuit breaker is triggered, the order may be marked “short exempt” consistent with SEC Rule 201, and the side field on the related Order Route event must be populated with ’SX.’

A. The time of execution of 9:35:00.000 a.m. must be reflected on both the trade report and the related CAT Trade Event in the eventTimestamp field. The reference time of 9:30:00.000 a.m. must be included in the trade report in the Trade Modifier 4 Time Field and is not required to be reported to CAT. The reference time will be obtained from the trade report.

Because the trade was executed on a different day from the reference price, the actual time of execution must be reflected in the eventTimestamp field on the CAT Trade Event and in the Execution Time field on the trade report for both OTC equity securities and NMS stocks. Please refer to TR FAQs 408.3, 408.4 and 408.5 for more information on the trade reporting requirements for PRP trades.

A. Yes. In CAT, routing instructions must be reported by the routing firm in Phase 2c. If the routing instructions are the same as the instructions received by the firm, then the firm may populate the handlingInstructions field with the value “RAR” (Routed as Received).

The only exception to this requirement is the “OPT” handling instruction, which must be populated on Order Route events representing the equity leg of a complex option with a net price beginning in Phase 2a. Refer to FAQ B12 for additional information.

Yes. Firm B must report the instructions it received from Firm A as to how Firm B was instructed to handle the order. In this example, Firm A instructed Firm B to route the order directly to the executing venue. The terms and conditions given to the executing venue are required to be reported to CAT using the values available in the handlingInstructions field in the CAT Reporting Technical Specification for Industry Members. The handlingInstructions on an Order Route Event are not required to be reported until Phase 2c. Note exchange specific values are not used, but rather an allowed value that most closely reflects the specific instruction sent to the exchange.

Orders that are routed as agent to another CAT Reporter (either an exchange or Industry Member) and executed by the receiving party do not require the submission of a Trade Event or Order Fulfillment by the routing firm unless the order was routed to a foreign venue which does not report to CAT. If the order was worked via a representative order, however, where the representative order was routed away instead of the underlying customer order, an Order Fulfillment Event would be required. See Appendix C of the Technical Specifications for more information on the reporting requirements for representative orders.

If separate and distinct functions are performed within the same desk or department of a firm, an Internal Route Event may be required if an order is passed between traders who perform different functions.  For example, an order would be considered to have been transferred to another department for CAT reporting purposes, if it were transferred between functions that the firm considers to be independent aggregation units for purposes of SEC Regulation SHO (See SEC Rule 200(f)). 

If an order is transmitted to a desk that performs multiple functions, the firm should populate the receivingDeskType with the code that identifies the function for which the specific order was routed to the desk.  For example, if a program trading order is routed to a desk that engages in arbitrage activities as well as program trading, the CAT Internal Route Event should include a receivingDeskType of “PT” to indicate the order was transmitted to the program trading function on the desk.

This FAQ has been archived and moved to Archived FAQs.

No. Each Industry Member is only required to report the order information that was received by that Industry Member. Thus, for an order received from another broker-dealer, the receiving Industry Member is only required to report the special handling instructions that are sent by the sending broker-dealer to the receiving Industry Member.

If a trade is reported to both CAT and a TRF/ADF/ORF, and later cancelled in the TRF/ADF/ORF, the cancellation is not required to also be reported to CAT. CAT will obtain the cancellation information from the TRF/ADF/ORF.

If the original trade was reported to CAT and correctly linked to the original TRF report, no further CAT reports are required for the correction. CAT will obtain that information from the TRF data. If, however, any part of the order prior to the execution was reported to CAT incorrectly, those corrections must be submitted to CAT.

If the required CAT order events, including the New Order and Trade Event were not previously reported to CAT, they must be reported and will be marked late. The late reported CAT Trade Event must link to the “as of” trade report submitted to the TRF. If the CAT Trade Event was reported on time, it would have been marked as unlinked since there was no related trade report available for linking. After processing, the unlinked CAT Trade Event will be marked as corrected provided it could be linked to the “as of” TRF report.

No. However, the tapeTradeID reported in the CAT Trade Event must precisely match the Branch/Sequence Number or FINRA Compliance Number reported to a TRF (including spaces and capitalization).

Yes. This number can contain any ASCII characters, except the specified file delimiters. The tapeTradeID contained in the CAT Trade event must the exact same as that contained in the TRF Report, including preceding zeros or spaces.

On a MEOT event, the only instances where the cancelFlag may be set to ‘true’ is when a trade is cancelled because the trade report is rejected by the TRF/ORF or ADF beginning in Phase 2a, or when the trade is cancelled but the Trade event is not linked to the related trade report due to use of reportingExceptionCode ‘C’ beginning in Phase 2c. For all instances where a trade is reported to and accepted by the TRF/ORF or ADF, and the trade report is linked to a corresponding Trade event, including those that are cancelled or busted in the trade reporting data, the cancelFlag must be set to ‘false’.

Yes. Section 6.3(d)(ii) of the CAT NMS Plan applies to both internal and external routes. Specifically, when Section 6.3(d)(ii) refers to “the routing of an order,” it includes routing orders internally within an Industry Member and routing orders by an Industry Member externally to an exchange or another broker-dealer. FAQ E.1 describes in more detail the types of internal routes that must be reported to the CAT.

The affiliateFlag should be populated as ‘true’ when routing an order between IMIDs belonging to the same broker-dealer.

The exchOriginCode field is a required text field on the CAT Options Order Route Event (“MOOR” event) and CAT will reject the record if the field is not populated. In instances where the market maker sends a market maker order through an options exchange protocol that does not require an exchange origin code, Industry Members must populate the exchOriginCode with “MM.”

The CAT reporting requirements depend on what reporting error(s) the Industry Member made as well as whether the FINRA Facility allows a trade report to be corrected without cancelling the original trade report. The different FINRA Facilities have different functionality with regards to correcting and cancelling trade reports. For more information on reporting cancellations, corrections, and reversals to the TRF/ADF/ORF, see Section 311 of FINRA’s Trade Reporting FAQs.

Below are descriptions and CAT reporting requirement for four different trade cancellation and correction scenarios. 

Scenario 1: An Industry Member executes a trade for 1,000 shares and correctly reports the MEOT to CAT for 1,000 shares but incorrectly reports the trade to a FINRA Facility for 100 shares. The FINRA Facility allows for corrections of trade reports without cancelling the original trade report and links the corrected trade report by reference to the original trade report. The Industry Member corrects the trade report to 1,000 shares without cancelling the original trade report and the Compliance ID or FINRA Control Number on the corrected trade report remains the same as the Compliance ID or FINRA Control Number on the original trade report.

In this scenario, the Industry Member is only required to report a single MEOT linking to the original trade report because the data in the MEOT was correct and it will link to the original trade report which will link by reference to the new trade report.

Scenario 2: An Industry Member executes a trade for 1,000 shares and correctly reports the MEOT to CAT for 1,000 shares but incorrectly reports the trade to a FINRA Facility for 100 shares. The FINRA Facility does not allow for corrections of trade reports so the Industry Member must cancel the original trade report and enter a new one. The Industry Member enters the same Branch Sequence Number on the corrected trade report as was on the original (cancelled) trade report. 

In this scenario, the Industry Member is only required to report a single MEOT because the data in the MEOT was correct and it will link to both the original (cancelled) trade report and the new trade report via the tapeTradeID/Branch Sequence Number since the Industry Member entered the same Branch Sequence Number on the corrected trade report as was on the original (cancelled) trade report.

Scenario 3: At 10 am, an Industry Member executes a trade at 9.99 and reports the MEOT to CAT with a price of 9.99. At 10:01 am, the Industry Member then realizes that the trade should have been executed at 9.98 so it cancels the original trade report and enters a new trade report at 9.98 and execution time of 10:01 am. 

In this scenario, the Industry Member is required to report two MEOTs- one linking to the original (cancelled) trade report and a second linking to the new trade report. Otherwise, the Industry Member will receive trade linkage errors. 

Scenario 4: An Industry Member executes a trade for 1,000 shares but incorrectly reports the MEOT to CAT for 100 shares and incorrectly reports the trade to a FINRA Facility for 100 shares. The FINRA Facility allows for corrections of trade reports without cancelling the original trade report and links the corrected trade report by reference to the original trade report. The Industry Member corrects the trade report to 1,000 shares without cancelling the original trade report and the Compliance ID or FINRA Control Number on the corrected trade report remains the same as the Compliance ID or FINRA Control Number on the original trade report.

In this scenario, the Industry Member is required to link the MEOT for 100 shares to the original trade report for 100 shares and then submit a correction (actionType= ‘COR’) of the MEOT to correct the share quantity to 1,000 shares. The ‘COR’ MEOT will link to both the original trade report and the corrected trade report via the tapeTradeID/Compliance ID or FINRA Control Number since the Industry Member entered the same Branch Sequence Number on the corrected trade report as was on the original (cancelled) trade report.
 

Yes.  FINRA rules and FINRA Facility system validations require that firms refer to the original trade report in the report of the reversal by including the control number assigned to the original report by the FINRA Facility and the original report date.  Because the reversal is linked by reference to the original trade, the Industry Member is not required to report the reversal to CAT by deleting the original MEOT.  The FINRA Facility Data reported to CAT by FINRA will be the source of the reversal.  After the reversal, if a new trade is reported to the FINRA Facility, a new MEOT would be required and must include a new tapeTradeID, irrespective of whether the execution date on the new trade report is the same as the original trade.

For more information on reporting cancellations, corrections, and reversals to the TRF/ADF/ORF, see Section 311 of FINRA’s Trade Reporting FAQs.
 

No, order events for order messages that cannot be read or parsed by the destination venue are not required to be reported to CAT by the sender or receiver.

There are designated handlingInstructions values for various auction-related order instructions. These values are intended to be mutually exclusive, and the CAT reporting requirements for each depends on the facts and circumstances of the scenario, as outlined in the below table:

A representative order is defined as an order originated by an Industry Member for the purpose of working one or more orders. Representative orders may be originated in firm owned or controlled accounts or a customer or client account.  

Examples of representative orders in firm owned or controlled accounts:

1. Order originated in a proprietary account to work an order on a riskless principal basis.
2. Order originated in a proprietary account to work an order on a net basis.
3. Order originated in a proprietary account to work one or more proprietary orders.
4. Order originated in a firm owned agency average price account to work an order(s) on an average price basis.
5. Order originated in a firm owned omnibus or agency average price account to aggregate and work multiple customer or client orders as a single order.

Example of a representative order in a customer or client account:

Order originated in a customer or client account or for a single Relationship ID to aggregate and work multiple orders from the same customer or client as a single order. In these instances, the Industry Member must report representative orders with representativeInd value of ‘Y’. Also, the resulting fulfillment events must be reported with fulfillmentLinkType value of ‘Y’.

See Appendix C of the Industry Member Technical Specification and Section 2.3 of the CAT Industry Member Reporting Scenarios document for detailed guidance and examples of how the representative orders must be reported.

No. The CAT Order Fulfillment report is not required to be linked to any related non-media riskless principal regulatory report. Because the street side order and any related media reported trades are linked to the related customer orders in CAT (subject to the phased implementation schedule), linkage of the CAT Order Fulfillment Report to the related non-media TRF report is not required. 

If an Industry Member’s order handling and/or reporting system does not allow for a route to be directly associated with the customer order or child order (with the same Order ID) and instead must generate/report a route from a separate order (with a different Order ID) created by the Industry Member for the purpose of working the customer order, then an Order Fulfillment should be used as described in Scenario 2.3.4 Fill of a Single Customer Order on an Average Price Basis in the CAT Industry Member Reporting Scenarios document.

More simply put, if an Industry Member is able to report the route directly linked to the customer order, the Industry Member should report Order Route events in accordance with Scenario 2.1.6. If the Industry Member is unable to report Order Route events, the Industry Member must report a representative order in accordance with Scenario 2.3.4.
 

In this scenario, the Industry Member must report four New Order Events to reflect the receipt of each customer order and an individual Order Fulfillment Event to show the fill of each customer order. Additionally, the Industry Member must report a New Order Event to reflect the aggregated representative order and any related Route Events. In Phase 2c, the street side representative order must be linked to the individual customer orders.

Yes, Industry Members are required to link a Representative Order with the underlying order(s) that it represents. Specifically, Industry Members are required to record and report to the Central Repository: (1) for original receipt or origination of a Representative Order, the CAT-Order-ID(s) and quantities of the underlying order(s), and whether linkage to the underlying order(s) is required, and (2) if the Representative Order is modified or cancelled, the CAT-Order-ID(s) and quantities of the underlying order(s). While all Representative Orders must be reported beginning in Phase 2a, the linkage requirements to the underlying orders will be phased in as described in the Industry Member Technical Specifications. 

All Industry Members will be required to provide representative order linkages to unlinked OMS/EMS and position fill scenarios no later than July 31, 2025 due to the expiry of the exemptive relief granted by the SEC on January 17, 2025.

As stated in FAQ F5, Industry Members are required to link a Representative Order with the underlying order(s) that it represents. There are limited instances where linkage is required at the client fill level rather than the order level using the Firm Designated ID (“FDID”) of the firm owned or controlled account from which the customer order was filled. Specifically, for orders that are originated in different systems that are not linked in an Industry Member’s systems, such as a customer order originated in an Order Management System (“OMS”) and represented by a principal order originated in an Execution Management System (“EMS”) that is not linked to the OMS, Industry Members are required to link the fill of the customer order to the FDID of the firm owned or controlled account that was used to originate and execute the Representative Order. Further, such Representative Orders must be reported to CAT with an indicator reflecting the order is eligible for customer fills from an unlinked system. Appendix C of the Industry Member Technical Specifications provides details of the required linkages in these workflows. 

All Industry Members will be required to provide representative order linkages to unlinked OMS/EMS and position fill scenarios no later than July 31, 2025 due to the expiry of the exemptive relief granted by the SEC on January 17, 2025. 

The only Representative Order workflow in which linkage is not required at either the order level or the fill level is that in which a firm receives a client order, guarantees an execution price (e.g., GVWAP) and then originates proprietary orders in an effort to work the client order. Because the client order may not ultimately be filled from the proprietary order(s) if the guaranteed price is not achieved, direct linkage is not required. Although direct linkage is not required to the client fill, the proprietary orders originated to work the client order must be marked as a Representative Order and designated as part of a price guarantee scenario. Appendix C of the Industry Member Technical Specifications provides the specific reporting requirements for price guarantee scenarios.
 

In representative order scenarios, the representativeInd field in a New Order event indicates the type of representative order being reported, and whether order level linkage is required. Order level linkage is specified through the aggregatedOrders field of the representative order’s New Order event, which identifies each related customer New Order event that is being represented. Fulfillment level linkage is identified through the fulfillmentLinkType field, which indicates the type of fulfillment and whether linkage is required. Fulfillment level linkage is specified through the firmDetails field in an Order Fulfillment event, and identifies the related representative order from which the fill was obtained.

Order level linkage does not determine fulfillment level linkage. A representative order may have order level linkage without fulfillment level linkage (e.g., unexecuted order), and may have fulfillment level linkage without order level linkage (e.g., a customer order filled from a pre-existing principal order such as a Manning execution, or in the case of a disconnected OMS/EMS). A representative order may also have both order and fulfillment level linkage with different values populated in the representativeInd and fulfillmentLinkType fields (e.g., the firm order originated to represent the order was not the order that was ultimately used to fill the customer order). Refer to Appendix C of the IM Technical Specifications for additional information.

All Industry Members will be required to provide representative order linkages to unlinked OMS/EMS and position fill scenarios no later than July 31, 2025 due to the expiry of the exemptive relief granted by the SEC on January 17, 2025.
 

Yes, a CAT Reporter is required to report two separate timestamps for Manual Order Events that are entered into an electronic system. If an order is received manually and then later entered into an electronic system for further handling and execution, the CAT Reporter must report both the manual receipt time and the Electronic Capture Time. Specifically, CAT Reporters are required to record and report: (1) the time of a Manual Order Event in increments up to and including one second; and (2) the time when a Manual Order Event has been captured electronically in an order handling and execution system of the Participant or Industry Member ("Electronic Capture Time") in milliseconds. (See Section 6.8 of the CAT NMS Plan available at SEC Approved CAT NMS Plan (11/15/2016))

No. Orders received manually by an Industry Member, such as via the telephone, and then entered by the Industry Member into its clearing firm’s system are considered manual orders received by the correspondent and routed electronically to the clearing firm. As such, the correspondent Industry Member would report a New Order event with the manualFlag set to ‘true’ and an Order Route event with the manualFlag set to ‘false.’ The clearing firm would report an Order Accept event with the manualFlag set to ‘false.’

The manualFlag field identifies if an order was received manually or electronically. If the manualFlag is set to ‘true,’ then the eventTimestamp may be reported in second granularity. If the manualFlag is set to ‘false’, then the eventTimestamp must be reported to at least the millisecond granularity. Additionally, if an event is received manually and then captured electronically, then the manualFlag must be set to ‘true’, the eventTimestamp field populated with the time of receipt and the electronicTimestamp field must be populated with the time the order was electronically captured.

Yes. In this scenario, the manual time of order receipt and the Electronic Capture Time are the same because the Industry Member broker has entered the order into his/her firm’s order handling and execution system simultaneously with the receipt of the order. The Industry Member is required to report both the manual time of order receipt and the Electronic Capture Time, and the same timestamp should be reported in both fields in milliseconds.

If, however, there is a delay between the time the Industry Member broker receives the order on the telephone and the time in which the broker enters the order into his/her firm’s order handling and execution system, then the Industry Member must report two distinct timestamps, one for the manual time of order receipt and one for the Electronic Capture Time, as described above in FAQ G.1.

Each time an Industry Member reprices a peg order based on a market move (e.g., when there is a change in the national best bid or offer or the best bid or offer on a particular exchange, as applicable based on the terms of the order), the Industry Member must report a price modification of the peg order to the CAT pursuant to Section 6.3(d) of the CAT NMS Plan, as applied to Industry Members by Section 6.4(d)(i) of the CAT NMS Plan, if the price is modified. If the Industry Member does not reprice a peg order when the market moves, the Industry Member does not need to report a modification of the peg order to the CAT since the order was not modified by either the customer or the Industry Member. For example, for both displayed and non-displayed alternative trading systems (ATSs), if an ATS’s matching engine reprices a peg order when the market moves, the price modification must be reported to the CAT. If a matching engine does not reprice a peg order when the market moves, there is no requirement to report a price modification to the CAT.

Example 1: A display ATS receives a buy order with a primary peg instruction and a limit price of $10. The current market is 9.98 and accordingly, the order is displayed at 9.98. The NBB subsequently moves to 9.99. The ATS reprices the order and re-displays it at 9.99. The re-pricing of this order must be reported to CAT by the ATS.

Example 2: An ATS receives a buy order with a primary peg instruction and a limit price of $10. The order is not displayable or routable and the ATS has no sell orders that are eligible to trade with the buy order. The NBB subsequently moves to 9.99 and the ATS receives no other sell orders that are eligible to trade with the buy order. The ATS takes no action on the open buy order when the NBB moves to 9.99, therefore there is no CAT reportable event.

Example 3: An ATS receives a buy order with mid-point peg instruction when the NBBO is 9.85 x 10. The order is not displayable or routable and the ATS has no sell orders that are eligible to trade with the buy order. The NBBO subsequently moves to 9.90 x 10. The ATS then receives a market order to sell that is eligible to trade with the buy order and the two orders are crossed at 9.95. Because the ATS did not re-price the buy order prior to executing it, there is no CAT reportable event required to reflect a price modification of the buy order to 9.95.

Yes. FINRA member ATSs must use the ATS MPID when reporting ATS activity to CAT.

The nbboTimestamp field should be populated with the time that the ATS referenced, or "looked up" the existing reference price.

Example: 

A sell order is received by an ATS at 10:00:00:007.  The ATS must then identify the NBBO in effect to determine if the order is marketable. The relevant times are as follows:
9:57:47.768    NBBO becomes 10 bid, 10.02 offer 1×1
9:58:23.324    NBBO is updated to 10 bid, 10.02 offer 5 x1
10:00:01.490    
NBBO is updated to 10.01 bid, 10.03 offer 1 x 1
ATS Order Receipt Time:    10:00:00:007
ATS looks up existing NBBO:    10:00:00.008
The ATS should report a timestamp of 10:00:00.008 in the nbboTimestamp field and an NBBO in effect at time of order receipt of 10 bid, 10.02 offer.  The size is not required to be reported but is optional.

Since the display is not on an order by order basis, an ATS that only displays aggregate level pricing information at pre-determined intervals of time is not required to report order display modifications to CAT.

Because the order was cancelled before the ATS referenced the NBBO (or other applicable reference price), there would be no such information to report.  Therefore, the ATS should populate the nbboSource field with “NA”.

One sided or invalid prices should be reflected as zero.  The time the ATS referenced the NBBO (or other relevant reference price) and NBBO source must still be reported.

If the ATSs’ Order Type encompasses the handling instruction, then the handlingInstructions field would not be required. For example, if ATS 1 has an Order Type that is NBBO midpoint peg, add liquidity only, then the handling instruction of Add Liquidity Only ("ALO") would not be necessary since the Order Type includes the add liquidity only restriction.

The origination or receipt of an order involving any security that meets the definition of an NMS security pursuant to SEC Rule 600 must be reported to the CAT, regardless of where the order is ultimately executed. This includes any NMS security that is also listed on a foreign exchange (“dually listed”). If the order is sent to a foreign market for execution, the CAT Reporter is required to report the relevant Reportable Events for the order (e.g., origination or receipt of the order and the routing of the order to the foreign market). All prices must be converted into U.S. dollars based on the conversion rate applicable at the time of the transaction.

Orders in foreign securities that are OTC Equity Securities are required to be reported to the CAT where the resulting execution is subject to transaction reporting under FINRA Rule 6622. Pursuant to FINRA Rule 6622(g), the following transactions in foreign securities that are OTC Equity Securities are not reportable: (1) the transaction is executed on and reported to a foreign securities exchange; or (2) the transaction is executed over-the-counter in a foreign country and reported to the regulator of securities markets of that country. CAT reportable orders in foreign securities that are OTC Equity Securities must be reported to CAT using the US symbol, and all prices must be converted into U.S. dollars based on the conversion rate applicable at the time of the transaction.
 

Because the resulting execution of the order was subject to transaction reporting under FINRA Rule 6622, both the routing firm and the firm ultimately executing the order have a CAT reporting obligation, and must report the order to CAT using the US Symbol and the price in US Dollars.

If, by the end of the CAT Trading day, the Industry Member does not know the market of execution, or if the destination venue has not informed the broker-dealer of the market of execution, the Industry Member will have an obligation to report all order events for that order to CAT. Refer to FAQ I4 for additional guidance if the market of execution is not known by the end of the CAT Trading day.

Orders received for foreign securities that are OTC Equity Securities must be reported if any resulting executions are subject to transaction reporting under FINRA Rule 6622. CAT reportable orders for foreign securities that are OTC Equity Securities must be reported to CAT using the US symbol and price in US dollars.

In this example, part of the order is executed over-the-counter in the US by the Industry Member and is therefore subject to transaction reporting under FINRA Rule 6622, and the other part of the order is executed and reported in the foreign market and therefore not subject to transaction reporting under FINRA Rule 6622. Thus, the firm would have an obligation to record and report a New Order event reflecting the receipt of the order, an Order Route event for each component sent abroad, an Order Fulfillment event for the portion executed and reported abroad, and a Trade event for each component executed by the Industry Member in the US.

Refer to FAQ I4 for additional guidance if the market of execution is not known by the end of the CAT Trading day.

Yes. As stated in FAQ I1, orders received for foreign securities that are OTC Equity Securities must be reported if any resulting executions are subject to transaction reporting under FINRA Rule 6622. If an order is received in the US symbol and the market of execution is not known by the end of the CAT Trading day on which the order was received, all events for the order must be reported to CAT. 

For example, if a firm receives an order in a foreign security that is an OTC Equity Security that is routed to a foreign market, and the order is not executed before the time the firm is required to report to CAT (i.e. the firm does not know if there will ultimately be a transaction reporting requirement under FINRA Rule 6622), then the firm should submit the New Order event and Order Route event to CAT. If the order is later fully or partially executed and reported in a foreign market, since an Order Route event was previously reported to CAT, the firm would submit an Order Fulfillment event indicating that the order was filled on the foreign market, as applicable.

Refer to FAQ I6 for guidance on orders that can only be executed and reported in a foreign market.

Industry Members receiving orders in foreign equity securities without a US symbol for which they have a trade reporting obligation must: 1) promptly request a symbol; and 2) comply with the CAT recording requirements under the Plan. Once a symbol becomes available, the Industry Member must report the trade to FINRA pursuant to FINRA Rule 6622 and report all applicable information to CAT in accordance with the Plan. Data submitted to CAT with an Event Timestamp prior to the symbol issuance date will not be marked late. Industry Members may, however, be asked to demonstrate that a symbol was promptly requested upon execution of the trade.

No. If the terms of the directed order require the firm to execute the order in a foreign market, and the firm knows that the order will be executed and reported in the foreign market (and thus not subject to transaction reporting under FINRA Rule 6622), the firm would not be required to report to CAT any events related to that order.

If the firm has decided to send the order to a foreign market to be executed and reported (and thus there would be no transaction reporting requirement under FINRA Rule 6622), the firm would not be required to report to CAT any events related to that order. However, if, for any reason, the order is ultimately executed in the US (and thus subject to transaction reporting under FINRA Rule 6622), the firm would be required to submit all CAT reportable events related to that order with the original time of order receipt as the eventTimestamp. CAT will mark these events late. Firms that display a pattern or practice of reporting orders late may be subject to formal review for potential violations of the CAT Rules.

The receiving US broker-dealer is required to report the receipt of an order from a non-US broker-dealer in the same way as it would report the receipt of an order from a Customer. Specifically, the receiving US broker-dealer would report the receipt of this order as the original receipt of the order from the non-US broker-dealer, and the receiving US broker-dealer would report the Firm Designated ID of the Customer, which is the non-US broker-dealer. The US broker-dealer would not report the ultimate customer of the non-US broker-dealer.

If a Reportable Event is priced in a non-U.S. dollar currency, CAT Reporters are required to convert such prices into U.S. dollars based on the conversion rate applicable at the time that the Reportable Event occurred and report the prices in US dollars to the CAT. Although a specific conversion methodology is not prescribed, any methodology must be applied consistently by the Industry Member. 

The senderType field on an Order Accepted event (MEOA) must only be populated with a value of ‘O’ when the receiving party is voluntarily reporting an order in the OTC Equity symbol of a foreign security that was not required to be reported to CAT because it was executed outside the U.S. Any Order Accepted event that was required to be reported to CAT and received from another Industry Member must be populated with a senderType value of ‘F’. The senderType value of ‘O’ must not be used as a default for all orders in foreign equity securities that are routed between Industry Members; it should only be used in the manner described above. Refer to the Industry Member Scenarios Document for further details.

The destinationType field on an Order Route event (MEOR) must only be populated with a value of ‘O’ when an order for the OTC Equity symbol of a foreign security is routed between Industry Members and the routing party does not provide instructions on where the order should be executed and does not know if the receiving party will have a reporting obligation. If an order in the OTC Equity symbol of a foreign security is not eligible to be executed outside the United States, then the destinationType value of ‘F’ must be used. The destinationType value of ‘O’ must not be used as a default for all orders in foreign equity securities that are routed between Industry Members; it should only be used in the manner described above. Refer to the Industry Member Scenarios Document for further details.  

Quotations in OTC equity securities sent to foreign exchanges are required to be reported only in those instances where a resulting execution is subject to the transaction reporting requirements in FINRA Rule 6622. The requirements of FINRA Rule 6622 do not apply to transactions in foreign equity securities that are not NMS Stocks provided that: (1) the transaction is executed on and reported to a foreign securities exchange; or (2) the transaction is executed over the counter in a foreign country and is reported to the regulator of securities markets in that country.

Pursuant to Section 6.3(d) of the CAT NMS Plan (“Plan”), as applied to Industry Members by Section 6.4(d) of the Plan, Industry Members must report certain details to the CAT for each order and reportable event. These requirements are applied to Industry Members via each Plan Participant’s CAT Compliance Rules. 

“Order,” as used in the Plan and the CAT Compliance Rules, is defined by SEC Rule 613(j)(8) to include “[a]ny order received by a member of a national securities exchange or national securities association from any person; [a]ny order originated by a member of a national securities exchange or national securities association; or [a]ny bid or offer.” SEC Rule 300 more specifically defines “order” as “any firm indication of a willingness to buy or sell a security, as either principal or agent, including any bid or offer quotation, market order, limit order, or other priced order.” Note that neither indications of interest (“IOIs”) nor requests for quotes (“RFQs”) fall within the definition of an order. See, e.g., CAT FAQs B3 and B38. A “reportable event” is defined by SEC Rule 613(j)(9) to “include, but not be limited to, the original receipt or origination, modification, cancellation, routing, and execution (in whole or in part) of an order, and receipt of a routed order.”

Messages sent through OTC Link ATS constitute “orders,” as defined above, for purposes of CAT reporting obligations to the extent such messages represent a “firm indication of a willingness to buy or sell a security.” OTC Link ATS and the OTC Link ATS broker-dealer subscribers are required to report all applicable CAT reportable events relating to such orders, both executed and unexecuted.

As set forth in Table 1 (Industry Specifications Phased Approach) of the Industry Member Technical Specifications, all OTC Link messages are reportable as orders starting in Phase 2d. Detailed reporting scenarios are available in the Phase 2d Industry Member Reporting Scenarios document. 

OTC Link trade messages directed by an OTC Link ATS subscriber to OTC Link ATS in response to a Global OTC quote meet the definition of an order. Because an immediately actionable order is sent to Global OTC as the result of an OTC Link message, the OTC Link ATS subscriber must report the order and route, even if the order is not ultimately executed. Under the Industry Member CAT Reporter phasing schedule, OTC Link ATS subscribers would have an obligation to report to CAT a New Order event and Order Route event for each OTC Link trade message directed by the OTC Link ATS subscriber to OTC Link ATS in response to a Global OTC quote, both executed and unexecuted, beginning in Phase 2a.

However, the Participants are aware that not all Industry Members fully understood that OTC Link trade messages directed by the OTC Link ATS subscriber to OTC Link ATS in response to a Global OTC quote constitute orders (and not negotiations). Given this, the Participants are deferring until Phase 2c the obligation for OTC Link ATS subscribers to report these messages as set forth above. In other words, in Phase 2a, Industry Members can either:

-Report OTC Link trade messages that they direct to OTC Link ATS in response to a Global OTC quote to CAT as negotiated trades. If an OTC Link trade message directed by an OTC Link ATS subscriber to OTC Link ATS in response to a Global OTC quote results in an execution, the OTC Link ATS subscriber would report a New Order event and a Trade event to CAT. While this may generate interfirm linkage errors beginning in October 2020, Industry Members will not be expected to correct such errors, and such errors will not be considered for Industry Member compliance purposes. 

-An Industry Member would have the option – but would not be required to – report a New Order event and Order Route event for these messages in Phase 2a. 

Beginning in Phase 2c, OTC Link ATS subscribers must report a New Order event and Order Route event to CAT for all OTC Link trade messages that they direct to OTC Link ATS in response to a Global OTC quote, both executed and unexecuted. Further, the Order Route event must indicate a route to OTC Link ATS and contain the handlingInstructions value ‘J3’. Global OTC would have an obligation to report an Order Accepted event indicating receipt from OTC Link ATS for each trade message received. Further, the handlingInstructions value on the Order Accepted event must contain the value ‘J3’. Since OTC Link ATS does not have a CAT reporting obligation in Phase 2c, the ‘J3’ handlingstructions value is designed to prevent interfirm linkage errors in Phase 2c. Beginning in Phase 2d, OTC Link ATS will report receipt of the order from its subscriber and the route to Global OTC. Thus, in Phase 2d, the handlingInstructions value ‘J3’ will no longer be required and will be removed as an allowable value. 

Please refer to the Phase 2c and Phase 2d Industry Member Reporting Scenarios for additional details.

Orders submitted directly to Global OTC by Global OTC subscribers are reportable as all other orders commencing in Phase 2a.
 

Starting in Phase 2d, the New Quote event (MENQ) is used to report:

• Quotes in OTC equity securities sent to an inter-dealer quotation system operated by an Industry Member
• Any other electronic quotes which are provided by or received in a CAT Reporter’s order/quote handling or execution systems in CAT reportable securities and are provided by an Industry Member to other market participants off a national securities exchanges, as described in CAT

Quotations that are initially opened prior to and still in effect on December 13, 2021 at the commencement of Phase 2d are required to be reported to the CAT on a go-forward basis starting on December 13, 2021. For example, on December 8, 2021, Industry Member 1 sends a quote in an OTC equity security to an inter-dealer quotation system (IDQS) operated by another Industry Member. If the quote remains in effect on the IDQS at the start of Phase 2d reporting obligations on December 13, 2021, and Industry Member 1 opens to quote at the start of day, then Industry Member 1 must report a New Quote event (MENQ) following the quote being opened for the first time on or after December 13, 2021. Any subsequent opening or closing of the quote must be reported on a quote status event.

An Automatic Process would be any process in which the Industry Member inter-dealer quotation system (IDQS) automatically takes action on behalf of the Industry Member either as part of an end of day process, or as a result of the receipt of a bulk message. For example, if the IDQS automatically closes a quote on behalf of an Industry Member at the end of the day, only the IDQS would have the requirement to report a Quote Status event to CAT. If the IDQS opens all quotes on behalf of an Industry Member at the start of the day as a result of a bulk open message received from that Industry Member, only the IDQS would have the requirement to report a Quote Status event to CAT. 

If an Industry Member manually actions the status to open or close a quote through an individual FIX message directed at that specific quote, or through the GUI platform, this would not be considered an ‘Automatic Process’, and both the Industry Member actioning the quote and the IDQS would be required to report a Quote Status event to CAT.

Quotes entered directly into the OTC Link IDQS via OTC Link IDQS’s Dealer Application are captured in a structured electronic format. The SEC’s July 28, 2023 Exemptive Relief Order grants temporary conditional relief from reporting “unstructured electronic and verbal communications that are not currently captured by Industry Member order management of execution systems” until July 31, 2026. As quotes entered directly in the OTC Link IDQS via OTC Link IDQS’s Dealer Application are structured, they are not covered by the SEC’s Order and are reportable beginning in Phase 2d. Because these quotes are entered manually into the Dealer Application, they are considered to be manually originated and manually routed. As such, the Industry Member entering a quote directly into the OTC Link IDQS via the Dealer Application would report a New Quote event with the manualFlag set to ‘true’ and a Routed Quote event with the manualFlag set to ‘true’. The OTC Link IDQS would report a Quote Received event with the manualFlag set to ‘true’.

OCC data regarding symbology and corporate actions will be included in the CAT.

During Phase 2b of the revised implementation schedule, Industry Members will be required to report to the CAT Industry Member Data related to Eligible Securities that are options and that are related to Simple Electronic Option Orders, excluding Electronic Paired Option Orders. “Simple Electronic Option Orders” mean orders to buy or sell a single option that are not related to or dependent on any other transaction for pricing or timing of execution that are either received or routed electronically by an Industry Member CAT Reporter. A “Paired Option Order” is defined for CAT reporting purposes as an electronic simple or multi-leg option order that contains both the initial and contra side that is routed as a single message to an exchange for crossing and/or price improvement. Further, the events related to Simple Electronic Option Orders subject to reporting in Phase 2b are limited to those events which involve electronic receipt of an order, or electronic routing of an order. Electronic receipt of an order is defined as the initial receipt of an order by an Industry Member in electronic form in standard format directly into an order handling or execution system. Electronic routing of an order is the routing of an order via electronic medium in standard format from one Industry Member’s order handling or execution system to an exchange or another Industry Member.

Yes. Responses to auctions of simple orders and paired simple orders are reportable in Phase 2b. The order must be reported with a handlingInstructions value of ‘AucResp’ and the Auction ID must be reported in a Name/Value Pair.

No. Option assignments (the exercise of options contracts) are not orders, as defined by SEC Rule 613. Therefore, option assignments are not required to be reported to CAT.

In Phases 2a, 2b and 2c the ‘OPT’ handlingInstructions value is to be used in instances involving a combination trade in which the cash leg is the second leg of the transaction and the terms and conditions of the cash order are contingent upon the related option trade. In other words, the ‘OPT’ value is appropriate when the price or size of a cash order is contingent upon a related option trade. The value is not intended to be used in conjunction with option exercises or assignments, which do not constitute CAT Reportable Events. The value would only be appropriate for a Buy/Write if, as explained above, the terms and conditions of the cash order were contingent upon the related option transaction. The reporting requirements of this scenario will change in Phase 2d when Buy/Writes are required to be reported as multi-leg/complex options orders.

Suppose that an Industry Member receives a simple electronic order for a Listed Option. The Industry Member then engages in a solicitation process to identify a contra party to pair the order against for execution on an exchange, and one or more market participants respond to the solicitation of interest. The Industry Member selects one or more of the responding market participants’ order(s) to execute against the original order, and sends a paired order(s) to an exchange for execution. The Industry Member that received the original simple electronic order must report the receipt of the simple electronic order in Phase 2b. The Industry Members providing responses to the solicitation of interest do not have any reporting requirements in Phase 2b. In Phase 2b, the Industry Member soliciting interest must report any simple electronic order received as the result of the solicitation process that is selected and sent on for execution using a handlingInstructions value of ‘SR’ (Solicitation Response). The routing of the paired order to the exchange would not be reportable until Phase 2d. However, if the original and contra-side solicited orders are routed to the exchange as unpaired, simple electronic orders, route events must be reported for each of the orders in Phase 2b. 

Suppose that an Industry Member receives a complex order including an equity leg. The Industry Member then engages in a solicitation process to identify a contra party to pair the order against, and one or more market participants respond to the solicitation of interest. The Industry Member selects one or more of the responding market participants’ order(s) to execute against the original order and sends a paired order(s) to an exchange for execution. The Industry Member that received the original complex order must report the receipt of the equity leg component of the complex order in Phase 2a with a handlingInstructions value of ‘OPT’. The Industry Members providing responses to the solicitation of interest do not have any reporting requirements in Phase 2a/2b. In Phase 2a, the Industry Member soliciting interest must report any equity leg received as the result of the solicitation process that is selected and sent on for execution using handlingInstructions values ‘SR’ (Solicitation Response) and ‘OPT’. The routing of the options legs of the complex order to the exchange would not be reportable until Phase 2d. However, the routing of the equity leg to the exchange or another Industry Member is reportable in Phase 2a.

Industry Members must report all responses to solicitation to CAT beginning in Phase 2c. Refer to FAQ B45 and the Phase 2c Industry Member Reporting Scenarios document for additional information.

Options Market Makers generally are not required to report open/close indicators on orders represented on/sent to an exchange. The CAT NMS Plan states that the open/close indicator does not need to be reported to CAT as part of the material terms of an order for Options Market Makers quotations. However, if exchange rules require an options market maker to include an open/close indicator when submitting orders to the exchange, Options Market Makers should submit the indicator for their orders to CAT as well.

Section 6.4(d)(iii) of the CAT NMS Plan, which describes the exemption for Options Market Maker quotes, states that “[w]ith respect to the reporting obligations of an Options Market Maker with regard to its quotes in Listed Options, Reportable Events required pursuant to Section 6.3(d)(ii) and (iv) shall be reported to the Central Repository by an Options Exchange in lieu of the reporting of such information by the Options Market Maker.” Section 6.4(d)(iii) also requires that, pursuant to the Compliance Rules of the Options Exchanges, Options Market Makers are required to report to an Options Exchange the time at which a quote in a Listed Option is sent to the Options Exchange (including any applicable quote modifications and/or cancellation time when such modification or cancellation is originated by the Options Market Maker). Such time information shall be reported to the Central Repository by the Options Exchange in lieu of reporting by the Options Market Maker.

The Options Market Maker exemption set forth in Section 6.4(d)(iii) applies to Options Market Maker quotes. Each Options Exchange determines which messages from Options Market Makers are subject to this provision pursuant to its rules. For additional information regarding the messages that each Options Exchange will report to the CAT on behalf of Options Market Makers and applicable protocols, please see: 

Yes. While manual options events are not required until Phase 2d, Industry Members may choose to report their manual options activity to CAT in Phase 2b. Industry Members may choose to report all of their manual options order activity, or may choose to report manual options activity on an order-by-order or system-by-system basis. However, as with all data reported to the CAT manual options activity voluntarily reported in Phase 2b must be timely, accurate and complete. Further, the prior/next unlinked fields must not be populated on reported orders events within the same intrafirm lifecycle immediately preceding or following a voluntarily submitted manual option event. Manual options activity reported in Phase 2b will be included in the firm’s error rate. Additionally, any rejected or unlinked manual options events must be corrected and resubmitted accordingly.

In Phase 2b, the Industry Member may populate any of the side values applicable to sell orders (i.e., SL, SS, SX). Starting in Phase 2d, the only value applicable to options sell orders is 'S'. 

Proprietary orders that are simultaneously entered into an OMS/EMS upon origination are always considered electronic. However, in Phase 2b it will be acceptable to report such events as either manual or electronic. Therefore, if an Industry Member has interpreted proprietary options orders manually entered into an OMS/EMS as manual events for Phase 2b, it will be acceptable to treat such events as manual in Phase 2b. Accordingly, if a proprietary order is routed electronically and the Order Route event is reported in Phase 2b, the priorUnlinked field must be populated. Beginning in Phase 2d, proprietary orders manually initiated and simultaneously entered into an OMS/EMS must be reported to CAT as electronic events.

Orders that are not part of a complex (multi-leg) order but are contingent on the execution of another order must be reported with a handlingInstructions value of ‘CND’ populated on the New Order event.  This guidance applies for contingent orders involving just equities, just options or both equities and options.   

This scenario is different from the ‘OPT’ handlingInstructions value which must be used to report the equity leg of a multi-leg order involving an option in Phase 2a, where the price or size of a cash order is contingent upon a related option trade, such as a Buy/Write. The reporting requirements for ‘OPT’ use in this scenario will change in Phase 2d when such orders must be reported as multi-leg orders.

To provide flexibility, CAT will accept the net price of a multi-leg strategy order as either a “per unit” amount, “total strategy” or “total cash” amount.

In most cases, a multi-leg strategy is represented with the leg ratios in their simplest form, and the order quantity representing the number of strategy “units” the customer or firm is looking to execute.  The “per unit” price represents each set of legs as defined in the CAT MLEG record.

The “Per Unit” priceType value indicates that the price provided is for the leg ratio as defined in the legDetails block. This example is selling a calendar spread for a $0.35 net credit 200 times.

           Order Qty = 200
           Leg 1: Buy 1 XYZ Jan calls @ 1.15
           Leg 2: Sell 1 XYZ Mar calls @ 1.50

           Per Unit net price = $.35 Credit

The “Total Strategy” priceType value indicates that the price provided on the event represents the total execution price of fully executing all legs.

          Leg 1: Buying 200 XYZ Jan calls @ 230
          Leg 2: Selling 200 XYZ Mar calls @ 300

         Total Strategy net price = $70 Credit

The “Total Cash” priceType value indicates that the price provided on the event represents the total dollar price to fully execute and clear all legs.  This includes the option multiplier (generally 100) for all option legs.

          Leg 1: Buying 200 XYZ Jan calls for $23,000
          Leg 2: Selling 200 XYZ Mar calls for $30,000

          Total Cash net price = $7,000.00 Credit

These numbers are mathematically equivalent and simply allow flexibility in CAT reporting to match how orders may be held in some trading systems.

Equity Leg Calculations

Equity legs prices are normalized to option pricing conventions in strategy level pricing, meaning that the ratio adjusted equity leg price is divided by 100 to give a ‘contract adjusted’ value.

In the example above, the “Per Unit” priceType value indicates that the price provided is for the leg ratio as defined in the legDetails block. This example is selling a call and buying the underlying stock for a $6.50 net debit.

           Order Qty = 2
           Leg 1: Buy 75 XYZ @ 10 = $750/100 = 7.50
           Leg 2: Sell 1 XYZ Mar calls @ 1.00 = 1

           Per Unit net price = $3.50 Debit

The “Total Strategy” priceType value indicates that the price provided on the event represents the total execution price of fully executing all legs.

          Leg 1: Buying 150 XYZ @ 10 = 1500/100 = 15.00
          Leg 2: Selling 2 XYZ Mar calls @ 2.00

          Total Strategy net price = $13 Debit

The “Total Cash” priceType value indicates that the price provided on the event represents the total dollar price to fully execute and clear all legs. This includes the option multiplier (generally 100) for all option legs.  There is no multiplier for the equity leg.

          Leg 1: Buying 150 XYZ for $1500
          Leg 2: Selling 2 XYZ Mar calls for $200

          Total Cash net price = $1300 Debit
 

In a scenario where a customer sends a complex order, and that customer has different accounts for the options and equities activity, the Industry Member must capture the FDID on the Multi-Leg New Option Order event (“MLNO”) with the FDID of the account in which the options portion of the multi-leg order is handled. Upon allocation, the party performing the allocation will be required to separately report the allocation of each equity leg (Post Trade Allocation event(s), “MEPA”) and each option leg (Option Post-Trade Allocation events, “MOPA”), and must capture the FDID of the exact account where the shares are booked. 

The CAT NMS Plan requires the trade event to be reported with the “time of execution”. Each exchange has different rules governing open outcry trading on the exchange floors. Thus, the eventTimestamp should be the execution time as recognized per the rules of the exchange on which the trade was executed.

The eventTimestamp must be reported with a minimum precision of seconds.  If the eventTimestamp is captured in more precise granularity, it must be reported to that level of precision (up to nanoseconds).  Please see FAQ B2 for more information about timestamp granularity.
 

No. The electronicTimestamp field is not required when reporting manual trade events for options or equities. The timestamp for electronic capture of the trade is provided on the corresponding trade event reported by the TRF or the exchange.

Starting in Phase 2d, Industry Members must use the ‘PBG’ handlingInstructions value when the customer instruction is to determine the limit price for an option order based on option Greeks (e.g., Delta, Vega) or other formula based on market conditions. These events must be reported using the orderType of ‘LMT’ and price of ‘0’. The specific option Greek value or formula related to the order is not required to be reported. 

If the instruction from the customer is to trade using a trading algorithm based on option Greeks, then the firm must report ‘ALG’ instead of ‘PBG’ handlingInstructions.
 

The pairedOrderID field is required on Option and Multi-leg Order Route events for orders that are routed electronically as a single message containing both the initial and contra side orders for simple or multileg options directly to an exchange for crossing and/or price improvement.

Industry Members may optionally populate the pairedOrderID field on Option, Multi-leg or Equity Order Route events for orders that are routed to another Industry Member, if two or more offsetting orders are sent with instructions to cross. These offsetting orders may be routed as either a single electronic message, individual electronic messages or manually conveyed to another Industry Member.

The pairedOrderID field is not required on Option, Multi-leg or Equity Order Accepted events reported by Industry Members. The pairedOrderID field may be optionally populated if two offsetting orders are received with instructions to cross.

On a MOOT event, the cancelFlag must be populated with ‘true’ when an Industry Member executes a manual option trade on an exchange floor, and that trade is subsequently cancelled.

The cancelTimestamp must reflect the timestamp that the exchange cancelled the trade.
 

Some Industry Members have systems that allow for the entry of algorithmic strategy trading instructions with parameters that do not include all material terms of a CAT reportable order for any component security, such as quantity. If an Industry Member has given instructions for such a strategy and no further action is required on the Industry Member’s part to generate an order for a particular component security, the Industry Member is required to report a new order event (MONO or MENO) and an order route event (MOOR or MEOR) for each component security included in the strategy as eligible to trade, even though all the material terms for an order in a given component security may not be known at the time. The Industry Member receiving such instructions is required to report order accepted events for each component security included in the strategy, again, even though all the material terms for an order in a given component security may not be known at the time. Although all material terms may not be known, both Industry Members are to report those material terms discernable from the strategy instructions.

Example 1
Broker 1 uses a Vega algorithm provided by Broker 2 and within Broker 2’s system stipulates a list of 10 option series that are eligible for Broker 2 to generate orders to trade on Broker 1’s behalf. No further action is required on Broker 1’s part to generate any order for a particular series. Broker 1 would report a MONO and a MOOR for each option series provided in the list of eligible securities within the algorithmic parameters, even though all material terms for an order in a given component security may not be known at the time.

Broker 2 will report a corresponding order accepted event (MOOA) for each of the 10 option series provided as eligible component securities, again, even though all material terms for an order in a given component security may not be known at the time.

Each order event above must be marked as follows:

When Broker 2’s algorithm generates specific orders for any of the eligible securities and routes those orders to an exchange or another Industry Member, Broker 2 must report an order route event (MOOR) related to the order accepted event (MOOA) for the specific eligible security reported to reflect receipt of the order from Broker 1.

If Broker 2’s algorithm does not ultimately generate any specific order(s) in an eligible option series, no further reporting is required by either Broker 1 or Broker 2 for that series. If Broker 1 or Broker 2 cancels or modifies the trading instruction, then a cancel or modify event would be required for each applicable component option series following existing guidance for the reporting of cancel events.

Example 2
A non-broker-dealer customer uses a Vega algorithm provided by Broker 2 and within Broker 2’s system stipulates a list of 10 option series that are eligible for Broker 2 to generate orders to trade on the non-broker-dealer customer’s behalf. No further action is required on the customer’s part to generate any order for a particular series. Broker 2 would report a MONO for each option series provided in the list of eligible securities within the algorithmic parameters, even though all material terms for an order in a given component security may not be known at the time. The MONO event must be marked as noted in the table above.

When Broker 2’s algorithm generates specific orders for any of the eligible securities and routes those orders to an exchange or another Industry Member, Broker 2 must report an order route event (MOOR) related to the new order event (MONO) for the specific eligible security reported to reflect receipt of the order from the non-broker-dealer customer.

If Broker 2’s algorithm does not ultimately generate any specific order(s) in an eligible option series, no further reporting is required by Broker 2 for that series. If the non-broker-dealer customer or Broker 2 cancels or modifies the trading instruction, then a cancel or modify event would be required for each applicable component option series following existing guidance for the reporting of cancel events.

At this time, the above-described algorithmic strategy trading instructions are reportable to CAT. Should the Participants determine in the future that such instructions are not reportable to CAT, the reporting guidance may change.
 

An example of this might be an index option strategy where a particular option series is to be traded with a “delta hedge” combination where the specific option contracts that constitute the delta hedge are not predetermined. Net price and full leg details are known for at least one leg of the strategy (e.g., B/S, quantity, contract, open/close) when the sending Industry Member communicates the instruction to the receiving Industry Member and no further action is required on the sending Industry Member’s part to generate any order for the options series that make up the combination. Instead, the receiving Industry Member must determine the remaining legs (e.g., for the specific combination). 

Although this strategy does not contain the specific contracts used to form the delta hedge combination, the Industry Members must report the leg(s) that are known at the time the strategy is given. Once the receiving Industry Member selects the specific contracts that will make up the combination, the receiver must report a full multi-leg order with all leg details.

Example
Broker 1 calls Floor Broker 2 with a strategy to sell 200 INDX March 4250 calls along with a delta hedge. The delta hedge portion of the strategy has not been defined by Broker 1, and would instead be identified by Floor Broker 2 based on market conditions (e.g., after getting indications from the trading floor) using two option contract series - sometimes referred to as a “combo order” – buying a call and selling a put with the same expiration date and strike price, and having the same underlying index as the primary order.

At the time Broker 1 provides Floor Broker 2 with a firm authorization to trade, Broker 1 must report a Multi-Leg New Order (MLNO) event and a Multi-Leg Order Route (MLOR) event. Both events must be marked with the ‘SLL’ (Strategy Legs Later) value in the handlingInstructions field and the eventTimestamp of the MLOR event must represent the time Broker 1 instructed Floor Broker 2 to trade on its behalf.

When reporting the MLNO and MLOR events, Broker 1 must include the full details of the leg(s) that are known at the time the instruction to trade is given. In the example above Broker 1 would report multi-leg order events that includes one leg – selling 200 INDX March 4250 calls.

Floor Broker 2 reports a Multi-Leg Order Accepted (MLOA) event that includes the leg that is known at the time Broker 1 provided authorization to trade. The MLOA event must be marked with the handlingInstructions value of ‘SLL’ (Strategy Legs Later) to indicate that the original instruction to trade was provided without all leg instruments specified and the eventTimestamp of the MLOR event must represent the time Broker 1 instructs Floor Broker 2 to trade on its behalf.

Upon determining the specific contracts that would make up the combo, Floor Broker 2 systematizes the receipt of an order for the entire strategy (i.e., the primary series and the two series that make up the combo). Floor Broker 2 then trades the order and reports any activity according to existing guidance.

At this time, the above-described multi-leg strategy is to have a CAT reportable event at the time the known legs are first communicated from Broker 1 and received by Floor Broker 2 and before Floor Broker 2 determines all legs of the strategy. Should the Participants determine in the future that such instruction is not reportable to CAT, the reporting guidance may change.
 

The ‘FB’ handlingInstructions value is used to identify order routes that are sent to an exchange and directed to a specific Floor Broker on that exchange. Currently, this workflow is only applicable to the Cboe Options (C1) exchange.

When an order is routed electronically from an Industry Member to the Cboe Options (C1) exchange that is to be directed to a Floor Broker’s PAR workstation, the Order Route event (MOOR or MLOR) for the order route to the exchange must include the handlingInstructions values ‘DIR’ (Directed Orders) and ‘FB’ (Cboe Options Floor Broker).

This handlingInstructions value must not be used for orders routed electronically or manually from an Industry Member directly to an Industry Member Floor Broker.

For more information regarding these workflows, please refer to Section 8.2 of the Industry Member Reporting Scenarios document on the catnmsplan.com website.
 

In Phase 2d, the ‘OPT’ instruction must only be used in the following circumstances:

• The equity leg of a multi-leg order is routed as a single leg to an executing broker or exchange with instructions to execute and print the equity trade at the specified limit price that was determined as part of achieving the net price of the multi-leg order. For example, a Floor Broker working a complex order prices the equity leg and then routes only the offsetting equity legs to an executing Broker as a pair for crossing and reporting to the TRF. In this example, the ‘OPT’ handlingInstructions value must be included on the MEOR reported by the Floor Broker and on the MEOA reported by the executing Broker.

• Only the equity leg of a multi-leg order is reported to CAT because the options legs of the multi-leg order were subject to the verbal quote exemption and therefore were not reported to CAT. Please refer to Section 8 of the Reporting Scenarios document for a detailed illustration of the reporting requirements in this circumstance.

In Phase 2d, if a multi-leg order is reported to CAT and an equity leg is legged out as a simple equity order with no special instructions, then the ‘OPT’ handlingInstructions value must not be used.

The handlingInstructions value of ‘OPT’ must not be used on any multi-leg events (MLNO, MLOA, etc.).
 

Many exchanges offer cross order types that allow a submitter to match potential price improvement offered by other exchange participants, up to a limit prescribed by the submitter (an “Auction Price Cap”). Related Exchange terminology includes “AutoMatch”, “No-Worse-Than” and “Step-Up”.

Beginning July 1, 2024, when routing a paired option order to an options exchange with an instruction that the contra party is willing to meet price improvement offered by other exchange participants, Industry Members must include one of the “Auction Price Cap” handlingInstructions values: ‘APCL’ (Auction Price Cap Limit) or ‘APCM’ (Auction Price Cap Market). If the exchange member only wishes to match price improvement to a specified amount, the ‘APCL’ handlingInstructions value must be used. If the exchange member is willing to match any price improvement, the ‘APCM’ handlingInstructions value must be used. These handlingInstructions values must only be populated on the contra-side options route event to the exchange. The ‘APCL’ and ‘APCM’ handlingInstructions values must only be used in combination with the pairedOrderID field. These values are required on paired orders routed directly to an exchange (when applicable), although may be optionally reported if the pairedOrderID field is also optionally populated. See FAQ K20 for further information on paired orders.
 

As described in the CAT Industry Member Technical Specification (“Tech Spec”) document certain events that occur within systems used by Floor Brokers on the NYSE’s equities or options floors are required to be reported to CAT pursuant to SEC Rule 613(c)(7). Generally, Floor Brokers on both the equities and options trading floors receive orders from one of several sources and such orders are processed via an order management system (“OMS”) before they are entered into an exchange for execution. For example, Floor Brokers may receive an order from within their own firm, which has electronically routed the order from one of its internal systems into the Floor Broker’s OMS. For CAT reporting purposes, that transfer of an order from the firm’s own internal system to that firm’s Floor Broker OMS on the floor of the NYSE is likely CAT reportable as an intrafirm transfer/internal route as described in the Tech Specs and required by Rule 613(c)(7)(ii)(F) and Rule 613(c)(7)(iii). In another scenario, Floor Brokers may receive an order from an outside source and enter it into the firm’s Floor Broker OMS. In this scenario, the Floor Broker must record and report the time of the order receipt as described in SEC Rule 613(c)(7)(i)(E), Appendix C at section A(1)(a)(iii) of the CAT NMS Plan and also described in the Tech Specs.

After a Floor Broker receives the order and the order is in the Floor Broker’s OMS, the Floor Broker determines how to represent their order. A Floor Broker may, for example: 1) send the order back to the source if routed directly to the Floor Broker’s OMS by another desk within the Floor Broker’s firm; 2) electronically send the order directly to an exchange system for execution; 3) electronically route the order to a third-party provider that determines where to route the order (to an exchange or other execution venue); or 4) orally represent and then execute the order on the floor. Each of these scenarios may include events that trigger an obligation to report to CAT.

In the first three scenarios, electronically routing an order from the Floor Broker’s OMS to another of the Floor Broker firm’s internal systems, to an exchange, or to a third-party provider constitutes a CAT-reportable event pursuant to Rule 613(c)(7)(ii). For the fourth scenario, if the Floor Broker orally represents an order on the trading floor, no reportable events are occurring until an execution is reported. The execution triggers a CAT-reporting obligation for the Floor Broker, who is responsible for reporting the time of order execution pursuant to SEC Rule 613(c)(7)(v) and as described in the Tech Spec. The time of execution as required by Rule 613(c)(7)(v)(C) is the time at which the Trading Official (options floors) releases the order to the Floor Broker for reporting to the exchange, or is the time at which the DMM (equities floor) reports the matched trade to the exchange. The Floor Broker is responsible for reporting each CAT-reportable event required by Rule 613, although a Floor Broker may arrange for the exchange to report on the Floor Broker’s behalf. The Floor Broker should contact NYSE Member Services to ensure reporting by the industry member reporting deadlines.

Firm Designated ID (FDID) is defined in Section 1.1 of the CAT NMS Plan as “(1) a unique and persistent identifier for each trading account designated by Industry Members for purposes of providing data to the Central Repository, provided, however, such identifier may not be the account number for such trading account if the trading account is not a proprietary account; (2) a unique and persistent relationship identifier when an Industry Member does not have an account number available to its order handling and/or execution system at the time of order receipt, provided, however, such identifier must be masked; or (3) a unique and persistent entity identifier when an employee of an Industry Member is exercising discretion over multiple client accounts and creates an aggregated order for which a trading account number of the Industry Member is not available at the time of order origination, where each such identifier is unique among all identifiers from any given Industry Member.” Under the CAT NMS Plan, broker-dealers are required to report the FDID on all Transaction Order events requiring the FDID submitted to the Central Repository and the Central Repository will associate specific customers and their CAT Customer IDs (CCID) with individual order events based on the reported FDID. Given the purpose of the FDID under the CAT NMS Plan, it is important that this identifier be unique, persistent and consistent within the firm and across all vendors and systems the Industry Member may use to report Transaction Order events requiring an FDID to CAT and associated Customer and Account information for the FDID to CAT CAIS, and unique across time. 

A change/replacement in the FDID value associated with a particular trading account would be an isolated event that is only permissible in certain limited circumstances, such as: 

• System migration. For example, Industry Member 1 changes from System A to System B, which necessitates the generation of unique FDID values for accounts, and the system migration does not involve closing the underlying accounts.

• Change of vendors. For example, an Industry Member currently uses an Order Management System (“OMS”) provided by Vendor A but will change to Vendor B’s OMS. Vendor B’s OMS does not support some of the characters supported by Vendor A so the Industry Member must change the FDID. Please see FAQs B53 and Q53.   

• Change in Clearing Firm. For example, an Industry Member changes from Clearing Firm A to Clearing Firm B. Clearing Firm B does not permit FDIDs in the same format as Clearing Firm A so the Industry Member must change the FDID.

• Change in masking methodology. 
  • Changing the algorithm which creates a new FDID value for the account
  • Masking a previously unmasked FDID value
  • Only for proprietary accounts: unmasking a masked FDID value of a proprietary account. 

Note that the above limited circumstances do not include correcting an erroneously reported FDID, closing an account, or transferring the FDID to another CAT Reporter Firm. Please see the CAT Reporting Customer and Account Technical Specifications for Industry Members for more information on these scenarios.

Also, please see FAQ M16 for the requirements when replacing/changing an FDID. 

The same guidance outlined above would apply to an FDID value representing a Relationship Identifier (“Relationship ID”).
 

The use of an actual account number as the FDID is prohibited to ensure the capture of sensitive data in CAT is minimized when its inclusion is not required to achieve the objectives of CAT. Specifically, the Operating Committee has determined that Industry Members must not assign as an FDID a customer’s account number or any other number associated with the customer’s account that could be used to effect a transaction in the account. Acceptable FDIDs may include, without limitation, a newly created unique identifier or an internal only identifier used by a broker-dealer that cannot be used to effect a transaction. Industry Members also may employ a masking methodology that would mask the actual account number prior to submission to CAT so that it could still be used by CAT to identify a single trading account within the Industry Member, but the identifier provided to CAT could not be used to effect a transaction in the account, and would not constitute "Customer Account Information" or “Customer Identifying Information” as defined in the CAT NMS Plan. The same guidance would apply to FDIDs representing a Relationship Identifier (“Relationship ID”). See also FAQs M9 and M10 for additional information on masking.

No. Unless a new account or entity identifier is assigned to a client or customer, each Firm Designated ID (FDID) must be unique, persistent and consistent for each trading account within the firm and across all vendors and systems the Industry Member may use to report Transaction Order events requiring an FDID to CAT and associated Customer and Account information for the FDID to CAT CAIS, and unique across time (with limited exceptions as noted in FAQ M16).

The account or entity identifier used to place the order must be reported. In scenarios where a master/top account or entity identifier is used to place an order, the Firm Designated ID (FDID) representing the master/top account or entity identifier should be reported to CAT for Transaction Order events requiring an FDID (e.g. New Order and Trade events). In such scenarios, the FDID represents the master/top account or entity that is authorized to place orders for one or more legal entities or customers. The Industry Member performing the allocation will also be required to report an allocation to the master/top account via a Post Trade Allocation (MEPA)/Options Post-Trade Allocation (MOPA), as well as subaccount allocations to the underlying subaccounts using the FDIDs associated with such subaccounts. For more information on allocation reporting and subaccounts, see FAQ U2.

The Firm Designated ID (FDID) representing the account identifier used by the Industry Member for the specific firm owned or controlled account in which the order was originated should be reported to CAT. For example, Industry Members must specify whether an account used for a Reportable Event was a market making account, other proprietary trading account, agency allocation account or error account.

Yes. CAT allows multiple vendors to submit data on behalf of a single Industry Member CAT Reporter. Each vendor reporting Transaction Order events requiring a Firm Designated ID (FDID) on behalf of an Industry Member CAT Reporter would have to provide the same FDID as required. A single FDID assigned to each trading account must be unique, persistent and consistent within the firm and across all vendors, and unique across time. An Industry Member CAT Reporter must ensure that the same FDID is used by all vendors and systems submitting Transaction Order Events requiring an FDID to CAT involving the same unique trading account at the Industry Member. It would not be acceptable for different vendors or systems to use different FDIDs to represent the same unique trading account. The Industry Member must also ensure that the same FDID used for a particular trading account in CAT Transaction reporting is submitted to the Customer and Account Information System. The same guidance would apply to an FDID value representing a Relationship Identifier (“Relationship ID”) or Entity Identifier (“Entity ID”).

Before the reporting of Customer Account Information and Customer Identifying Information begins with the implementation of Phase 2e (Full CAIS), regulatory users of the CAT will use FDIDs to identify whether the same account is trading within a single broker-dealer. After the reporting of Customer Account Information and Customer Identifying Information begins, FDIDs will be used to link accounts to specific Customers, including mapping accounts with common ownership (for instance, where a Customer is associated with more than one FDID).

Industry Members (other than Small Industry Members) and Small Industry Members that are required to record and report information to FINRA’s Order Audit Trail System pursuant to applicable SRO rules (“Small Industry OATS Reporters”) must commence reporting Firm Designated IDs (FDID) on all Transaction Order events requiring an FDID to the CAT in Phase 2a beginning on June 22, 2020. Small Industry Members that are not Small Industry OATS Reporters must commence reporting FDIDs on all Transaction Order events requiring an FDID to the CAT by December 13, 2021.

No. Each Industry Member must make its own determination whether it believes it is necessary to mask the actual account number for any proprietary account of the firm when reporting the FDID to CAT.

No. The Plan Participants are not prescribing any specific methodology that must be used to mask or otherwise transform account numbers for the purposes of reporting the Firm Designated ID (FDID) to CAT. Each Industry Member must, however, ensure the methodology used to mask or otherwise transform an account number does not result in a newly created unique identifier or an internal only identifier that can be used to effect a transaction or would not constitute "Customer Account Information" or “Customer Identifying Information” as defined in the CAT NMS Plan. The same guidance would apply to FDIDs representing a Relationship ID. When selecting an FDID, the Industry Member must also ensure that all vendors and systems can support and use the same FDID for a particular trading account in all CAT Transaction Order events requiring an FDID, and that the same FDID associated with the trading account is submitted to the Customer and Account Information System. 

No. If the trading account structure of an individual customer is not available when a new order is first received, as with an institutional client in the same circumstances, the Industry Member may populate the FDID with an identifier used by the firm to represent the individual customer’s trading relationship with the Industry Member (“Relationship ID”). Please note that the Participants will make any filings with the SEC, as necessary, to reflect this guidance.

Additional information regarding the Firm Designated ID (FDID) may be found in the February 19, 2020 webinar here, as well as the CAT Reporting Technical Specifications for Industry Members and CAT Reporting Customer and Account Technical Specifications for Industry Members

A Firm Designated ID applies to a trading account, not to a Customer. Specifically, a Firm Designated ID is defined in Section 1.1 of the CAT NMS Plan, in relevant part, as “a unique identifier for each trading account designated by Industry Members for purposes of providing data to the Central Repository.” The Operating Committee recognizes that certain provisions of the CAT NMS Plan use phrases similar to “Firm Designated ID for each Customer.” For example, Section 6.3(d)(i)(A) of the CAT NMS Plan refers to “Firm Designated ID(s) for each Customer,” and Section 6.4(d)(ii)(C) of the CAT NMS Plan refers to “the Firm Designated ID for the relevant Customer.” Notwithstanding this phraseology, the Firm Designated ID applies to a trading account, not to a Customer.

In certain scenarios (e.g., institutional, managed accounts), the trading account structure may not be available when a new order is first received from a client and instead, only an identifier representing the client’s trading relationship is available. In these limited instances, the Industry Member may populate the Firm Designated ID (“FDID”) with an identifier used by the firm to represent the client’s trading relationship with the Industry Member (“Relationship ID”) instead of an account number. 

An example of such an identifier could be as follows:

• Big Fund Manager is known in Industry Member A’s systems as “Big Fund Manager.”
• When an order is placed by Big Fund Manager, the order is tagged to Big Fund Manager.
• Industry Member A could use BFM1 (a masked version of the relationship with the customer) as the FDID when reporting a new order from Big Fund Manager instead of the account numbers to which executed shares/contracts will be allocated at a later time via a booking or other system.

When an employee of the Industry Member is exercising discretion over multiple client accounts and creates an aggregated order for which a trading account number of the Industry Member is not available at the time of order origination, the FDID can be populated by the Entity ID instead of the identifier for an account number. An Entity ID is an identifier of the Industry Member that represents the firm discretionary relationship with the client rather than a firm trading account.

An example of the use of an Entity ID as an FDID would be when Industry Member 1 has an employee that is a registered representative that has discretion over several client accounts held at Industry Member 1. The registered representative places an order that he will later allocate to individual client accounts. At the time the order is placed, the trading system only knows it is a representative of Industry Member 1 and it does not have a specific trading account that could be used for FDID reporting. Therefore, Industry Member 1 could report “IM1,” its Entity ID, as the FDID with the new order.
 

As stated in FAQ M1, given the purpose of the Firm Designated ID (“FDID”) under the CAT NMS Plan, a change/replacement in the Firm Designated ID (FDID) value associated with a particular trading account would only be permissible in certain limited circumstances, such as system migration, change of vendors, change in clearing firm and change in masking methodology.

If an Industry Member has reported an FDID on a Transaction Order event (e.g., MENO, MEOF, MEOT) and subsequently changed the FDID associated with that particular trading account prior to the implementation of full Customer and Account Reporting, the Industry Member has additional obligations as outlined below. The same obligations would apply to an FDID value representing a Relationship Identifier (“Relationship ID”) and Entity Identifier (“Entity ID”).

All Industry Members:

• Must maintain as part of books and records the circumstances necessitating the FDID change/replacement, and make these records available to Regulators upon request. 

In addition: 

Industry Members who have already reported the FDID to CAT CAIS:

• Must report the change of FDID to CAIS. If reporting in schema version 1.0.0 (LTID Account Phase), see Scenario 3.4 (Ending FDID with Replacing Record) of the CAT CAIS Industry Member Reporting Scenarios – LTID Phase. If reporting in schema version 2.0.0, see the scenario titled “FDID Replaced by Another FDID Within the Same Firm” in the CAT CAIS Industry Member Reporting Scenarios – Full CAIS Phase. 

Industry Members who have NOT reported the FDID to CAT CAIS:

• May report both the prior FDID and replacing FDID to CAIS. If reporting in schema version 1.0.0 (LTID Account Phase), see Scenario 3.4 (Ending FDID with Replacing Record) of the CAT CAIS Industry Member Reporting Scenarios– LTID Phase. If reporting in schema version 2.0.0, see the scenario titled “FDID Replaced by Another FDID Within the Same Firm” in the CAT CAIS Industry Member Reporting Scenarios – Full CAIS Phase. While Industry Members are not required to report all FDIDs to CAT CAIS until the implementation of full Customer and Account Reporting, Industry Members may voluntarily do so. Per FAQ Q8, if an Industry Member voluntarily provides such account reporting, the Industry Member is still subject to timely, accurate and complete reporting requirements. See CAT Alerts 2022-01 and 2023-01 for the Full CAIS Implementation Schedule.  
• OR must notify FINRA CAT of FDID changes via the Customer and Account Reporting Disclosure Form. This Form, as well as the standards for submitting it, are outlined in CAT Alert 2021-02 (Standards for Completing the Customer and Account Reporting Disclosure Form). Industry Members choosing this option must also maintain mapping information that links the prior FDID to the replacing FDID and the associated trading account, Relationship ID, or Entity ID. Industry Members must not provide the FDID mapping information to FINRA CAT on the Customer and Account Reporting Disclosure Form, but must maintain such documentation, and make it available to Regulators upon request. 

Note that after implementation of full Customer and Account Reporting, all Industry Members must maintain as part of books and records the circumstances necessitating the FDID change/replacement, and make these records available to Regulators upon request. In addition, all Industry Members must report a change/replacement of FDID value as described in the CAT Reporting Customer and Account Technical Specifications for Industry Members.

No, the firmDesignatedID submitted to CAIS must be the same firmDesignatedID populated on the related Transaction Order event for a specific trading account, Relationship ID or Entity ID. 

Per FAQ M1, given the purpose of the FDID under the CAT NMS Plan, it is important that this identifier be unique, persistent and consistent within the firm and across all vendors and systems the Industry Member may use to report Transaction Order events requiring an FDID to CAT and associated Customer and Account information for the FDID to CAT CAIS, and unique across time.
 

No, a CAT Reporting Agent may not report CAT Data to the CAT on behalf of an Industry Member without the Industry Member’s consent. As required in the CAT Compliance Rules, an Industry Member may enter into an agreement with a CAT Reporting Agent pursuant to which the CAT Reporting Agent agrees to fulfill the obligations of such Industry Member under the CAT Compliance Rules. Any such agreement is required to be evidenced in writing and the agreement must specify the respective functions and responsibilities of each party to the agreement that are required to effect full compliance with the requirements of the CAT Compliance Rules. Such agreement should include the date on which the CAT Reporting Agent should commence reporting to the CAT on behalf of the Industry Member. In addition, to begin reporting to the CAT, the Industry Member and the CAT Reporting Agent must complete the onboarding process with the Plan Processor. Notwithstanding the existence of an agreement with a CAT Reporting Agent, an Industry Member remains primarily responsible for compliance with the CAT reporting requirements.

Each Industry Member is responsible for the timeliness, accuracy and completeness of the data it is required to report to CAT regardless of who transmits the data to the CAT. Therefore, even if an Industry Member uses another CAT Reporter to report data on its behalf, the Industry Member remains fully responsible for the timeliness, accuracy and completeness of the data. Each Industry Member must have written procedures in place to ensure that the information reported by or on its behalf is timely, accurate, and complete.

Yes. More than one third party may transmit order events to CAT on behalf of a single Industry Member. Industry Members are responsible for ensuring that all required information is submitted to CAT via the third parties, and that the third parties do not send duplicate information to CAT.

No. There are no scenarios where one CAT Reporter has an obligation to report orders on behalf of another Industry Member that uses its systems to route or execute orders. An agreement to use any third party for reporting to CAT must be agreed to by the two parties, evidenced in writing, and retained by both parties to the agreement. The agreement must specify the respective functions and responsibilities of each party. An Industry Member cannot assume that any third party will perform reporting on its behalf.

No. The connectivity standards in the CAT NMS Plan (i.e., Section 4.1.1 of Appendix D) only apply to connections directly into the CAT infrastructure. Although the connectivity standards in the CAT NMS Plan would not apply in this scenario, broker-dealers are encouraged to consider industry practices for connectivity designed to mitigate security and other risks.

Yes, Industry Members must have individual reporting agreements with each firm or service bureau transmitting data to CAT on the Industry Member’s behalf. A reporting agreement between the Industry Member clearing firm and third party service bureau in this instance would not apply to the introducing Industry Member firm.

Each Industry Member is responsible for complying with applicable CAT requirements, including those related to recordkeeping and record retention, set forth in the CAT Compliance Rules. Outsourcing a function to a vendor or other third party does not relieve the Industry Member of its ultimate responsibility for compliance with the CAT Compliance Rules or other applicable securities laws, rules or regulations (e.g., SEC Rule 17a-4). To the extent that an Industry Member seeks to rely on its third party CAT Reporting Agent to maintain and preserve records on its behalf, the Industry Member must take steps reasonably designed to ensure that its CAT Reporting Agent is capable of performing these functions consistent with the CAT Compliance Rules and other applicable securities laws, rules or regulations.

FINRA CAT, LLC provides two mechanisms for submitting files: SFTP via a private network, and the Web via Reporter Web Portal. These mechanisms are described in the CAT Reporting Technical Specifications for Industry Members.

CAT supports network access for reporting order events via Private Lines (i.e., wan circuits and cross connects) and Remote Client VPN connections. FINRA CAT, LLC will organize Private Lines connectivity options with Industry Members through the use of a Managed network Service Provider (MNSP). For Industry Members who require Private Line connections, Industry Members will be responsible for procuring access from an approved (MNSP) to authenticate and submit SFTP data uploads. The Reporter Portal will also be available over the MNSP connection(s). Alternatively the Industry Members may access the Reporter Portal via a browser based Remote Client VPN connection that will also be made available to Industry Members. All Industry Members must have access to the SFTP and CAT Reporter Portal in order to report and receive information about file and record rejections, statistics about order reporting, and announcements. In order to use SFTP and CAT Reporter Portal, Industry Members must register with CAT prior to the beginning of Phase 2a. If an Industry Member is using one or more third parties for reporting, it must work closely with those organizations in the CAT testing environment to resolve any issues before it begins reporting to the CAT production environment. More details regarding the MNSP and VPN access methods will be published in July once the MNSP vendor(s) is selected. For additional information, refer to the CAT Reporting Technical Specifications for Industry Members.

Yes, FINRA CAT, LLC provides a CAT Reporter Portal that allows Industry Members to upload small files, as well as manually type and transmit the required order data. (This is only appropriate for Industry Members that will submit fewer than 500 order reports per day.) There are no other plans to provide Industry Members with software or a workstation to transmit the required data.

Yes. Clearing firms that enter into agreements with their correspondents to transmit data to CAT on behalf of their correspondents are required to use each correspondent’s unique CAT Reporter IMID.

No. A file may contain records for only one CAT Reporter IMID.

There is no requirement to install a back-up circuit. Several different scenarios may apply, as follows:
If a broker-dealer experiences a short-term outage, for instance an internal network goes down during the day and the broker-dealer is unable to transmit before the deadline, the broker-dealer should note the outage in its books and records and transmit as soon as possible. In addition, it is recommended that a case be opened with the CAT Help Desk so that there is a record of the outage.

Information on CAT Entitlement, will be published in an Industry Member Onboarding User Guide on www.catnmsplan.com.

It is currently under development, and will be provided once available.

Information regarding connectivity and the registration process will be provided in the Industry Member Onboarding User Guide.

CAT supports network access for reporting order events via VPN or direct connections. Once connected, files can be submitted via SFTP.

If you need technical assistance, contact the CAT Helpdesk at 1-888-696-3348.

Functionality to save a copy of records submitted via the CAT Reporter Portal is anticipated. Further details will be provided in Reporter Portal User Guide.

The CAT System status and other announcements will be presented on the Reporter Portal.

Yes. A CAT Reporter may share its CAT connectivity (e.g., Industry Member or Plan Participant connectivity to FINRA CAT, such as private line, AWS PrivateLink, CAT Secure Reporting Gateway) with one or more affiliated CAT Reporters (“Affiliated CAT Reporter(s)”) and/or affiliated CAT Reporting Agents (“Affiliated CAT Reporting Agent(s)”).

Each Affiliated CAT Reporter can use the shared connectivity to report on its own behalf directly to the CAT. Similarly, each Affiliated CAT Reporting Agent can use the shared connectivity to report on behalf of others to the CAT. Each CAT Reporting Agent, or CAT Reporter submitting machine to machine on its own behalf, will need to establish its own FINRA CAT Secure File Transfer Protocol ("SFTP") Account.

Each CAT Reporter is ultimately responsible for satisfying its obligations to report to the CAT. Each CAT Reporter and CAT Reporting Agent also must have executed any required documentation, such as the CAT Reporter Agreement and/or CAT Reporting Agent Agreement, as applicable.

The Participants intend to modify the CAT Connectivity Guide to make clear that sharing of CAT connectivity as described above is permitted.

Each CAT Reporter’s reporting metrics, including linkage statistics, will be available via the CAT Reporter Portal and via Feedback files.

Order Events for non-Eligible Securities will be rejected by CAT.

No. Files are only rejected for errors in the basic file integrity checks. If an individual record is unacceptable, only that record will be rejected and require repair. See Section 7 in the CAT Reporting Technical Specifications for Industry Members for additional information on Feedback and Corrections.

Feedback, including acknowledgements and rejections, will be generated from each stage of processing. Order Events feedback will be provided as soon as the processing of each stage is completed. All feedback, including rejections, for files submitted by 8AM T+1 will be available no later than noon on T+1, where T is the CAT Trading Day. From a timing perspective, intrafirm processing occurs prior to interfirm. More detailed information on timing of feedback is available in Section 7 of the CAT Reporting Technical Specifications for Industry Members.

There are multiple ways to repair a rejected order event. The first way is to regenerate the repaired record, and package it in a Data File and submit the new file to CAT. Events from different calendar days can be commingled in one file. Industry Members may also use the CAT provided feedback files, which pre-populates original rejected records, to repair a rejected order event. A third option is to make the repair via the Reporter Portal. Additional information on repairing CAT errors may be found in Section 7.6.1, 7.6.2 and 7.6.3 of the CAT Reporting Technical Specifications for Industry Members.

Industry Members must submit a firm-initiated correction to CAT (actionType ‘COR’) for an order event record that has already been submitted to CAT and been accepted by the system only if they discover a mistake, such as a data entry error. Corrections must never be used to reflect a change requested by a customer. For example, if an order quantity is mistakenly reported to CAT as 100 rather than 1,000, the Industry Member must correct the error via a correction record. However, if the customer requests that an order quantity be changed from 100 to 1,000 shares, the Industry Member must instead submit an Order Modified event. Correction records submitted to CAT after 8am on T+3, where T is the CAT Trading Day, will be marked as late.

The above guidance does not apply to Customer Accommodation Correction scenarios, where an Industry Member must submit a correction and populate a handlingInstructions value of ‘CAC’ when a ‘COR’ event was submitted to CAT as the result of a customer/client accommodation. Refer to the CAT Industry Member Reporting Scenarios for additional information on this scenario. 
 

Industry Members should submit a self-identified deletion to CAT only if they discover that an order event record was mistakenly sent to CAT and accepted. For example, if an Industry Member mistakenly reports that an order was canceled when it was actually executed, a deletion should be submitted for the Order Canceled Report. Deletions transmitted to CAT after 8am on T+3, where T is the CAT Trading Day, will be marked as late.

CAT files may be rejected if they cannot be decrypted or if the files are unreadable, contain a malformed file name, duplicated file name, or contain an invalid Submitter ID. Additional information on file feedback may be found in Sections 7 and Section E.1 (File Integrity Errors) in Appendix E of the CAT Reporting Technical Specifications for Industry Members.

Individual records will be rejected if they do not meet the specific data type formats as laid out in the CAT Reporting Technical Specifications for Industry Members. Additional information on file feedback may be found in Section 7 and Section E.2 (Data Ingestion Errors) in Appendix E of the CAT Reporting Technical Specifications for Industry Members.

All rejected files must be corrected and resubmitted by 8 a.m. T+1.

No. The CAT system processes and validates each report individually and will not reject secondary events such as an Order Route because the related primary event was not reported. However, these instances may be flagged as Unlinked.

No. Data that was submitted to and accepted by CAT cannot be viewed by the CAT Reporter. However, the feedback file does provide counts of records contained within each file so that firms can identify the number of events in an accepted or rejected file and/or whether an accepted file contains zero records. The CAT Reporter Portal and feedback files allow for the viewing of file status, reporting statistics, and rejected or unlinked events.

No. Limit orders with a timeInForce value of ‘GTC’ are maintained in CAT for six years. Limit orders with a timeInForce value of ‘GTD’ will be maintained until the expiration date provided on the order, plus the Processing Window. Any order report related to one of these limit orders can be reported to CAT within that time period.

No. The Order Canceled Event will not be rejected from CAT.

The reporting of data will be considered late if it is not reported by the deadlines established in the CAT NMS Plan. For example, Industry Members must report (1) Recorded Industry Member Data, as defined in the CAT NMS Plan, to the CAT by 8:00 a.m. ET on the Trading Day following the day the Industry Member records such data, and (2) Received Industry Member Data, as defined in the CAT NMS Plan, to the CAT by 8:00am ET on the Trading Day following the day the Industry Member receives such Received Industry Member Data. If such data is not reported in accordance with those deadlines, it will be considered late.

Pursuant to the Participants’ CAT compliance rules and the CAT NMS Plan, all error corrections must be made by 8 am on T+3, where T is the Trading Day of the Reportable Event, otherwise they will be marked as late. In the example, all rejections, including the second rejection on T+1 and any subsequent rejections, must be corrected and submitted by 8 am on T+3. Industry Members must correct all errors regardless of when they occur.

The CAT NMS Plan currently requires Industry Members to provide Firm Designated IDs, Customer Account Information and Customer Identifying Information to the CAT.

As set forth in the CAT NMS Plan, a Firm Designated ID is a unique identifier for each trading account designated by Industry Members for purposes of providing data to the CAT, where each such identifier is unique among all identifiers from any given Industry Member for each business date.

Customer Account Information includes, but is not limited to:

• Account number (except in certain circumstances);
• Account type;
• Customer type;
• Date account opened; and
• Large Trader identifier, if applicable.

Customer Identifying Information means information of sufficient detail to identify a Customer, including, but not limited to, (a) with respect to individuals: name, address, date of birth, individual tax payer identification number (“ITIN”)/social security number (“SSN”), individual’s role in the account (e.g., primary holder, joint holder, guardian, trustee, person with the power of attorney); and (b) with respect to legal entities: name, address, Employer Identification Number (“EIN”)/Legal Entity Identifier (“LEI”) or other comparable common entity identifier, if applicable; provided, however, an Industry Member that has an LEI for a Customer must submit that Customer’s LEI in addition to other information of sufficient detail to identify a Customer.

In light of security concerns, however, the Operating Committee is analyzing alternative approaches to providing Customer information.

No, the Participants obtained exemptive relief from the requirement in Rule 613 for a CAT Reporter to report the Customer-ID(s) for each Customer. Instead, the CAT NMS Plan requires Industry Members to report only the Firm Designated ID for each new order submitted to the CAT, rather than the Customer-ID, and the Plan Processor would associate the specific Customers and their Customer-IDs with individual order events based on the reported Firm Designated ID. The Firm Designated ID is a unique identifier for each trading account designated by Industry Members for purposes of providing data to the CAT, where each such identifier is unique among all identifiers from any given Industry Member for each business date.

The reporting of Customer Identifying Information and Customer Account Information consists of two phases, an earlier phase in which Industry Members must report to the CAT certain account information regarding account holders with a Large Trader Identification (LTID) number or an Unidentified Large Trader Identification (ULTID) number pursuant to SEC Rule 13h-1 (collectively called “LTID Account Information”), and a later phase that requires Industry Members to report all Customer Identifying Information and Customer Account Information. Specifically, each Industry Member must report Customer information according to the following milestones:

First Phase - Limited LTID Account Information Reporting 

April 26, 2021| By April 26, 2021, Large Industry Members (which are Industry Members other than Small Industry Members) must report LTID Account Information for FDIDs that have associated LTIDs or ULTIDs and a CAT reporting requirement on or after April 26, 2021. The specific reporting requirements and guidance for such reporting are set forth in the CAT Reporting Customer and Account Information Technical Specifications for Industry Members-LTID.

December 13, 2021| By December 13, 2021, all Industry Members (Large and Small Industry Members) must report LTID Account Information related to all remaining FDIDs that have associated LTIDs or ULTIDs and CAT reportable activity as of and including Phases 2a, 2b, 2c and 2d.

Note that all Industry Members may begin submitting LTID Account Information to the CAT CAIS Testing Environment on August 24, 2020 and to the CAT Production Environment on December 14, 2020.

Second Phase - Full Customer & Account Reporting

May 31, 2024| All Industry Members must report to the CAT a full set of Customer Account Information and Customer Identifying Information for all Active Accounts in Phase 2e. The specific reporting requirements and guidance for Industry Members is provided in the CAT Reporting Customer and Account Technical Specifications for Industry Members-Full CAIS and CAT Alerts 2022-01 and 2023-01.

In addition, on a periodic basis, each Industry Member will be required to submit to the CAT a complete set of all required Customer information.
 

An Industry Member is required to report an LEI for a Customer that is a legal entity to the CAT if the Industry Member has an LEI for a Customer. The CAT NMS Plan does not require a Customer to obtain an LEI if it does not have one, it does not require a Customer to provide an LEI to an Industry Member; and it does not require the Industry Member to request an LEI of its Customer.

The LEI information associated with Customer information is separate from the collection of the Industry Member’s LEI via the CAIS Registration Form and CAT Registration Form (Transaction Reporting). For additional information pertaining to LEI and Industry Members, see FAQs A34 and Q38.

The CAT NMS Plan defines a “Customer” as (a) the account holder(s) of the account at a registered broker-dealer originating the order; and (b) any person from whom the broker-dealer is authorized to accept trading instructions for such account, if different from the account holder(s). This is the same definition as set forth in Rule 613(j)(3).

Industry Members are required to obtain and report LTIDs to CAT for Firm Designated IDs (FDID) with Reportable Events that must be reported to CAT in Phase 2c (equities) and Phase 2d (options). This applies to both existing FDIDs and new FDIDs established after the Phase 2c and 2d implementation dates. Each Industry Member must determine how to obtain the LTID for each FDID – to the extent that an LTID exists – in order to report this information to CAT. This means that CAT imposes new recording and reporting obligations on some Industry Members with respect to obtaining LTIDs to meet their CAT reporting obligations. Some Industry Members may have to change current onboarding activities to ensure an LTID is obtained and recorded for any account with Reportable Events.

Large Industry Members must obtain and report LTIDs to CAT by April 26, 2021 for Phase 2c and December 13, 2021 for Phase 2d. Small Industry Members must obtain and report LTIDs to CAT by December 13, 2021 for both Phase 2c and Phase 2d. 

No. Sensitive Identifiers are defined in the Customer and Account Information Technical Specifications as Social Security Number and Individual Taxpayer Identification Identifiers. Industry Members must not provide Sensitive Identifiers, nor full dates of birth for individuals, nor account numbers for customer accounts to the CAT.  In light of security concerns raised with regard to the maintenance of Customer information in the CAT, the SEC granted exemptive relief on March 17, 2020 that would eliminate the requirement to report these three data elements [

Further, a Sensitive Identifier, date of birth or account number must not be submitted to CAIS as a value for any field in the record including firmDesignatedID and accountName, unless it is masked. In the scenario where a Sensitive Identifier, date of birth or account number is part of the account name in an Industry Member’s books and records, it is expected that the masked accountName value submitted to CAIS will not match the unmasked account name in an Industry Member’s books and records.  

In addition, Industry Members must not submit to CAIS, in any field of the record, any other number associated with the customer’s account that could be used to effect a transaction in the account.
 

Yes, Industry Members may provide Customer Account Information on all of their accounts, not just Active Accounts or those Active Accounts in scope for a given phase of reporting. If an Industry Member voluntarily provides such account reporting, the Industry Member is still subject to timely, accurate and complete reporting requirements. As noted in FAQ Q7, Industry Members must not provide social security numbers, dates of birth and account numbers to the CAT. See CAT Alerts 2022-01 and 2023-01 for the Full CAIS Implementation Schedule.

As described in the Customer and Account Technical Specifications for Industry Members (LTID and Full CAIS), in the scenario a CAT Reporter that is a clearing firm or self-clearing firm determines a person (which includes both natural persons and legal entities under Section 13(h)(8)(E) of the Exchange Act) would qualify as a large trader, but the firm has not yet been provided with an LTID by the person, the clearing firm or self-clearing firm is required to assign an ULTID to the person until such time as the person provides their LTID. Any CAT Reporter that is a clearing firm or self-clearing firm with an obligation to assign an ULTID under the large trader rule is required to report any assigned ULTIDs associated to their FDIDs as part of their customer and account reporting. CAT Reporters that are not clearing firms or self-clearing firms and do not have an obligation to assign ULTIDs are not required to report ULTIDs to CAT as they will have no such number to report.

The ltidEffectiveDate in this scenario is the date the Industry Member was provided the LTID and it was associated with the FDID. If an Industry Member stores LTIDs at the entity, top account or relationship level (for example, in the case of institutional accounts), the ltidEffectiveDate may be reported as the date the Industry Member associated the LTID to the top-level account (for all associated subaccounts) or the entity or relationship level for all associated FDIDs. 

The ltidEndDate is the date the Industry Member became aware that the LTID or ULTID was no longer associated with the FDID.

Industry Members should make a reasonable effort to obtain an accurate reason as to why the LTID, ULTID or Customer is no longer associated to the FDID. Starting with the implementation of Full CAIS, if the facts and circumstances regarding why an association was ended cannot be reasonably ascertained, then the ltidEndReason or roleEndReason value of ‘OTHER’ may be used.

Industry Members must record in their systems the date that an LTID or ULTID becomes associated with an FDID (“LTID Effective Date”). Some Industry Members may have to change current onboarding activities to ensure this information is obtained and recorded. 

If an Industry Member has not recorded the LTID Effective Date, they may use the go-live date as the ltidEffectiveDate until the go-live date. Starting on the go-live date, Industry Members must record and report an accurate LTID Effective Date. 

For information on the relevant go-live dates, see FAQ Q3.

If an LTID to FDID association is ended erroneously and must be reestablished, the Industry Member should populate the ltidEffectiveDate with the original LTID Effective Date- not the date that the record reestablishing the association is submitted to CAT CAIS. 

If an LTID to FDID association is ended for a legitimate reason and must be reestablished, the Industry Member should populate the ltidEffectiveDate with the date on which the LTID or ULTID became re-associated to the FDID within the CAT Reporter’s system- not the original LTID Effective Date. 

For the first phase (Limited LTID Account Information Reporting), starting on April 26, 2021, the Industry Member must also populate ltidEndreasonNull=true and ltidEndDateNull=true with the record reestablishing the LTID to FDID association. Beginning in the second phase (Full Customer and Account Reporting), Industry Members need only leave null or exclude the ltidEndDate and ltidEndReason attributes to clear previously set value.
 

Industry Members may resubmit the same record each business day but are not required to. If an Industry Member resubmits an identical record to one that already exists in CAT CAIS, CAT CAIS will overwrite the previous record with the new record with the same information. 

For the LTID Phase, it was permissible to exclude optional or conditional attributes previously submitted for an FDID or LTID, and no implicit update was made to these values stored in CAIS. If an Industry Member intended to clear a previously submitted value, it was required to use the paired NULL attribute for the field. 

For the Full CAIS Phase, Industry Members are required to include all attributes and associations for each record within the file. Industry Members are still only required to include records in their submission when changes occur to Active Accounts, however each record present in the file must contain the current state of attributes and associations of the record. The sole exception to this inclusion of all current attributes and associations is Customer associations that were previously stored, where the FDID is not included in the current submission but at least one of its associated Customers is included. For example, suppose a Customer Record was associated to both FDID 1234 and FDID 5678 and was previously accepted by CAIS. Later, the Industry Member must submit required updates for FDID 1234 but there were no changes to FDID 5678. All current attributes and associations for FDID 1234 must be reported to CAIS. Despite having a common Customer, the Industry Member is not required to submit all current attributes and associations for FDID 5678 because there are no changes to this FDID. Please see the Customer and Account Technical Specifications for Industry Members- Full CAIS for more information. 
 

Industry Members are only required to report LTIDs for active accounts. That is, accounts for which there is CAT reportable activity.

Account movements must be linked in CAIS beginning in Phase 2e (Full CAIS May 31, 2024).

Periodic Customer Account refreshes were not required in the LTID Phase but are required in the Full CAIS Phase. Note, FDIDs that are accepted in daily submissions will have met the refresh requirement. 

In light of the proposed amendment to the CAT NMS Plan regarding CAIS reporting requirements (see Securities Exchange Act Rel. No. 102665) (https://www.govinfo.gov/content/pkg/FR-2025-03-19/pdf/2025-04516.pdf), compliance with the Periodic Customer & Account Information Refresh has been delayed to a future to-be-determined date.

To provide time for testing ahead of the first Periodic Customer & Account Information Refresh Due Date, the first FDID Refresh Reports were delivered in the Test Environment on December 4, 2024 and will continue to be delivered on the third CAT Trading Day of each following month.

Additionally, the first FDID Refresh Reports were delivered in the Production Environment on January 6, 2025 and will continue to be delivered on the third CAT Trading Day of each following month. The refresh deadline will be reset for FDID Records that are refreshed in the Production Environment. The FDID Refresh Reports are being delivered in the Production Environment for testing purposes and unrefreshed FDIDs may display a Refresh Due Date in the past and a Status of OVERDUE. Since these FDID Refresh Reports are being delivered ahead of compliance with the first Periodic Customer & Account Information Refresh requirement (which, as noted above, has been delayed to a future to-be-determined date), these FDIDs are not subject to the compliance requirement until further notice. 

See the Periodic Customer & Account Information Refresh section of the CAT Reporting Customer and Account Technical Specifications for Industry Members-Full CAIS for more information.    
 

Concurrent with Phase 2c (April 26, 2021), LTIDs or ULTIDs associated with FDIDs must be reported in the LTID Phase of CAIS (“CAIS LTID”) when all three of the following conditions are met:

• a.    The Industry Member is a Large Industry Member (which is an Industry Member other than a Small Industry Member); AND

• b.    The FDID has an associated LTID or ULTID; AND

• c.    The FDID is reported in equities and/or options events to CAT on or after April 26, 2021. CAT Reportable Events requiring an FDID include:

  • i.     New Order, Trade and Order Fulfillment events (MENO, MENOS, MONO, MONOS, MENQ, MEOT, MEOTS, MEOF)

  • ii.    Equity Allocation events (MEPA, MEAA)

For an FDID reported in an equity and/or options event prior to April 26, 2021, the FDID is not required to be reported to CAIS until or unless that FDID is reported in an equity and/or options event occurring on or after April 26, 2021.

For example: 

A Large Industry Member has recorded FDID XYZ456 which has an associated LTID. On February 2, 2021, the Industry Member accepts a GTC order for FDID XYZ456. On April 26, 2021, FDID XYZ456 has no reportable activity even though the GTC order remains active. At 8:30 am ET on April 29, 2021, the GTC order for FDID XYZ456 is executed and reported on an MEOT. The Industry Member now has a CAIS reporting obligation and is required report this FDID and associated LTID information to CAIS no later than 8 am ET on April 30, 2021. For more information on reporting deadlines in the CAIS LTID Phase see FAQ Q21. 

Concurrent with Phase 2d (December 13, 2021), Large Industry Members must report any additional LTIDs or ULTIDs associated with FDIDs that have events reportable to CAT as of and including Phase 2d using the same conditions as above, with the addition of Option Allocation events (MOPA, MOAA).

In addition, Small Industry members must report LTIDs or ULTIDs associated with FDIDs that have events reportable to CAT as of and including Phase 2d using the same conditions as above, with the addition of Option Allocation events (MOPA, MOAA) by December 13, 2021.

NOTE: All firms satisfying the above criteria, including introducing and non-self clearing executing brokers, are required to begin reporting in the CAIS LTID Phase.

For more guidance regarding an LTID or ULTID being associated with an account, contact the SEC or see the SEC’s Large Trader Rule FAQs at https://www.sec.gov/divisions/marketreg/large-trader-faqs.htm.

For both phases, the CAT NMS Plan requires Industry Members to report Received Industry Member Data, which includes customer and account data, by 8:00 a.m. Eastern Time on the CAT Trading Day following the day the Industry Member receives such Received Industry Member Data. See CAT Alerts 2022-01 and 2023-01 for the Full CAIS Implementation Schedule. 

For example:

If the Industry Member receives Received Industry Member Data before 4:15 p.m. ET on T, then the Customer and Account data must be reported by 8:00 a.m. ET on T+1.

If the Industry Member receives Received Industry Member Data after 4:15 p.m. ET on T, then the Customer and Account data must be reported by 8:00 a.m. ET on T+2.

Also, as stated in FAQ Q43, while a firmDesignatedID value of ‘PENDING’ is acceptable for Transaction reporting, CAT CAIS will reject a firmDesignatedID value of ‘PENDING’. Thus, once the FDID becomes available, the Industry Member must report the actual FDID to CAT CAIS along with all other required Customer and Account information by 8:00 a.m. ET on T+1.

Received Industry Member Data not reported within these timeframes will not be marked late by the Plan Processor but will be subject to review by the applicable SRO.

See the Reporting and Repair Deadlines and Examples from the May 4, 2021 CAIS Technical Specification Working Group.
 

Yes. If an LTID or ULTID is associated with an account, it must be reported to CAIS in the LTID Phase. For more guidance regarding an LTID or ULTID being associated with and account, contact the SEC or see the SEC’s Large Trader Rule FAQs. See https://www.sec.gov/divisions/marketreg/large-trader-faqs.htm

Yes. If an introducing broker or non-self-clearing executing broker has Reportable Events for an account with associated LTIDs or ULTIDs, they must report such accounts to CAIS LTID as described in FAQ Q20.

Yes. See the Industry Member CAIS Onboarding Guide for details on production readiness certification.

Yes, all broker-dealers will be required to be certified in order to gain access to the CAIS Production environment. The certification may be supported by their Reporting Agent. See the Industry Member CAIS Onboarding Guide for details on production readiness certification.

Please see the Industry Member CAIS Onboarding Guide for complete details.

For the LTID Phase, Reporting Agents should aggregate the number of accounts with associated LTIDs across all of its broker-dealers (CRDs) it is reporting for. The certification requirements will apply against the aggregate totals of CAIS-reportable accounts with the added requirement that at least one record from every broker-dealer (CRD) that is reportable is included in the certification.

For the Full CAIS Phase, Reporting Agents must provide production data for at least 75% of the FDID population (aggregated across all CAT Reporters for which organization submits data) or 1,000 records, whichever is fewer. In addition, all CAT Customer record(s) corresponding to the submitted FDID records must be provided. Finally, the CAT Customer records for the submitted FDID records must include at least one of each TID Type where the Reporting Agent reports on behalf of a CAT Reporter that has at least one CAT Customer with that TID Type, including:

• SSN/ITIN for a US Natural Person
• EIN for a US Legal Entity
• FOREIGN for a non-US Natural Person or Legal Entity

CAIS LTID opened for Production on December 14, 2020. Once a CAT Reporter was certified, it was enabled to submit into Production. Any data submitted into Production, even before the April 26, 2021 mandatory reporting date, was considered “live” data and any changes to the reportable attributes of that account had to be reported. Certified Reporters were able to “stage” their CAIS LTID data into Production however they wished between December 14, 2020 and April 26, 2021.

See CAT Alerts 2022-01 and 2023-01 for a description of the Full CAIS Implementation Schedule.

Please see the Industry Member CAIS Onboarding Guide for more information.
 

Beginning April 26, 2021, Large Industry Members will be required to report into CAIS LTID all FDIDs with associated LTIDs or ULTIDs with Reportable Activity on or after April 26, 2021. Firms may choose to report accounts without associated LTIDs or ULTIDs, but there is no requirement to do so until the implementation of Full CAIS. See CAT Alerts 2022-01 and 2023-01 for the Full CAIS Implementation Schedule.

Yes. Proprietary trading firms must submit account information related to their own accounts to the CAT CAIS system. If the proprietary trading firm is itself a Large Trader, it is required to report its own accounts beginning with the LTID Phase of CAIS if it has Reportable Activity.

More information can be found at the SEC’s Large Trader Requirements FAQs. See https://www.sec.gov/divisions/marketreg/large-trader-faqs.htm.

Introducing and executing brokers are responsible for reporting the LTID information for the accounts of their clients, where they have reported New Order Events of that client to CAT and the account has an LTID.  For introducing and executing brokers who are self-reporting to CAT, clearing brokers should provide LTID information to those introducing and executing brokers to facilitate the timely and accurate reporting of such information.  For introducing and executing brokers who are not self-reporting to CAT, the clearing broker or any other CAT reporting agent might be engaged to report on their behalf.

Yes, Production data may be submitted to the CAIS Test environment. Optionally, data submitted to the CAIS Test environment can be obfuscated; however it is not required. For more information on testing in the CAT CAIS Test environment, see the Testing section of the CAT Reporting Customer and Account Technical Specifications for Industry Members.

For information on Production Readiness testing and data requirements for the Transaction Portal, see the Industry Member Onboarding Guide.

Because all CAIS data is maintained separately from transaction data for data security reasons, Industry Members are required to establish separate Reporting Relationships for CAIS. It is acceptable to have relationships with the same party for both CAT transaction data and CAIS; however they are separate relationships and will need to be separately established. CAT CAIS Reporting Relationships must be established to authorize another CAT Reporting Agent to submit on a firm’s behalf. Relationships must be established prior to any data submissions to the CAT CAIS Reporter Portal.

Firms transmitting data on their own behalf are not required to establish a relationship for themselves.

LTID identifiers are issued by the SEC. These are not publicly available. 

The requirements are detailed in the CAT CAIS Industry Member Onboarding Guide.

There is no record limit for files submitted to CAT CAIS through SFTP. However, files submitted through SFTP are limited to a maximum uncompressed size of 7GB. Files sizes <= 1GB are recommended as feedback will be returned faster. For more information, see CAIS Technical Specification section 5.1.3 – Data File Submission. Note that the file size recommendations for CAT CAIS are different from the file size recommendations for CAT Transaction reporting.

As explained in FAQs Q6 and Q31, CAT Reporters are required to obtain and report LTIDs to CAT, including introducing brokers and executing brokers that use separate clearing brokers. In contrast, Legal Entity Identifiers (LEIs) are not required to be disclosed to a broker-dealer, nor is a broker-dealer required to obtain an LEI from its customers. Further, there are no obligations imposed by SEC Rule 613 or the CAT NMS Plan to obtain an LEI from a customer for purposes of reporting it to CAT. Therefore, LEIs are only required to be reported to CAT if the CAT Reporter has otherwise obtained an LEI for a particular customer.  

The CAT NMS Plan requires Industry Members to “submit to the Central Repository” information  “including CRD number and LEI, if such LEI has been obtained.” “Central Repository” means the repository responsible for the receipt, consolidation, and retention of all information reported to the CAT pursuant to SEC Rule 613 and this Agreement. 
 
The CAT NMS Plan requirement does not require Industry Members to obtain an LEI, but rather to provide its LEI to the Plan Processor (FINRA CAT) if the Industry Member does have an LEI. The collection of the Industry Member’s LEI via the CAIS Registration Form and CAT Registration Form (Transaction Reporting) are separate from the reporting of customer account LEI data requirements. (For additional information pertaining to the LEI for customer accounts, see FAQs Q1 and Q4).  

Section 1.1 of the CAT NMS Plan defines “Active Accounts” as “an account that has had activity in Eligible Securities within the last six months.” Section 6.4(d)(iv) of the Plan, as well as the SRO CAT Compliance Rules, requires each Industry Member to “submit an initial set of the Customer information… for Active Accounts to the Central Repository [CAIS] upon the Industry Member’s commencement of reporting to the Central Repository [CAIS].”

This reportable activity includes all customer and proprietary accounts with any CAT-reportable events associated with the Firm Designated IDs (FDID), as well as any proprietary accounts for which the Industry Member utilizes the account number as the FDID. All accounts with any CAT-reportable activity on or after June 12, 2022 must be reported to CAIS with the implementation of Phase 2e (Full CAIS). See CAT Alerts 2022-01 and 2023-01 for the Full CAIS Implementation Schedule.

Also see FAQ Q41 regarding changes to customer and account records after June 12, 2022.
 

As outlined in FAQ Q40, all Active Accounts with activity on or after June 12, 2022 must be reported to CAIS with the implementation of Phase 2e (Full CAIS). Industry Members are required to report the current state of the customer information and account records in effect at the time the account is first required to be reported to the CAIS Production Environment. Per CAT Alert 2022-01, subsequent updates and changes to customer and account information must be reported to CAIS no later than November 7, 2022.

For example, a customer relocated from Address A to Address B in August 2022, and is residing at Address B on October 15, 2022 when Industry Member 1 is required to report this record to CAIS. The customer no longer has any association to Address A as of October 15, 2022. In this example, Industry Member 1 would only be required to report the current state of the account and customer information to CAIS (i.e., Address B) on October 15, 2022.
 

Prior to the CAT CAIS Implementation date (May 31, 2024), in this case where there are multiple dates associated with an account, CAT Reporters should report the fdidDate that is reasonably available. See CAT NMS Plan, Article 1, Section 1.1 definition of “Account Effective Date”. For example, if a CAT Reporter has physical account papers located in an offsite storage system and a different systematized date, both of which indicate that the account was opened prior to the CAT CAIS Implementation date, it is reasonable to use the systematized date as the fdidDate.

After the CAT CAIS Implementation date (May 31, 2024), the CAT Reporter must use the date that is reflected in its books and records as the fdidDate.
 

No. CAT CAIS will reject a firmDesignatedID value of ‘PENDING’. Once the FDID becomes available, the Industry Member must report the actual FDID in the firmDesignatedID field to CAT CAIS in the phase in which the Industry Member is required to report FDIDs to CAT CAIS. The CAT NMS Plan requires Industry Members to report Received Industry Member Data, which includes customer and account data, by 8:00 a.m. Eastern Time on the CAT Trading Day following the day the Industry Member receives such Received Industry Member Data. 

Beginning with the implementation of Phase 2e (Full CAIS), the addressList field at the account level is required to be populated for each FDID reported to CAIS. Industry Members must report one mailing address associated with the account in the ‘ADDRESS1’ value of the addrType field. The mailing address submitted is the destination where account correspondence is sent at the account level. In addition to the requirement to distinguish a mailing address for the account, Industry Members have the ability to report an additional three addresses associated with the FDID at the account level via the ‘ADDRESS2’, ‘ADDRESS3’, and ‘ADDRESS4’ values. If multiple addresses are associated with a particular account, then Industry Members must submit these additional addresses to CAIS if such address information is reasonably available. For example, Industry Members that maintain three mailing addresses for a particular account would populate such address information as addrType values of ‘ADDRESS1’, ‘ADDRESS2’, and ‘ADDRESS3’.

As noted in FAQ M12, the Firm Designated ID applies to a trading account, not to a particular Customer. However, in addition to supporting address records maintained at the account level, CAIS supports the ability for Industry Members to report up to four addresses associated with a particular customer record via the addressList field. In instances where an Industry Member maintains separate addresses at the account and customer level, then all such reasonably available addresses must be reported to CAIS.

For more information on the requirements for the data attributes for Customer information pursuant to the CAT NMS Plan, see Sections 9.1 and 9.2 of Appendix D.
 

As noted in FAQ Q44, if multiple addresses are associated with a particular account, then Industry Members must submit these additional addresses to CAIS if such address information is reasonably available. Further, FAQ Q44 states that in instances where an Industry Member maintains separate addresses at the account and customer level, then all such reasonably available addresses must be reported to CAIS.

While various addresses associated with a particular Account or Customer are of regulatory significance, the Plan Participants recognize that Industry Members may save several addresses in their records, some of which may contain legacy information. The requirement to report additional address information maintained by the Industry Member is not intended to change or supersede the Industry Members’ obligations to collect or maintain customer and account address information. Outside of Industry Members’ existing record keeping requirements and applicable SRO and SEC rules, there are no additional CAT CAIS-specific requirements to validate, audit or otherwise update and maintain such additional addresses by or at the time they are initially reported to CAT CAIS along with the full set of Customer and Account information with the implementation of Phase 2e (Full CAIS). Notwithstanding the above, additional addresses should be reported in the appropriate format to CAT CAIS.
 

For Customers with a US Taxpayer Identification Number (for example, social security number), Industry Members must not populate the customerType field with ‘FOREIGN’. ‘FOREIGN’ must only be used if the Customer is a Natural Person or Legal Entity that does not have a US Tax Identifier. Thus, Industry Members must choose one of the other allowable values to represent the CAT Customer associated to the FDID.

For the purposes of CAT CAIS, the value ‘ADVISER’ in the customerType field has the same definition as “Investment Adviser” in Section 202(a)(11) of the Investment Advisers Act of 1940.

Further, a customer is considered associated with a US registered Investment Adviser if they are such a person as defined as “a person associated with an investment adviser” in Section 202(a)(17) of the Investment Advisers Act of 1940.
 

The Industry Member must populate as ‘ADDRESS1’ the same principal business address as is listed on its Uniform Application for Broker-Dealer Registration (or “Form BD”). If the Industry Member listed a separate mailing address on its Form BD, it must populate this address as ‘ADDRESS2’. 

No. An Industry Member would not be required to re-activate a closed FDID in CAIS for post-account closure residual cash payments.  

No. CAT CAIS does not accept the GIIN for the foreignTIDType because the GIIN does not guarantee uniqueness as an Input Identifier to generate a foreignTIDType. Industry Members must obtain either a National Registration or Tax Identifier (‘NATIONALID’), Legal Entity Identifier (‘LEI’), or another Government Issued Identifier (‘OTHGOVT’) from the customer in order to generate a foreignTIDType for a foreign legal entity.

See FAQ Q63 for more information regarding how FDID Records should be reported to CAIS when the account holder is a foreign trust or foreign estate with no Input Identifier.

Prior to the implementation of full Customer and Account Reporting (May 31, 2024), if an Industry Member has not recorded the date on which the Customer entered into the specified role on the account, it may populate the roleStartDate field with a start date that is reasonably available. If no start date is reasonably available, the Industry Member may populate this field with the same value as the fdidDate. For example, if an Industry Member has physical account papers located in an offsite storage system, it is reasonable to use the associated fdidDate as the roleStartDate. Note that the fdidDate may not be used as a default date for the roleStartDate field.  

Starting on May 31, 2024, the Industry Member must populate the roleStartDate field with the date on which the Customer entered into the specified role on the account, according to the Industry Member’s books and records.
 

If the Industry Member’s practice is to close an account and open a new account in the scenario where there is a triggering event, the Industry Member must populate the “end date” fields with the date that is maintained in its books and records.

The updated record is required to be reported to CAT CAIS by 8:00 a.m. Eastern Time on the CAT Trading Day following the day the Industry Member confirmed the date in its books and records.

For example, the date of death of an account holder was January 1. The beneficiary notified the Industry Member on February 1 and requested closure of the account, but did not provide the required documentation (e.g., death certificate) until February 15. On February 16, the Industry Member confirmed the death of the account holder and started processing the account closure. The Industry Member must populate the “end date” fields with the date that is maintained in its books and records. However, the updated record is due by 8:00 a.m. Eastern Time on February 17 (assuming February 17 is a CAT Trading Day).
 

As stated in FAQ B53, transfers of securities during an account transfer between broker-dealers (e.g., ACATS transfers, transferring a Registered Investment Advisor (RIA) book of business from one Industry Member to another Industry Member and for a clearing firm when a correspondent firm changes to another clearing firm) are not orders, as defined by SEC Rule 613. Such account transfer activity as outlined above between Industry Members does not meet the definition of Mass Transfer of FDIDs across CAT Reporter Firms for CAT CAIS reporting requirements. As such, the Industry Member closing the account must populate the value of ‘ENDED’ in the roleEndReason, fdidEndReason, and ltidEndReason fields. The same guidance would apply to a firmDesignatedID (FDID) representing a Relationship ID or Entity ID.

The requirements to report mass transfer of FDIDs across CAT Reporters is limited in scope to mergers, acquisitions, and divestures. Refer to the Full CAIS Technical Specifications for Industry Members for more information.
 

If no address is stored at the FDID level, the Industry Member must choose one mailing address associated with one customer and report it as the mailing address associated to the FDID. Industry Members have the ability to report an additional three addresses associated with the FDID via the ‘ADDRESS2’, ‘ADDRESS3’, and ‘ADDRESS4’ values.

Although a specific methodology is not prescribed for choosing which address(es) to report to CAIS for the FDID, any methodology must be applied consistently by the Industry Member. In addition, the Industry Member must be consistent in its approach and methodology for populating the ‘ADDRESS2’, ‘ADDRESS3’, and ‘ADDRESS4’ values, if populated. Please see FAQs Q44 and Q45 for more information.
 

Resolving a Material Inconsistency requires that a Reporter follow the Material Inconsistencies Procedure as set forth in the Full CAIS Technical Specifications for Industry Members to confirm or correct the record that generated the Material Inconsistency. The Material Inconsistencies Procedure does not require the Reporter to contact the Customer to confirm the Customer’s information. For more information on Material Inconsistencies, see the Material Inconsistencies section of the Full CAIS Technical Specifications for Industry Members. 

The Industry Member is required to report Customer information for the entity authorized trader for this account to the CAT.  The Industry Member is not required to report Customer information for any natural persons who are employed by the entity authorized trader and who are authorized to trade for that account on behalf of the entity authorized trader, unless the account holder specifically designates the natural person employee as authorized to trade for the account independent of the authority granted to the entity authorized trader, in which case the Industry Member is also required to report Customer information for that natural person authorized trader to the CAT.  These requirements apply regardless of whether the account holder is a natural person or a legal entity.  

This FAQ response is based on the SEC Staff’s interpretation of the definition of “Customer” in Rule 613(j)(3) that natural persons who are employed by, and authorized to trade for an account on behalf of, an entity authorized trader are not considered different from the entity authorized trader.  The SEC Staff’s interpretation is similar to and consistent with the guidance provided by the SEC in footnote 388 of the Rule 613 Adopting Release, which states that “for the purposes of Rule 613(j)(3), natural persons who are employed by an entity that is an account holder, and who are authorized to trade for that account, are not considered different from the account holders, and are therefore not covered by Rule 613(j)(3)(ii).”   
 

In the event that a CAT Reporter has multiple valid Input Identifiers for a CAT Customer who is associated with a single account at the firm, then the CAT Reporter will need to select one of the Input Identifiers based on the following criteria. 

If there is more than one Input Identifier type for the CAT Customer, then CAT Reporter Firms must follow the hierarchy as outlined in Section 2.2.5 of the Full CAIS Technical Specifications for Industry Members. Specifically, if a US-assigned Input Identifier (i.e., SSN/ITIN or EIN) is available for the CAT Customer, then the CAT Customer must be reported to CAIS using a Transformed Identifier (TID) generated from the US-assigned Input Identifier. 

• For example, a dual citizen Natural Person CAT Customer provides a CAT Reporter with both a valid SSN and a National Identity Card for a country outside of the United States. In this example, the CAT Reporter firm would generate the TID value from the SSN. 

In the event the CAT Customer does not have a US-assigned Input Identifier but has more than one foreign Input Identifier of a specific type– such as multiple Tax Identifiers or multiple Legal Entity Identifiers (LEI) values – then the CAT Reporter Firm must determine which value is the primary, current value. If multiple values are current, the CAT Reporter firm must select the Input Identifier from the country/municipality of the primary incorporation or residence of the customer.

• For example, a Legal Entity CAT Customer is currently legally registered in both the United Kingdom and France, and provides the CAT Reporter with a Tax Identifier for both locations. The Customer indicates and/or the CAT Reporter ascertains that the United Kingdom is the primary incorporation of the Legal Entity.  In this example, the CAT Reporter would use the Tax Identifier for the United Kingdom to generate the TID value.
   

As noted above, the Full CAIS Technical Specifications require the Natural Person first and last names be reported in two separate fields. In the scenario where the Industry Member has historically maintained the Customer name in an unparsed state and will not be able to complete parsing of all Customer names by the implementation schedule set forth in CAT Alerts 2022-01 and 2023-01, the Plan Participants will temporarily make available a value of ‘UNPARSED’ to be populated in the firstName field. The unparsed name must be populated in the lastName field. Further, as soon as practicable, but no later than June 12, 2023, the Industry Member must resubmit the Customer Record to CAIS with the first and last names parsed and in the required separate firstName and lastName fields.

Use of the ‘UNPARSED’ value in the firstName field is only allowable until June 12, 2023. While the Plan Participants are providing this temporary solution to allow Industry Members to report the Customer Record to CAIS according to the implementation schedule set forth in CAT Alerts 2022-01 and 2023-01, an unparsed first and last name is not in compliance with the Plan and the Operating Committee-approved Technical Specifications which require that the first and last names be reported in separate fields. There is no exemptive relief that would allow the entry of Customer names in an unparsed state. Accordingly, use of the ‘UNPARSED’ value could be subject to review by Regulators.

An “Unparsed Names” Report will be made available to regulators and affected Industry Members. ‘UNPARSED’ will be retired from the Full CAIS Technical Specifications effective June 13, 2023.
 

All accounts, Relationships or Entity IDs (as represented by the FDID/Firm Designated ID) with any CAT-reportable activity (equities, options and/or multileg events) on or after June 12, 2022 must be reported to CAIS with the implementation of Phase 2e (Full CAIS). See CAT Alerts 2022-01 and 2023-01 for the Full CAIS Implementation Schedule. 

Example 1 (FDID in scope for Full CAIS reporting)

On June 22, 2020 (the Phase 2a Go-Live date), FRMA had an obligation to report a New Order event (MENO). The order remained open until August 17, 2022, when it was cancelled. Because the FDID had CAT-reportable activity after June 12, 2022, FRMA has a CAIS reporting obligation for this FDID. By contrast, if the open order did not have any subsequent CAT-reportable activity as of the date that FRMA was required to report this FDID to Full CAIS, FRMA would not have a CAIS reporting obligation for this FDID at that time.

Example 2 (FDID in scope for Full CAIS reporting)

FRMB received a customer order on June 12, 2022 and reported a MENO. The account was permanently closed off FRMB’s books on July 1, 2022. FRMB has a CAIS reporting obligation for this FDID because it had CAT-reportable activity on June 12, 2022. When FRMB is required to report this FDID to Full CAIS, it must submit this FDID Record with an fdidEndReason of ‘ENDED’ and fdidEndDate of July 1, 2022.

Example 3 (FDID NOT in scope for Full CAIS reporting)

FRMC is a clearing firm with an obligation to report post-trade allocation events (MEPA/MEAA/MOPA/MOAA). On June 22, 2021, FRMC allocated shares to FDID1234. As of June 12, 2022, there has been no further CAT-reportable activity for this FDID. Since there has been no CAT-reportable activity related to the FDID on or after June 12, 2022, FRMC does not have a CAIS reporting obligation for this FDID. However, should FDID1234 subsequently have any CAT-reportable activity, it will be in scope for Full CAIS reporting.

Example 4 (Business Model with no Full CAIS reporting obligation)

FRMD only accepts orders from other CAT Reporters and immediately routes them away for execution. Since FRMD only reports order accepted events (MEOA/MOOA/MLOA) and order route events (MEOR/MOOR/MLOR) which do not have the firmDesignatedID field on them, FRMD does not have a CAIS reporting obligation for this business model. However, if FRMD has firm-owned/controlled accounts (such as an error account) with activity on or after June 12, 2022, FRMD would have a CAIS reporting obligation for those firm-owned/controlled accounts.
 

Whether the Industry Member should be identified as a CAT Customer depends on whether the Industry Member is an account holder or has authority to place orders for the account without prior approval of the account holder(s). Absent this authority from the account holder(s) (and assuming the Industry Member is not an account holder in this scenario), receipt of a “Not Held” order does not require that the Industry Member be identified as a CAT Customer on the related FDID Record.

See FAQ Q56 for more information regarding when a natural person who is employed by an Authorized Trader must be identified as a CAT Customer.
 

Whether the Industry Member should be identified as a CAT Customer on the FDID Record depends on whether the Industry Member is an account holder or has authority to place orders for the account without prior approval of the account holder(s). Absent this authority from the account holder(s) (and assuming the Industry Member is not an account holder in this scenario), the Industry Member is not required to be identified as a CAT Customer on the related FDID Record when there are standing instructions on the account (such as the Industry Member purchase of shares in an Automated Investment Plan or Dividend Reinvestment Plan) or when an order is placed by the Industry Member to satisfy a legal requirement or SEC/SRO rule, such as a liquidation to satisfy a margin call. In addition, assuming the Industry Member is not an account holder and has not been given authority to place orders for the account without prior approval of the account holder(s), the Industry Member is not required to be identified as a CAT Customer on the related FDID Record when liquidating fractional shares held in a Customer’s account to facilitate operational processes (e.g., ACAT, an Industry Member buying a fractional share from a customer upon receipt of an order to exit its entire position in a security, or orphaned fractional positions). If an Industry Member uses a firm owned or controlled account to trade fractional positions against a Customer account, the Industry Member must report that firm owned or controlled account to CAIS. 

See the section titled “Fractional Share Scenarios” in the CAT Industry Member Reporting Scenarios document for more information regarding the transaction reporting requirements for fractional share scenarios.

See FAQ Q56 for more information regarding when a natural person who is employed by an Authorized Trader must be identified as a CAT Customer.

Yes. When reporting its version of the Customer Record, the clearing firm may replicate the attribute value for certain required data elements as provided by its correspondent firm. Specifically, when the correspondentCRD field is populated, the clearing firm may report a role of ‘AUTHREP’ for an Authorized Trader rather than “flipping” the role to ‘AUTH3RD’ on the clearing firm’s version of the Customer Record. Additionally, when the correspondentCRD field is populated, the clearing firm may report a customerType of ‘EMPLOYEE’ rather than “flipping” the customerType to ‘OTHBKR’ on the clearing firm’s version of the Customer Record.

In limited circumstances where a Legal Entity meets the following criteria:

• Foreign trust or foreign estate; and
• No allowable Input Identifier exists because the foreign country or foreign municipality does not require or issue any kind of identifier; and no LEI is assigned to the entity

The FDID Record may be reported to CAIS with no Customer Record for the foreign trust or foreign estate. However, all other CAT Customers (e.g., trustees that are Authorized Traders on the account) must be reported to CAIS with the customerType value of ‘TRUST’.  Additional information regarding the foreign trust or foreign estate may be required in future phases of CAT.

The above guidance must not be used in instances where an allowable Input Identifier value exists for the foreign trust or foreign estate (e.g., the foreign trust has a foreign Tax Identifier issued by a governmental authority, or an LEI issued by a Local Operating Unit), and only exclusively in those circumstances where no such value exists for the foreign trust or foreign estate.

When reporting an FDID Record for an account that is owned or controlled by an introducing broker/correspondent, it is acceptable for the clearing firm to report the accountType from the perspective of the introducing broker/correspondent. For example, if a clearing firm is optionally reporting the allocation of shares to an error account that is owned/controlled by a correspondent, and the account involved is marked as an error account in the clearing firm’s books and records, the clearing firm must populate the accountType field with ‘ERROR’ (Error account) indicating that the error account is owned/controlled by the correspondent. If the specific type of account involved in the allocation is not recorded in the clearing firm’s books and records, the clearing firm must populate the accountType field with ‘FIRM’ indicating an account owned by the correspondent. 

In the scenario where an Industry Member has systematized all data required to report a Natural Person Authorized Trader, it must report all information required for a complete Customer Record, including tidValue and yearOfBirth. However, in the scenario where an Industry Member has not historically collected and systematized all data required to report a Natural Person Authorized Trader and will not be able to collect and systematize the data by the Full CAIS Compliance Go-Live date per the implementation schedule as set forth in CAT Alerts – 2022-01 and 2023-01, the Plan Participants will have temporarily made available an Authorized Trader Names List on the FDID Record.

The Authorized Trader Names List will enable the Industry Member to report only the name of the Natural Person Authorized Trader having authority to trade on the Account, where they do not have all data required to report the Authorized Trader as a Natural Person CAT Customer. Each FDID submitted must still have at least one active association to a CAT Customer reported with a TID and all required data, with trading capabilities.

Use of the Authorized Trader Names List is only allowable on a temporary basis and, with sufficient time and notice, will be retired from the Full CAIS Technical Specifications at a future date. Thus, Industry Members will be required to resubmit the FDID Record to CAIS with all required data for a full CAT Customer Record.

While the Plan Participants are providing this temporary technical solution to allow an Industry Member to report an incomplete Customer Record for a Natural Person Authorized Trader to CAIS effective with the implementation of full Customer and Account Reporting (in lieu of having that Customer Record rejected), use of the Authorized Trader Names List is not in compliance with the Plan. There currently is no exemptive relief that would allow only the submission of an incomplete Customer Record for a Natural Person Authorized Trader. Use of the Authorized Trader Names List rather than the submission of all information required for Natural Person Authorized Traders could be subject to review by Regulators. Accordingly, Industry Members are encouraged to report all data required for Natural Person Authorized Traders as soon as possible before the Full CAIS Compliance Go-Live date.

The requirement to report to CAT CAIS a firstName, lastName, yearOfBirth, tidType and tidValue (i.e., a hashed version of an Input Identifier, such as a social security number) for all Natural Person Authorized Traders means that CAT may impose new recording and reporting obligations on some Industry Members with respect to obtaining Customer information to meet their CAT reporting obligations. Some Industry Members may have to change current onboarding activities to ensure Customer information is obtained and recorded for any Active Accounts with CAT Reportable Events, including for accounts that existed prior to the effective date of the CAT NMS Plan.
 

If an Industry Member optionally reports a DVP/RVP account that is temporarily not assigned a clearing number or DTC number because the account is new, or the current clearing number or DTC number has been removed from DTCC's ALERT service and no new clearing number or DTC number is available, the Industry Member must populate the DVPCustodianID field with ‘DTCRM’. Further, the DVPCustodianID must be immediately updated upon receipt of the new clearing number or DTC number.

The CAT NMS Plan requires that Industry Members report addresses at the Customer level. In response to industry feedback that broker-dealers generally maintain addresses at the account level rather than at the Customer level, Participants implemented a temporary technical solution that allowed a Customer to be reported to CAIS without an address and permitted Industry Members to report a minimum of one address for each account rather than an address for each Customer.

On September 13, 2021, the Participants requested exemptive relief from the requirement that Industry Members report addresses at the Customer level. The Commission has not acted on this request. Accordingly, there is no exemptive relief that would allow an Industry Member to report only addresses at the account level.

Therefore, effective July 12, 2023, each Customer must be reported to CAIS with at least one address (up to four addresses), and the requirement to report at least one address at the FDID level will remain. Further, Industry Members that reported Customers to CAIS without a Customer level address must report a Customer level address for such Customers to CAIS by no later than July 12, 2023.

Separately, effective August 7, 2023 in the Production Environment, a new validation will reject Customer Records submitted to CAIS without at least one address reported at the Customer level. Error Code 22514, which is currently in production, will be enhanced to cover this new validation on a go-forward basis.

In this situation, the minor or incapacitated person must be reported to CAIS with a role of ‘TRDHOLDER’ with the doingBusinessAs field populated with the value of ‘PUBLIC ADMINISTRATOR’. The Authorized Traders Names List must be included with the submission, and include the name of the government employee public administrator (e.g., U.S. state, county or municipality government employee). 

It is understood by the Plan Participants that a Customer Record with a role of ‘TRDHOLDER’ paired with the ‘PUBLIC ADMINISTRATOR’ value populated in the doingBusinessAs field represents a minor or incapacitated account holder who does not have authorization to trade on the account, and that the associated FDID Record is associated with a government employee Authorized Trader acting in the capacity as of a conservator or guardian for the account holder. This is an interim technical solution to allow these FDIDs to be accepted into CAIS prior to Full CAIS Compliance go-live. This guidance is specific to the scenario where the Natural Person government employee (rather than the Legal Entity) is appointed as the Authorized Trader.

The Industry Member may choose to report such Customer Records to CAIS in the manner outlined above so that the associated FDID Records can be accepted into CAIS and not be rejected due to Error Code 22071. However, given the limited number of FDID Records associated with this guardianship/conservatorship and government employee Authorized Trader fact-pattern, the Industry Member may also opt to resubmit such records to CAIS in the manner described above to CAIS following receipt of Error Code 22071 in its feedback. There currently is no exemptive relief that would allow an Industry Member not to report Customer Identifying Information for U.S. government employee Authorized Traders under Rule 613. In this situation, where the government employee Authorized Trader does not provide a year of birth or Input Identifier citing exemptions from the definition of “customer” under the Customer Identification Program Rule (31 CFR § 1023.100(d)), the Plan Participants are providing a temporary technical solution to allow an Industry Member to report the government employee Authorized Trader in the Authorized Trader Names List, rather than reporting a Customer Record. As noted in FAQ Q65, use of the Authorized Trader Names List is not in compliance with the Plan, is only allowable on a temporary basis and, with sufficient time and notice, will be retired from the Full CAIS Technical Specifications at a future date. Thus, Industry Members will be required to resubmit the FDID Record to CAIS with all required data for a full CAT Customer Record.

The Plan Participants will provide further guidance on this scenario before retirement of the Authorized Trader Names List and are evaluating the mechanism for reporting government employee public administrators to CAIS.
 

Per the Full CAIS Technical Specifications, each CAT Customer must only have one active role in association to the FDID at a time. Therefore, an attempt to associate two or more active CAT Customers with the same EIN to the same FDID will result in a rejection.

A disregarded entity is an entity that is disregarded as separate from its owner for federal income tax purposes. When a disregarded entity and its parent company have the same EIN and are both CAT Customers associated to the same FDID, Industry Members must report only one version of the Customer in association to the FDID, either the disregarded entity or the parent company. The CAT Customer must be identified in a role of ‘TRDHOLDER’, which indicates that the CAT Customer is a holder of the account that also has authorization to trade on the account. The data elements reported to CAIS (e.g., Address, Legal Name, LEI, etc.) in association with the Customer Record must be that of the chosen version of the CAT Customer. For example, when the disregarded entity and its parent company have the same EIN but different LEIs, and the Industry Member has reported the parent company as the CAT Customer associated to the FDID, the Industry Member must report the LEI of the parent company. See also FAQ Q4 for additional information regarding the reporting of LEIs for CAT Customers.

While the Plan Participants are providing this temporary solution to facilitate the partial reporting of Customer information to CAT in the context of disregarded entities, the reporting of only one CAT Customer where two CAT Customers are associated to the same FDID is not in compliance with the Plan. Accordingly, the Plan Participants have requested a temporary exemption from the SEC with respect to certain provisions of the CAT NMS Plan relating to this scenario. The reporting of both the disregarded entity and its parent company as CAT Customers associated to the same FDID may be required in future phases of CAT. 

When the disregarded entity and its parent company have different EINs and are both CAT Customers associated to the same FDID, Industry Members must report both versions of the Customers in association to the FDID. 

When the piggyback firm is fully disclosed, the correspondentCRD field must be populated with the CRD number of the introducing firm that has the relationship with the customer. For example, in a piggyback scenario where the piggyback firm is fully disclosed and Firm A (with customer relationships) piggybacks on Firm B’s clearing relationship with Clearing Firm C, the clearing firm must populate Firm A’s CRD number in the correspondentCRD field. 

See also FAQ U13 for additional information on allocation reporting for piggyback clearing scenarios.

Per the Full CAIS Technical Specifications, each CAT Customer must only have one active role in association to the FDID at a time. Therefore, an attempt to associate two or more active CAT Customers with the same SSN to the same FDID will result in a rejection.

When multiple trusts (or sole proprietorships) and a Natural Person have the same Tax Identifier (i.e., SSN) and are all CAT Customers associated to the same FDID, Industry Members must report only the Natural Person in association to the FDID with the doingBusinessAs field populated with only one of the trusts that shares the Natural Person’s SSN. The Natural Person must be identified in a role of ‘TRDHOLDER’, which indicates that the CAT Customer is a holder of the account that also has authorization to trade on the account. The Plan Participants are not prescribing a specific methodology for which trust must be reported in the doingBusinessAs field, and any methodology must be applied consistently by the Industry Member.

While the Plan Participants are providing this temporary solution to facilitate the partial reporting of Customer information to CAT, the reporting of only one CAT Customer where two or more CAT Customers are associated to the same FDID is not in compliance with the Plan. The reporting of the Natural Person and trusts with the same SSN as CAT Customers associated to the same FDID may be required in future phases of CAT.

When the trusts and Natural Person have different Tax Identifiers and are all CAT Customers associated to the same FDID, Industry Members must report all versions of the CAT Customers in association to the FDID.

In a Mass Transfer scenario, an “Active Account” is reportable to CAIS once there is Transaction-reportable activity for the FDID under the acquiring Industry Member’s CRD number. The Mass Transfer must be reported in accordance with the guidance in the Full CAIS Technical Specifications for Industry Members, including all applicable fields (e.g., priorCATReporterCRD and priorCATReporterFDID). The FDID must be reported to CAIS by 8 am ET on T+1 where T represents the CAT Trading Day of the Transaction-reportable activity. 

For example, if an FDID was acquired on calendar date October 1, but did not have any Transaction-reportable activity until CAT Trading Day November 15, the FDID is required to be reported to CAIS by 8 am ET on November 16 (assuming November 16 is a CAT Trading Day). 
 

The CAT NMS Plan requires Industry Members to synchronize their Business Clocks at a minimum to within 50 milliseconds of the time maintained by the National Institute of Standards (NIST), with the exception of Business Clocks used solely for Manual Order Events or the time of allocation on Allocation Reports, which must be synchronized to within one second of the NIST clock.

The CAT NMS Plan requires Participants to synchronize their Business Clocks at a minimum to within 100 microseconds of the time maintained by the NIST, consistent with industry standards, with the exception of Business Clocks used solely for Manual Order Events, which must be synchronized to within one second of the NIST clock.

An Industry Member must satisfy the CAT clock synchronization requirements for all of its Business Clocks. Business Clocks are defined as clocks used to record the date and time of any Reportable Event required to be reported under SEC Rule 613. If an Industry Member relies on a third-party service provider’s clocks, including, but not limited to, third-party service providers that are registered broker-dealers, to record the date and time of any of the Industry Member’s Reportable Events required to be reported under SEC Rule 613, such clocks are considered to be the Industry Member’s Business Clocks for purposes of the CAT clock synchronization requirements. Accordingly, the Industry Member has the ultimate responsibility for ensuring that such Business Clocks satisfy the CAT clock synchronization requirements. Industry Members also must satisfy the documentation, certification and violation reporting requirements related to clock synchronization as set forth in the Compliance Rule with regard to such third-party service providers’ clocks.

Industry Members will need to obtain information regarding clock synchronization procedures from their third-party service providers to satisfy these requirements. The amount of information an Industry Member must obtain from a third-party vendor may depend on whether the vendor is itself a registered broker-dealer. Industry Members would be expected to obtain at least the information specified below to satisfy the clock synchronization requirements provided in the Participants’ common CAT clock synchronization rule, although Industry Members may employ their own reasonable arrangements with their vendors to demonstrate compliance. Third-party vendors are encouraged to provide this information to Industry Members to facilitate compliance. Industry Members also would be expected to document in their own procedures the steps they take to perform this oversight of their vendors with respect to clock synchronization.

If its vendor is not a registered broker-dealer, an Industry Member should:

• On a reasonable periodic basis, receive and review the vendor’s clock synchronization procedures and copies of sample logs for consistency with the requirements of paragraphs (a) and (b) of the clock synchronization rule.
  • Specifically, an Industry Member should confirm that its vendor’s procedures apply the correct clock synchronization standard, call for Business Clocks to be synchronized every business day before market open to ensure that timestamps for Reportable Events are accurate, provide for re-synchronization throughout the day as necessary, and provide for sufficient log creation, retention, and accessibility (consistent with FAQ R.6 below).
  • An Industry Member should also periodically review copies of sample logs for verification
• Receive an attestation or comparable written assurance to provide the Industry Member a sufficient basis to complete the certification required by paragraph (c) of the clock synchronization rule.
  • Specifically, the attestation or comparable written assurance should communicate to the Industry Member that the vendor complied with paragraph (a) of the clock synchronization rule by synchronizing its Business Clocks to the correct clock synchronization standard and maintaining such synchronization. This attestation or comparable written assurance could use the same language that is used on the certification form that each Industry Member must execute annually.
• Receive alerts from its vendor so that it can report violations as required by paragraph (d) of the clock synchronization rule, once violation reporting thresholds are in effect.

If its vendor is a registered broker-dealer, an Industry Member should:

• Receive a copy of the certification that the vendor completed as required by paragraph (c) of the clock synchronization rule.
• Receive a supplemental attestation concerning the vendor’s compliance with the documentation requirements in paragraph (b) and, once violation reporting thresholds are in effect, the violation reporting requirements in paragraph (d).
  • An Industry Member that receives such an attestation from its vendor would not itself need to submit violation reports that would be duplicative of reports submitted by its vendor.
  • The supplemental attestation may be provided at the same time the vendor provides a copy of its yearly certification required by paragraph (c).

In addition, to the extent that the Industry Member has any Business Clocks other than those of the third-party service provider, then the Industry Member must satisfy the CAT clock synchronization requirements, as well as the documentation, certification and violation reporting requirements related to clock synchronization set forth in the Compliance Rule, with regard to those Business Clocks.

The CAT NMS Plan does not disallow the use of manually written timestamps provided the clock referenced is synchronized properly.

Computer system and mechanical clocks must be synchronized every business day before market open. To maintain clock synchronization, clocks should be checked against the NIST atomic clock and re-synchronized, if necessary, throughout the day. Industry Members must document and maintain their clock synchronization procedures.

All Industry Members that have Business Clocks that are subject to the clock synchronization requirements must document and maintain their synchronization procedures and keep a log of the times when they synchronize their Business Clocks and the results of the synchronization process. The Participants expect that each Industry Member will synchronize its Business Clocks every business day before market open, and check synchronization at pre-determined intervals throughout the business day, to reasonably ensure that Business Clocks maintain synchronization. The Participants also expect that each Industry Member’s synchronization log will document whenever a Business Clock fails to be within the applicable tolerance of the time maintained by NIST.

Yes. Firms required to synchronize their clocks according to the CAT NMS Plan should keep a log of the times when they synchronize their clocks and the results of the synchronization process. This log should include notice of any time the clock drifts more than allowed by the CAT NMS Plan. Logs must be maintained consistent with the five-year retention period in paragraph (b) of the Participants’ common clock synchronization rule and accessible to the firm or made available by the firm in response to a regulatory request on a reasonably prompt basis whether maintained and preserved on site or by a third party.

The Annual Clock Synchronization Certification Form certifies that the Industry Member’s Business Clocks satisfied the synchronization requirements of the CAT compliance rule for the prior calendar year.

This FAQ has been archived and moved to Archived FAQs.

This FAQ has been archived and moved to Archived FAQs.

Multiple oversight mechanisms are established so that the Plan Processor and the CAT System secure CAT Data.

Among other things, the CAT CISO has a fiduciary responsibility to Consolidated Audit Trail, LLC and is responsible for overseeing the security of the CAT System and the Plan Processor. Additionally, the CAT System is an SEC Regulation SCI System of FINRA CAT and of the individual Plan Participants. As such, it is subject to the oversight mechanisms of the SEC and subject to Reg SCI exams performed by the SEC’s Division of Examinations’ Technology Controls Program.

Security oversight is informed by independent and third-party assessments, including recurring Independent Validation and Verification (IV&V) of the NIST SP 800-53-based security control framework and third-party penetration testing and code review. FINRA CAT has also participated in Department of Homeland Security Cybersecurity & Infrastructure Security Agency (DHS CISA) assessments and exercises. 
 

This FAQ has been archived and moved to Archived FAQs.

The CAT contains information about orders, quotes, and transactions for all NMS Securities (i.e., exchange-listed equities and options), as well as OTC Equity Securities across U.S. markets, including related events such as origination, modification, cancellation, routing, and execution, reported by Industry Members and Plan Participants to the order and trade subsystem. This includes a limited set of associated customer and account information reported by Industry Members to the segmented Customer Account and Information Subsystem (CAIS). Industry Members are directed not to report social security numbers, customer account numbers, or dates of birth to CAIS.

a.    What is Customer Account Information and Customer Identifying Information?

SEC Rule 613 requires that the CAT collect certain information about each customer in a securities transaction. In March 2020, and prior to the collection of any customer information, the SEC approved an exemption requested by the Plan Participants to eliminate the requirement for Industry Members to report social security numbers, customer account numbers, and birthdates to CAIS. Specifically, pursuant to the exemption, Industry Members are to report the following Customer Account Information and Customer Identifying Information to CAIS:

Customer Account Information includes information such as account type, account status, and key account dates (e.g., date account opened, closed). Industry Members are prohibited from reporting customer account numbers to CAIS.

Customer Identifying Information includes, with respect to individuals, information such as name, address, year of birth (NOT the full date of birth), and role in the account (e.g., primary holder, joint holder, etc.)  Industry Members are PROHIBITED FROM REPORTING SOCIAL SECURITY NUMBERS (SSNs) TO CAIS.  In lieu of submitting SSNs, Industry Members generate and report a Temporary Identifier (TID). This TID is further tokenized by the Plan Processor to create an internal CAT Customer Identifier (CCID) that is not to be shared outside of CAT. This process, referred to as the “CCID Alternative” in the March 17, 2020 SEC Order, implements a CCID generation strategy that insulates the CCID generation process from the CAT Central Repository and avoids the need for Industry Members to submit SSNs to CAIS. The CCID Alternative was developed in consultation with Industry Member security experts and was facilitated by the Securities Industry Financial Markets Association (SIFMA).

b.    Must social security numbers, customer account numbers, or dates of birth be reported to CAIS?

No. In March 2020, the SEC approved the Plan Participants’ exemptive request to eliminate the requirement for Industry Members to report social security numbers, full dates of birth, and customer account numbers to CAIS. Reporting specifications explicitly provide that Industry Members are prohibited from reporting such information to CAIS. Instead of reporting full date of birth, reporters are required to report only year of birth for Natural Persons.
 

This FAQ has been archived and moved to Archived FAQs.

This FAQ has been archived and moved to Archived FAQs.

Access to CAT Data is limited to the SEC and SRO regulatory staff, with access to customer and account data (which is stored and handled separately from the order and trade data) further restricted. Participants’ authorized regulatory users must execute a Safeguard of Information Affidavit prior to access, which provides, among other things, that authorized regulatory users must maintain the confidentiality and security of CAT Data and only use CAT Data for regulatory purposes. In addition, a CAT Security Awareness Training Course is made available to all authorized regulatory users by the Plan Processor; Participants’ authorized regulatory users are required to complete the training prior to accessing CAT Data.

In accordance with the objective set forth in the Rule 613 Adopting Release and the CAT NMS Plan Approval Order, the CAT is used to enable the analysis and reconstruction of broad-based market events, facilitate market analysis in support of regulatory decisions, and support market surveillance, investigations, and other enforcement activities.

A limited number of Plan Processor personnel may also access the data in conjunction with supporting operation of the CAT System. These Plan Processor personnel are subject to various controls including execution of a Safeguard of Information Affidavit, background checks, CAT-specific security awareness training, and security monitoring. 

This FAQ has been archived and moved to Archived FAQs.

The CAT System is designed from the ground up with security as a core principle. The system’s architecture provides for a separation between systems that handle transaction data and those that handle customer/account data. The CAT cannot be queried via the internet with its architecture instead restricting query access to be via private circuits with the authorized regulators. Multifactor authentication (MFA) is required. Data is encrypted at-rest and in-transit.

As provided by the CAT NMS Plan, CAT System security controls are guided by National Institute of Standards and Technologies (NIST) SP 800-53, a set of security and privacy controls for federal information systems and organizations. The implementation of these controls is generally subject to regular third-party independent validation and verification. Independent third-party code security review and penetration testing is performed in accordance with the CAT NMS Plan.

Entitlements are periodically reviewed. SRO users and Plan Processor staff undergo CAT-specific security awareness training, and SRO users and Plan Processer staff are each required to execute a Safeguard of Information Affidavit.

This suite of controls is designed to protect the CAT system from unauthorized access. The security program also incorporates plans to respond to and recover from a security event in case one should occur. Accordingly, FINRA CAT maintains an Information Security Incident Response Plan (ISIRP).

This FAQ has beeen archived and moved to Archived FAQs.

Industry testing is performed in an environment separate from the Production Environment. The security of the Industry Testing environment is equivalent to the production environment however, with production-level security controls enforced.

The requirements are detailed in the Industry Member Onboarding Guide.

Industry Members may use multiple CRAs to submit data to CAT. For production readiness testing, each of the Industry Member’s CRAs must submit its portion of a full day of production data to the Test Environment; it does not have to be on the same processing date or for the same trade date. However, an Industry Member will not be granted access to Production until all CRAs have reported and the Industry Member achieves a combined error rate of less than 10% across all CRA submissions.

No. The Industry Member should contact the FINRA CAT Helpdesk to declare a subsequent day for which it will submit a production readiness test.

Yes. Industry Members are required to complete production readiness testing for Phase 2a reporting by June 8, 2020.  This deadline, which was previously April 6, 2020, was extended in light of the SEC’s exemptive order, which moved the date by which Industry Members must begin reporting Phase 2a data from April 20, 2020 to June 22, 2020. Notwithstanding the June 8, 2020 deadline, because Industry Members must successfully complete production readiness testing before being granted access to the production environment, production readiness testing will remain available after June 8, 2020. 

No. Industry Members that have successfully completed their production readiness certification for Phase 2a equities do not have to recertify before submitting production options data.

Phase 2b production readiness testing for Industry Members not submitting equities data in Phase 2a must be completed by July 6, 2020. This deadline, which was previously May 4, 2020, was extended in light of the SEC’s exemptive order, which moved the date by which Industry Members must begin reporting Phase 2b data from May 18, 2020 to July 20, 2020.  Notwithstanding the July 6, 2020 deadline, because Industry Members must successfully complete production readiness testing before being granted access to the production environment, production readiness testing will remain available after July 6, 2020.   

No. If an Industry Member or CAT Reporting Agent coded a role of ‘AUTH3RD’ for the scenario where the reporting Industry Member itself has authority to place orders for the Account without prior approval of the account holder(s) and is not the holder of the account, the Industry Member and/or its CAT Reporting Agent can certify for Full CAIS production with the previous description of the ‘AUTH3RD’ value, assuming the Industry Member and/or its CAT Reporting Agent meet the production readiness requirements as set forth in the Industry Member CAIS Onboarding Guide. However, effective June 12, 2023, the role field must be accurately populated with ‘AUTHREP’ as set forth in the Full CAIS Technical Specifications.

Starting in Phases 2c (for equities) and 2d (for options), “if available in the booking system” means that the FDID is either directly available in the booking system, or can be made available through a simple reference data lookup, or can be readily accessed by the booking system through an existing system integration. For example, if the FDID is directly stored or can be directly queried by the booking system, the newOrderFDID field should be populated. In contrast, if, in order to supply the FDID, a new system integration would be required or if new data element(s) were required in the booking record, then the newOrderFDID field would not be required to be populated. It should also be noted that requirements for populating this field may be expanded in future phases of CAT.

The CAT NMS Plan defines an Allocation Report as “a report made to the Central Repository by an Industry Member that identifies the Firm Designated ID for any account(s), including subaccount(s), to which executed shares are allocated”. This includes the booking of shares/contracts into the same account for which an order was originally placed, and the booking of shares/contracts into an account based on allocation instructions (e.g., subaccount allocations).

Allocation Reports are reported to CAT via the Post-Trade Allocation (MEPA) and Option Post-Trade Allocation events (MOPA). The CAT reporting obligation for allocation events belongs to the firm performing the allocation, which is generally the clearing or self-clearing firm processing the allocation.

The answer depends on whether the Industry Member is self-clearing, and therefore responsible for reporting both the new order events and the allocation events involving the same FDID assigned by the self-clearing firm.  For Industry Members that are self-clearing, the FDID on the MENO/MONO must be the same as the FDID on the MEPA/MOPA when an order is placed directly into the customer account. In this scenario, the newOrderFDID field must be populated on the Industry Member’s MEPA/MOPA event, and would be the same as the value populated in the firmDesignatedID field. 

For Industry Members that are not self-clearing, the FDID on the MENO/MONO, which is assigned by the correspondent firm, may be different from the FDID on the MEPA/MOPA, which is assigned by the clearing firm.  If the clearing firm knows the FDID assigned by the correspondent firm that was reported on the MENO/MONO, the clearing firm must populate it in the newOrderFDID field on the clearing firm’s MEPA/MOPA event.
 

Allocation events are not required to be linked to particular orders or executions.

Allocations to firm owned or controlled accounts are not required to be reported but may optionally be reported. If an Industry Member chooses to report such an allocation, it must populate the firmDesignatedID field with the FDID of the firm owned or controlled account. Additionally, the allocationType field must be populated with the value, ‘FRM’.

Yes, allocations to DVP accounts are required to be reported by the executing broker-dealer or clearing firm of the executing broker-dealer if the executing broker is not self-clearing. The firmDesignatedID field must be populated with the FDID of the DVP account. Additionally, the allocationType field must be populated with the value, ‘DVP’; and the DVPCustodianID field must be populated as described in the CAT Reporting Technical Specifications for Industry Members.

The clearing firm may know the introducing broker-dealer’s FDIDs, in which case the firmDesignatedID in the introducing broker-dealer’s MENO/MONO may be the same as the firmDesignatedID in the clearing firm’s MEPA/MOPA. In this scenario, the clearing firm would also be required to populate the correspondentCRD and newOrderFDID fields. 

Further, the clearing firm may report the introducing broker-dealer’s customer and account information to CAT on behalf of the introducing broker-dealer. However, since both Industry Members have a separate CAT reporting obligation involving the FDID, each Industry Member must separately register the FDID under their CAT IMID.

Note that it is not required that the clearing firm know the introducing broker-dealer’s FDIDs in which case the firmDesignatedID in the introducing broker-dealer’s MENO/MONO would not be the same as the firmDesignatedID in the clearing firm’s MEPA/MOPA. In this scenario, the clearing firm would also be required to populate the correspondentCRD field. 
 

Yes, all allocations to customer accounts are required to be reported even if the shares are only held there temporarily. In this scenario, the self-clearing firm would have to report the allocation to the RIA’s average price account as well as the subaccount allocations to the individual customer accounts. 

The eventTimestamp on an Allocation event should reflect the date and time when the shares or contracts allocated are booked into the customer or client’s account. For firms that have multiple “booking times” that are captured in their backend system, this is the booking time that reflects the placement of shares or contracts into the customer account.

No. CMTAs are not allocations, as defined by SEC Rule 613. Therefore, CMTAs are not required to be reported to CAT. However, CMTAs may optionally be reported to CAT in the Option Post-Trade Allocation (MOPA) and Option Amended Allocation (MOOA) events using the allocationType value of ‘CMTA’ and populating the occClearingMemberID field.

No, allocation events are required to be submitted to CAT by 8 am ET on the next “CAT Trading Day.” “CAT Trading Day” is defined as beginning immediately after 4:15:00 pm and no fractions of a second Eastern Time on one trade date and ending at exactly 4:15:00 pm and no fractions of a second Eastern Time on the next trading date. For example, an allocation performed at 10 pm ET on Monday (part of Tuesday’s CAT Trading Day) would have to be reported by 8:00 am on the next CAT Trading Day, which would be by 8:00 am on Wednesday. For more information and examples of reporting deadlines, please refer to the Reporting Deadline Examples in the CAT Reporting Technical Specifications for Industry Members. 

The CAT reporting obligation for the allocation belongs to Firm A because it knows the customer and performs the allocation. 

When the piggyback firm is fully disclosed, the clearing firm has the obligation to report the allocation. The correspondentCRD field should be populated with the CRD Number of the introducing firm that has the relationship with the customer. For example, Firm A piggybacks on Firm B’s clearing relationship with Clearing Firm C. In this case, the clearing firm should populate the correspondentCRD field with Firm A’s CRD Number.

If an allocation is updated such that a CAT reportable attribute is changed after the shares/contracts have been booked in a customer or client account, then an Amended Allocation event (MEAA) or Option Amended Allocation Event (MOAA) may be reported to CAT reflecting the corrected details of the allocation. 

For example, an equity allocation is booked to an account at 5:15 pm. Subsequently, at 6:30 pm, the clearing firm updates a CAT reportable attribute. In this scenario, the original booking at 5:15 pm must be reported as a Post-Trade Allocation event (MEPA) and the update to the booking at 6:30 pm may be reported to CAT as an Amended Allocation event (MEAA). Changes that do not impact CAT reportable attributes must not be reported to CAT as Amended Allocation events. 

Yes. An Allocation Report is required when executed shares/contracts are allocated to an account when the account is purchasing shares (shares are placed in account) and when the account is selling shares (shares are delivered from the account). Designation of a purchase or sale is reported as the “side” of the allocation.

No, allocations to any account owned or controlled by a broker-dealer are not required to be reported to CAT as Post-Trade Allocation (MEPA) or Option Post-Trade Allocation (MOPA) events. Allocations to an account owned or controlled by a broker-dealer may be optionally reported to CAT but must be properly identified as such by populating the allocationType field with one of the allowable values indicating an optionally reported allocation as defined in the Industry Member Technical Specifications (for example, ‘FLP’ (Correspondent Flip)). In addition, effective July 11, 2022, the accountHolderType field must be populated on allocation events. When optionally reporting an allocation to an account owned or controlled by a broker-dealer:

• If the specific account holder type is recorded in the Industry Member’s books and records, it must choose the applicable allowable value. For example, if an Industry Member is voluntarily reporting a CMTA and the account involved is recorded in the Industry Member’s books and records as an institutional account as defined in FINRA Rule 4512(c), it must use the accountHolderType ‘A’ (Institutional Customer – An institutional account as defined in FINRA Rule 4512(c))
• If the specific account holder type is not recorded in the Industry Member’s books and records, it must populate the accountHolderType field with ‘P’ (Other Proprietary).

Note that average price accounts designated exclusively for a specific customer (not a broker-dealer) are always considered customer accounts.

Example 1 (Allocation report NOT required but may be voluntarily reported)

A clearing firm books shares into an average price account that is owned or controlled by an Introducing Broker (IB) before the IB provides allocation instructions to the final customer accounts. When optionally reporting allocations to an account that is owned/controlled by an introducing broker/correspondent, it is acceptable for the clearing firm to report the accountHolderType from the perspective of the IB/correspondent. In this example, since the clearing firm knows it is allocating shares to an average price account that is owned/controlled by its IB, the clearing firm must populate the accountHolderType field with ‘V’ (Firm agency average price account) indicating that the average price account is owned/controlled by the IB.

Example 2 (Allocation report NOT required but may be voluntarily reported)

An executing self-clearing firm receives an order from another broker-dealer. The order is executed, and the shares are booked into an account that is owned or controlled by the other broker-dealer before allocation to the final customer accounts. 
 

Changes to CAT reportable attributes of an allocation after the original booking of shares/contracts are required to be reported to CAT as either an Amended Allocation/Option Amended Allocation (MEAA/MOAA) event or the cancellation of a Post-Trade Allocation/Option Post-Trade Allocation (MEPA/MOPA) event followed by a new Post-Trade Allocation/Option Post-Trade Allocation event regardless if they occur pre-settlement or post-settlement. 

If the trade date of the allocation is prior to the mandatory reporting date for allocations (Phase 2c for equities and Phase 2d for options), then any amendments made to the allocation after the applicable CAT allocations reporting go-live date are not required to be reported to CAT. 

The DVPCustodianID field in the Post-Trade Allocation event (MEPA) should accurately reflect the settlement instructions on the account (not the entity) to which shares are placed or from which shares are delivered at settlement. A Depository Trust Company (DTC) number should be reported if the account where the shares are allocated will settle the transaction via DTC. If there is no DTC Number associated with the account because the allocation involves a foreign entity, or the shares will settle via a foreign settlement mechanism (e.g., Euroclear), then the value of ‘FOREIGN’ should be used.

Refer to FAQ U24 where the DTC number related to transactions that do not involve a foreign entity is not available at the time of allocation.

Yes, it would be acceptable to use an end of day currency conversion rate.

If the side value ‘SX’ is available in the Industry Member’s booking system, then it should be reported on the MEPA. If it is not available in the booking system, then the side value ‘SS’ should be reported on the MEPA.

In Phase 2c, allocations to an average price account that is held either in the name of a specific client of the Introducing Broker or is associated in the clearing firm’s systems with a specific client of the Introducing Broker are required to be reported to CAT. The allocationType for these allocations may be marked as ‘CUS’ (Allocation to a custody account) or ‘DVP’ (Allocation to a DVP/RVP accounts). 

Starting in Phase 2d, Industry Members may choose to optionally report these allocations. If optionally reported, the allocationType field must be populated with ‘FRM’ (An allocation to a firm owned or controlled account). 
 

The term “booking” is the recording of the details related to shares/contracts owed to or delivering out of an account to the firm’s books and records. “Original Booking” is the first reasonably available time details of shares/contracts owed to or delivering out of an account are recorded to a firm’s books and records. Due to diverse post-trade processing models (e.g., batch, intraday, and real-time processing), firms should use the first reasonably available original booking time to reflect the eventTimestamp on a Post-Trade Allocation event/Option Post-Trade Allocation (MEPA/MOPA). Changes to CAT reportable attributes of an allocation after the original booking of shares/contracts are required to be reported to CAT as either an Allocation Amendment event or the cancellation of a Post-Trade Allocation event followed by a new Post-Trade Allocation event regardless if they occur pre-settlement or post-settlement. (also see FAQ U14)

Because the identity of the prime broker is a required element on the allocation report to a DVP account, the allocation report cannot be reported to CAT until the DVPCustodianID is known to the clearing broker. The allocation eventTimestamp should represent the time all required elements, including the DVPCustodianID, are known to the Industry Member clearing broker.

Allocation events for shares/contracts initially booked to an account or changes to shares/contracts that were initially booked to an account prior to April 26, 2021 (Phase 2c - Equities) or December 13, 2021 (Phase 2d – Options) are not required to be reported to the CAT. This includes any actions subsequent to the initial booking, such as allocation amendments or cancel/rebills. 

The Industry Member may choose to optionally report an Amended Allocation event (MEAA) or Option Amended Allocation event (MOAA) to the CAT for amendments to an allocation that initially occurred prior to April 26, 2021 (Phase 2c – Equities) or December 13, 2021 (Phase 2d – Options).  The allocationKeyDate field on these optionally reported MEAA/MOAA events must be populated with the applicable date prior to April 26, 2021 (For Equities) or December 13, 2021 (For Options). 

For example, an equity trade was executed on February 23, 2021 and the shares were initially booked to a customer account the following day (February 24, 2021). The allocation was subsequently amended on May 5, 2021, either through an amendment or a cancel/rebill. No CAT reports are required for any actions taken in this example. The Industry Member may optionally choose to report an MEAA to CAT for the amendment occurring on May 5, 2021, but must populate the allocationKeyDate field with a date of February 24, 2021, which is the date of the initial booking and the date on which the allocationID was assigned.
 

No.  As noted in FAQ K4, options assignments and exercises are not orders, as defined by SEC Rule 613, and therefore are not required to be reported to CAT.  Therefore, Industry Members are also not required to report the resulting booking of shares into a customer account resulting from an options assignment or exercise.  Similarly, Industry Members are not required to report the booking of shares or contracts into a customer account resulting from other non-CAT Reportable events (e.g., conversions of a convertible bond into an equity, ADR creations and cancellations, ETF creations and redemptions, ACATS transfers). Additionally, Industry Members are not required to report the booking of shares to a customer account for the OTC equity symbol of a foreign security if it is known that the related transaction was not reportable to CAT. However, if it is not known in the firm’s booking system that the booking of shares to a customer account was related to an event (or a transaction in an OTC equity symbol of a foreign security) that was not reportable to CAT, Industry Members must report such allocations to CAT and use the applicable allocationType as set forth in the Industry Member Technical Reporting Specifications.  For example, an allocation to a custody account should be reported with an allocationType of ‘CUS’.

Allocations in “when-issued” securities do not have a settlement date, as the settlement occurs once the symbol starts trading “regular-way”. In Phase 2c, the settlementDate field may be populated with any future date (e.g. 12/31/2099) in order for CAT to accept the record as settlementDate is a required field. From May 10, 2021, onwards, the settlementDate field will be made conditional and will not be required for “when-issued” securities. 

Beginning in Phase 2d, the settlementDate field must not be populated for allocations in “when-issued” securities with any future date.
 

In a mixed side marking scenario, the Industry Member must report the ‘SL’ (Sell Long) value in the side field of the Post Trade Allocation event (MEPA). For example, a customer sells long and short throughout the day, and the associated CAT Transaction reporting is appropriately identified for the street side fills as long sales and short sales (e.g., ‘SL’ (Sell Long) and ‘SS’ (Short Sale) in New Order events). The customer's transactions are averaged out at the end of the day at the time of booking to the client account, and a MEPA is reported to CAT with a side of ‘SL’. This guidance does not apply to Options Post Trade Allocation Events, as the side value of ‘S’ (Sell) must be used. 

Yes. When reporting an allocation event or amended allocation event, the clearing firm may report the accountHolderType from the perspective of the correspondent firm rather than “flipping” the accountHolderType to the perspective of the clearing firm. 

For example, if a clearing firm is reporting an allocation to an account that is owned by a correspondent’s employee, and the clearing firm’s books and records reflect a beneficial owner of employee, the clearing firm may populate the accountHolderType field with ‘E’ (Employee Account) rather than “flipping” the perspective to one of the other allowable values.