pubdate: October 1, 2012 effdate: October 1, 2012
- 34-67457 Consolidated Audit Trail
-Topic: SEC Final Rule, Release No. 34-67457
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ citation: N/A
+ pubdate: February 28, 2019 effdate: N/A
+ CAT Industry Member Reporting Scenarios
+Topic: CAT Industry Member Reporting Scenarios
+ Compliance User: Industry Member
Keywords:
- NMS Plan,
- SRO,
+ Technical Specification,
- AGENCY: Securities and Exchange Commission
-ACTION: Final rule.
-SUMMARY: The Securities and Exchange Commission ("Commission") is adopting Rule 613 under the Securities Exchange Act of 1934 ("Exchange Act" or "Act") to require national securities exchanges and national securities associations ("self-regulatory organizations" or "SROs") to submit a national market system ("NMS") plan to create, implement, and maintain a consolidated order tracking system, or consolidated audit trail, with respect to the trading of NMS securities, that would capture customer and order event information for orders in NMS securities, across all markets, from the time of order inception through routing, cancellation, modification, or execution.
-EFFECTIVE DATE: October 1, 2012
-FOR FURTHER INFORMATION CONTACT: Rebekah Liu, Special Counsel, at (202) 551-5665; Jennifer Colihan, Special Counsel, at (202) 551-5642; Carl Tugberk, Special Counsel, at (202) 551-6049; or Leigh Duffy, Special Counsel, at (202) 551-5928, Division of Trading and Markets, Securities and Exchange Commission, 100 F Street, NE, Washington, DC 20549-7010.
-pubdate: N/A effdate: N/A
- SUPPLEMENTARY INFORMATION:
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ (For IM Technical Specification v1.1)
+2/28/19 DRAFT Version 1.1
+pubdate: N/A effdate: N/A
+ Executive Summary
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary
+ Compliance User: Industry Member
Keywords:
- Summary,
+ Technical Specifications,
+ CAT NMS plan,
- pubdate: N/A effdate: N/A
- I. Executive Summary
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Executive Summary
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ This document is a companion document to the CAT Reporting Technical Specifications for Industry Members (“Technical Specifications”) and is provided to assist Industry Members in implementing the reporting requirements laid out in the Technical Specifications. This document illustrates the specific reporting requirements for a variety of order handling execution scenarios for both equities and options Eligible Securities (as defined in the CAT NMS Plan). The scenarios illustrate the reporting requirements for Phases 2a and 2b. Additional scenarios will be added for Phases 2c and 2d when the Technical Specifications are published for those phases.
+The reporting scenarios are presented in a separated document from the Technical Specifications to provide the greatest flexibility in the ability to modify or add scenarios as new questions are presented and trading practices evolves. It is expected that changes and additions will be necessary for reporting scenarios with greater frequency than changes to the Technical Specifications that would be required when record format, field value changes, etc., occur. By maintaining a separate reporting scenarios document, reporting scenarios may be clarified or added without the need for a new version of the Technical Specifications.
+This document contains interpretive guidance for Industry Member CAT Reporters with respect to how the Technical Specifications must be implemented. As such, any changes to this document are subject to the same review and approval process by the Operating Committee, pursuant to the CAT NMS Plan, as the Technical Specifications.
+This document represents a phased approach to industry reporting. Please note that a proposed amendment to the CAT NMS Plan will be filed with the Securities and Exchange Commission ("Commission") to reflect the phased approach for the Industry member CAT reporting described in the Technical Specifications. The proposed amendment will be subject to the approval of the Commission.
+Revision / Change Process
+
+ pubdate: N/A effdate: N/A
+ 1. Introduction
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Introduction
+ Compliance User: Industry Member
Keywords:
- Trading,
- broker-dealers,
- SRO,
- audit trail,
- NMS Plan,
+ Event Reports,
- In today's high-speed electronic markets, trading is widely dispersed across a variety of market centers, including exchanges, alternative trading systems ("ATSs"), such as dark pools and electronic communication networks ("ECNs"), and over-the-counter broker-dealers acting as market makers or block positioners. In their capacity as SROs, the Financial Industry Regulatory Authority ("FINRA") and some of the exchanges currently maintain their own separate audit trail systems for certain segments of this trading activity, which vary in scope, required data elements and format. In performing their market oversight responsibilities, SRO and Commission staffs today must rely heavily on data from these various SRO audit trails.
-As discussed more fully in part II.A below, there are shortcomings in the completeness, accuracy, accessibility, and timeliness of these existing audit trail systems. Some of these shortcomings are a result of the disparate nature of the systems, which make it impractical, for example, to follow orders through their entire lifecycle as they may be routed, aggregated, rerouted, and disaggregated across multiple markets. The lack of key information in the audit trails that would be useful for regulatory oversight, such as the identity of the customers who originate orders, or even the fact that two sets of orders may have been originated by the same customer, is another shortcoming.
-Though SRO and Commission staff also have access to sources of market activity data other than SRO audit trails, these systems each suffer their own drawbacks. For example, data obtained from the electronic blue sheet ("EBS")1 system and equity cleared reports2 comprise only trade executions, and not orders or quotes. In addition, like data from existing audit trails, data from these sources lacks key elements important to regulators, such as the time of execution, and, in the case of equity cleared reports, the identity of the customer. Furthermore, recent experience with implementing incremental improvements to the EBS system has illustrated some of the overall limitations of the current technologies and mechanisms used by the industry to collect, record, and make available market activity data for regulatory purposes.3
-The Commission therefore believes that the regulatory data infrastructure on which the SROs and the Commission currently must rely generally is outdated and inadequate to effectively oversee a complex, dispersed, and highly automated national market system. In performing their oversight responsibilities, regulators today must attempt to cobble together disparate data from a variety of existing information systems lacking in completeness, accuracy, accessibility, and/or timeliness – a model that neither supports the efficient aggregation of data from multiple trading venues nor yields the type of complete and accurate market activity data needed for robust market oversight.
-To address this problem and improve the ability of the SROs and the Commission to oversee the securities markets, on May 26, 2010, the Commission proposed Rule 613,4 with the goal of creating a comprehensive consolidated audit trail5 that allows regulators to efficiently and accurately track all activity in NMS securities throughout the U.S. markets. As proposed – and summarized in part II.B below – Rule 613 required SROs to jointly submit an NMS plan6 that would govern the creation, implementation, and maintenance of a consolidated audit trail, including a central repository to receive and store consolidated audit trail data. In the proposed Rule, the Commission specified many requirements that the NMS plan, and by extension the consolidated audit trail, must meet, ranging from details of the data elements to be collected, to the timing of data transmissions, to specific standards for data formatting.
-Among its various requirements, the proposed Rule mandated that the NMS plan developed by the SROs must in turn require each SRO and its members to capture and report specified trade, quote, and order activity in all NMS securities7 to the central repository in real time, across all markets, from order inception through routing, cancellation, modification, and execution. The proposed Rule also mandated that the NMS plan require the creation of unique order identifiers to facilitate the ability of regulators to view cross-market activity, as well as unique customer identifiers to enhance the ability of regulators to reliably and efficiently identify the beneficial owner of the account originating an order or the person exercising investment discretion for the account originating the order, if different from the beneficial owner.
-The Commission received 64 comment letters from 56 commenters in response to the proposed consolidated audit trail representing a wide range of viewpoints, as summarized in part II.C below.8 The commenters included national securities exchanges, a national securities association, technology providers, academics, broker-dealers, organizations representing industry participants, individual investors, and members of Congress.9 Of the comment letters received, 13 expressed support for the proposal;10 36 expressed support, but suggested modifications to certain provisions of the proposal;11 five solely suggested modifications to the proposal;12 two opposed the proposal;13 and seven neither supported nor opposed the substance of the proposal.14 Concerns raised in these comment letters included: (1) the appropriateness of real-time reporting of required data to the central repository;15 (2) the scope of the required data elements, including the use of unique order identifiers and unique customer identifiers;16 and (3) the burden and costs associated with the proposal.17 In addition, a number of commenters offered alternative approaches and made suggestions regarding the creation, implementation, and maintenance of the consolidated audit trail.18
-In consideration of the views expressed, suggestions for alternatives, and other information provided by those commenting on the proposed Rule, the Commission is adopting Rule 613 with significant modifications to the proposed requirements for the NMS plan submitted to the Commission for its consideration. In certain instances these modifications alter the data and collection requirements of the proposed Rule. In other instances, the adopted Rule has been altered to be less prescriptive, and hence less limiting, in the means SROs may use to meet certain requirements. Some of the more significant changes are as follows:
-• Replacing Real-Time Reporting with a Requirement to Report Data by 8: 00 AM of the Next Trading Day. The adopted Rule no longer requires that the NMS plan provide for the reporting of order event data19 to the central repository in real time; rather, it provides that the NMS plan must require the reporting of order event data to the central repository by 8: 00 a.m. Eastern Time on the trading day following the day such information has been recorded by the SRO or the member.20 The NMS plan may accommodate voluntary submissions of order event data prior to 8: 00 a.m. on the following trading day, but it may not mandate a reporting deadline prior to 8: 00 a.m.
-• Providing More Flexibility to Determine the Format of Data Reported to the Central Repository. The proposed Rule mandated that the NMS plan require the SROs and their members to collect and provide to the central repository the required order and event information in a uniform electronic format. The adopted Rule instead allows the SROs to determine the details of how market participants would transmit data to the central repository (which might include multiple electronic formats, rather than a uniform electronic format), subject to a more general requirement that data must be transmitted in a manner that ultimately allows the central repository to make this data available to regulators in a uniform electronic format.21
-• Eliminating the Requirement to Report Orders with a Unique Order Identifier. The proposed Rule mandated that each order reported to the central repository be tagged with a unique identifier that is the same throughout the order's entire lifecycle. In the adopted Rule, this requirement is replaced with a more general requirement that once all order events are transmitted to the central repository, the repository must be able to efficiently and accurately link together all lifecycle events for the same order, and make available to regulators this linked order data.22
-• Extending the Compliance Period for Small Broker-Dealers. Under the adopted Rule, the NMS plan may provide that small broker-dealers be allowed up to three years, rather than two years as proposed, from the effectiveness of the NMS plan to provide the required data to the consolidated audit trail. 23
-In addition to the above modifications, the Commission has also added a number of new requirements to the adopted Rule in response to general concerns expressed by commenters regarding the process for the development and implementation of the NMS plan. Some of the more significant of these additions are as follows:
-• Considering and Explaining Choices and Available Alternatives. The adopted Rule requires that the NMS plan describe and discuss any reasonable alternative approaches to the creation of the consolidated audit trail that were considered by the SROs and why the approach set forth by the NMS plan was selected.24
-• Planning for Future System Efficiencies. The adopted Rule requires that the NMS plan provide a plan to eliminate existing rules and systems (or components thereof) that are rendered duplicative by the consolidated audit trail, including identification of such rules and systems (or components thereof). Further, to the extent that any existing rules or systems related to monitoring quotes, orders, and executions provide information that is not rendered duplicative by the consolidated audit trail, such plan must also include an analysis of (1) whether the collection of such information remains appropriate, (2) if still appropriate, whether such information should continue to be separately collected or should instead be incorporated into the consolidated audit trail, and (3) if no longer appropriate, how the collection of such information could be efficiently terminated. Finally, such plan must also discuss the steps the plan sponsors propose to take to seek Commission approval for the elimination of such rules and systems (or components thereof); and a timetable for such elimination, including a description of how the plan sponsors propose to phase in the consolidated audit trail and phase out such existing rules and systems (or components thereof).25
-• Considering Input. The adopted Rule requires the NMS plan to address the process by which the plan sponsors solicited views of their members and other appropriate parties regarding the creation, implementation, and maintenance of the consolidated audit trail, provide a summary of the views of such members and other parties, and describe how the plan sponsors took such views into account in preparing the NMS plan.26 In addition, the adopted Rule also requires the NMS plan to provide for the establishment of an Advisory Committee whose function will be to advise the plan sponsors on the implementation, operation, and administration of the central repository.27
-• Periodic Reviews of the Consolidated Audit Trail. To help assure the Commission that as financial markets evolve and new technologies emerge, the consolidated audit trail remains a useful regulatory tool, the adopted Rule mandates that the NMS plan must require the central repository's Chief Compliance Officer to regularly review the operations of the consolidated audit trail, and, in light of market and technological developments, make appropriate recommendations for enhancements to the consolidated audit trail.28
-The Commission has also added certain requirements to the adopted Rule in response to specific concerns expressed by commenters with respect to the use of consolidated audit trail data. Some of the more significant of these additions are as follows:
-• Enhancing Security and Privacy Requirements. Commenters have expressed concerns regarding the risk of failing to maintain appropriate controls over the privacy and security of consolidated audit trail data. Accordingly, the adopted Rule requires the NMS plan to include additional policies and procedures that are designed to ensure the rigorous protection of confidential information collected by the central repository.29
-• Addressing and Limiting Errors. Commenters have also expressed concerns about the potential for errors in the consolidated audit trail; the adopted Rule requires the SROs to provide in their NMS plan detailed information regarding anticipated error rates as well as the plan's proposed error correction process.30
-The Commission generally believes that the collective effect of the modifications and additions described above will be to significantly expand the set of solutions that could be considered by the SROs for creating, implementing, and maintaining a consolidated audit trail and to provide the SROs with increased flexibility in how they choose to meet the requirements of the adopted Rule, relative to the alternatives that would have been available under the requirements of the proposed Rule. The Commission further believes that these changes address or mitigate the principal concerns raised by commenters – including concerns regarding the extent and cost of the systems changes required by the SROs and their members – while continuing to enable the SROs and the Commission to achieve significant benefits from the consolidated audit trail.31 Each of the modifications and additions noted above is described and explained in detail in part III below.
-Given these changes and the wide array of commenters' views on how to best create, implement, and maintain a consolidated audit trail, the Commission expects that the SROs will seriously consider various options as they develop the NMS plan to be submitted to the Commission for its consideration.32 Indeed, some commenters recognized that a consolidated audit trail could be created, implemented, and maintained in a number of ways, and thus recommended that the Commission replace the specific systems requirements of the proposed Rule with more general "end-user" requirements, perform an analysis of how existing audit trail systems do and do not meet the needs of regulators, and perhaps even engage in a formal request-for-proposal ("RFP") process.33
-In light of the expanded solution set that should be available under the changes described above and commenter views on the NMS plan development process, the adopted Rule now requires the SROs to provide much more information and analysis to the Commission as part of their NMS plan submission. These requirements have been incorporated into the adopted Rule as "considerations" that the SROs must address, and generally mandate that the NMS plan discuss: (1) the specific features and details of the NMS plan (e.g., how data will be transmitted to the central repository, when linked data will be available to regulators); (2) the SROs' analysis of NMS plan costs and impact on competition, efficiency, and capital formation; (3) the process followed by the SROs in developing the NMS plan (e.g., the requirement to solicit input from members of the SROs and other appropriate parties); and (4) information about the implementation plan and milestones for the creation of the consolidated audit trail.
-These requirements are intended to ensure that the Commission and the public have sufficiently detailed information to carefully consider all aspects of the NMS plan ultimately submitted by the SROs, facilitating an analysis of how well the NMS plan would allow regulators to effectively and efficiently carry out their responsibilities. To help elicit the most appropriate information and analysis from the SROs in response to these requirements, the Commission is furnishing further details about how it envisions regulators would use, access, and analyze consolidated audit trail data through a number of "use cases." These use cases and accompanying questions should help the SROs prepare an NMS plan that better addresses the requirements of the adopted Rule, as well as aid the Commission and the public in gauging how well the NMS plan will address the need for a consolidated audit trail.34
-Because the Commission believes the adopted Rule permits a wider array of solutions to be considered by the SROs than the proposed Rule did and because the Commission and the public will be able to avail themselves of much more information and analysis in connection with the NMS plan submission, the Commission is also making significant modifications to the process by which it will consider the costs and benefits of the creation, implementation, and maintenance of a consolidated audit trail, as well as the potential impacts on efficiency, competition, and capital formation. In particular, the methodology that the Commission used in the Proposing Release to estimate the costs of creating, implementing, and maintaining a consolidated audit trail may be no longer suitable. As discussed in the Proposing Release, the approximately $4 billion cost estimate for the creation and implementation of a consolidated audit trail was primarily based on averages for the development from scratch of new, very large-scale market systems.35 However, the Commission's rationale for this approach was predicated on some of the specific technical requirements of the proposed Rule, especially those related to the real-time collection and standard formatting of all data. As such, the approach assumed that the consolidated audit trail would not be able to build on existing trade, order, and audit trail systems. As noted above, these assumptions may no longer be valid since several of the specific technical requirements underlying the Proposing Release's approach have been substantially modified. The Commission believes these changes would now permit a wider array of solutions to be considered by the SROs, including solutions that could capitalize on existing systems and standards.36
-In light of these changes, the Commission believes that the economic consequences of the consolidated audit trail now will become apparent only over the course of the multi-step process for developing and approving an NMS plan that will govern the creation, implementation, and maintenance of a consolidated audit trail. In particular, the Commission believes that the costs and benefits of creating a consolidated audit trail, and the consideration of specific costs as related to specific benefits, is more appropriately analyzed once the SROs narrow the expanded array of choices they have under the adopted Rule and develop a detailed NMS plan. The Commission therefore is focusing its economic analysis in this Release on the actions the SROs are required to take upon approval of the adopted Rule – specifically the requirement that the SROs develop an NMS plan, utilizing their own resources and undertaking their own research, that addresses the specific details, cost estimates, considerations, and other requirements of the Rule.37 A robust economic analysis of the next step – the actual creation and implementation of a consolidated audit trail itself – requires information on the plan's detailed features (and their associated cost estimates) that will not be known until the SROs submit their NMS plan to the Commission for its consideration. Accordingly, the Commission is deferring this analysis until such time as it may approve any NMS plan – that is, after the NMS plan, together with its detailed information and analysis, has been submitted by the SROs and there has been an opportunity for public comment.
-To that end, the adopted Rule requires that the SROs: (1) provide an estimate of the costs associated with creating, implementing, and maintaining the consolidated audit trail under the terms of the NMS plan submitted to the Commission for its consideration; (2) discuss the costs, benefits, and rationale for the choices made in developing the NMS plan submitted; and (3) provide their own analysis of the submitted NMS plan's potential impact on competition, efficiency and capital formation. The Commission believes that these estimates and analyses will help inform public comment regarding the NMS plan and will help inform the Commission as it evaluates whether to approve the NMS plan. In this way, the Commission can develop estimates of the costs for the creation, implementation, and maintenance of the consolidated audit trail that benefit from cost data and information provided by the SROs.
-The Commission notes that this approach is suited for the multi-step nature of the particular process for developing and approving an NMS plan that will govern the creation, implementation, and maintenance of a consolidated audit trail. Further, because the Commission is deferring its final analysis of the consolidated audit trail until after a detailed NMS plan has been submitted to the Commission for its consideration and the public has had an opportunity to comment, the adopted Rule has been modified to include a mandate that in determining whether to approve the NMS plan and whether the NMS plan is in the public interest, the Commission must consider the impact of the NMS plan on efficiency, competition, and capital formation of creating, implementing, and maintaining the NMS plan.38 The Commission also will consider the costs and benefits of the creation, implementation, and maintenance of the consolidated audit trail pursuant to the details proposed in the NMS plan submitted to the Commission for its consideration.
-As a result of the new requirements for SROs to provide additional information about costs and a number of other aspects of the NMS plan they submit, the Commission is extending the timeframe for the submission of the NMS plan from 90 days from the date of approval of Rule 613 to 270 days from the date of publication of the adopting release for Rule 613 ("Adopting Release") in the Federal Register. The Commission also is altering the timeframe within which SROs must submit proposed rule changes to require their members to comply with the requirements of the Rule and the NMS plan approved by the Commission39 and the deadline for submitting the document required by Rule 613(i) regarding the possible expansion of the scope of the NMS plan.40
+This document is organized by product, and then within each product, by general handling scenario, such as order receipt and routing, order execution, etc.
+For each scenario, a description of the scenario along with a diagram is provided and then is followed by specific Event Reports illustrating the correct values to be populated for each field.
pubdate: N/A effdate: N/A
- II. Introduction
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Introduction
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Objectives,
- Limitations,
- Reporting,
-
- pubdate: N/A effdate: N/A
- A. Need for, and Objectives of, a Consolidated Audit Trail
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Introduction, Objectives
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2. Equity Scenarios and Examples
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples
+ Compliance User: Industry Member
+ Keywords:
+ This section will illustrate sample equity reporting scenarios. Each scenario will include a brief scenario description including the reportable order events, a flow chart, and step-by-step reporting responsibilities.
+pubdate: N/A effdate: N/A
+ 2.1. Order Origination and Route Scenarios
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios
+ Compliance User: Industry Member
Keywords:
- audit trail,
- Rule 613,
- NMS Plan,
+ Order,
- The Commission believes that the Rule adopted today is an appropriate step in the creation of a consolidated audit trail which, when implemented, should substantially enhance the ability of the SROs and the Commission to oversee today's securities markets and fulfill their responsibilities under the federal securities laws. Rule 613 requires the submission of an NMS plan to create, implement, and maintain the first comprehensive audit trail for the U.S. securities markets, which will allow for the prompt and accurate recording of material information about all orders in NMS securities, including the identity of customers, as these orders are generated and then routed throughout the U.S. markets until execution, cancellation, or modification. This information will be consolidated and made readily available to regulators in a uniform electronic format.
-This section reviews the current status and limitations of existing, discrete audit trails and discusses how a consolidated audit trail could address those limitations and improve the ability of the SROs and the Commission to perform their regulatory functions. To perform this review, the Commission is, in part, drawing upon its own experiences in using existing audit trails to carry out its regulatory duties.41 The Commission also is relying on information provided to the Commission from other regulators who use existing audit trail systems, broker-dealers and organizations representing industry participants, and those with expertise in data management and technology solutions that may be applicable to the adopted requirements.
-pubdate: N/A effdate: N/A
- 1. Use and Limitations of Current Sources of Trading Data
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Introduction, Objectives, Use and Limitations
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2.1.1. New Principal Order Routed to Exchange and Executed
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, New Principal Order Routed to Exchange and Executed
+ Compliance User: Industry Member
Keywords:
- SRO,
- TRade,
- EBS System,
- Equity Cleared Reports,
- SRO Audit Trails,
+ Industry Member Broker 1,
+ Route Scenarios,
- It has become increasingly challenging for SROs and the Commission to oversee the U.S. securities markets across the multitude of trading venues, given the huge volume of orders and trades that are generated, routed, transformed, and then re-routed across dozens of venues every day. Among the challenges is the fact that there is no single, comprehensive audit trail available to regulators.42 At present, the SROs and the Commission must use a variety of data sources, including EBS,43 equity cleared reports,44 and SRO audit trail data to help fulfill their regulatory obligations. As a result, among other issues, regulatory authorities face many challenges in obtaining, reconciling, and making effective use of even the limited order and execution data that is available, thereby hindering the conduct of market surveillance, investigation and enforcement activities, and market reconstructions and analyses.45
-The ultimate effectiveness of core SRO and Commission regulatory efforts depends on the following four qualities of trade and order (collectively "market") data:
-• Accuracy. Is the data about a particular order or trade correct?
-• Completeness. Does the data represent all market activity of interest, or just a subset? Is the data sufficiently detailed to provide the required information?
-• Accessibility. How is the data stored? How practical is it to assemble, aggregate, reconcile, and process the data? Can all appropriate regulators acquire the data they need?
-• Timeliness. When is the data available to regulators? How long will it take to process before it can be used for regulatory analyses?
-SROs generally use market data in the form of audit trails to identify potential misconduct in the markets they oversee, including attempts to manipulate market quotations, inflate trading or order volume artificially, or profit from non-public information. When these surveillance efforts identify suspicious trading activity, SROs have a responsibility to open investigations in which they assemble and review additional market data to assess the nature and scope of the potential misconduct. When an SRO detects persistent problems in the market it oversees, it may write new rules for its members to address the problems. To inform these rulemaking efforts, SROs frequently gather and analyze significant amounts of market data. The effectiveness of such efforts is largely determined by the qualities of the data available.46
-The qualities of such market data are also primary determinants of the Commission's ability to fulfill its statutory mission. The Commission uses market data in most of its investigations of potential securities law violations. In many of these investigations, market data analysis frames the issues for investigation and is a primary means of identifying relationships between individuals and entities whose activities may threaten the integrity of the securities markets or create substantial and unnecessary investor losses. The Commission also uses audit trails and other sources of market data to: (1) inform its priorities for examinations of broker-dealers, investment advisers and SROs; (2) supplement the data and information it collects during those examinations; and (3) determine the nature and scope of any potential misconduct the examinations identify. The Commission also relies heavily on market data to identify patterns of trading and order activity that pose risks to the securities markets and to inform regulatory initiatives, as well as to perform market reconstructions. In addition, the Commission relies on market data to improve its understanding of how markets operate and evolve, including with respect to the development of new trading practices, the reconstruction of atypical or novel market events, and the implications of new markets or market rules. As is the case for the SROs, the effectiveness of such efforts by the Commission is largely determined by the qualities of the data available.47
-As described in the following sections, each of the present sources of market data available to regulators suffers from deficiencies limiting its effective use.
-a. The EBS System
-The EBS system is currently the only available source of data that allows regulators to obtain the identity of customers of broker-dealers who have executed trades. The SROs and the Commission have depended on this system for decades to request trading records from broker-dealers. The EBS system, supplemented by the requirements of Rule 17a-25 under the Exchange Act,48 is generally used by SRO and Commission staff to assist in the investigation of possible securities law violations, typically involving insider trading and market manipulations.49 In its electronic format, the EBS system provides certain detailed execution information, upon request by SRO or Commission staff, for specific securities during specified timeframes. However, EBS data, which is currently sourced from the so-called back-office records of clearing brokers, are limited to executed trades and do not contain information on orders or quotes (and thus no information on routes, modifications, and cancellations). Also, in frequent cases where brokers utilize average-price accounts to execute and aggregate multiple trades for one or more customers, the details of each individual trade execution are typically lost when reported through the EBS system because it is only the average aggregate price and volume of a series of executed trades that are transmitted to the clearing systems for processing.50
-Furthermore, the EBS data currently includes only the dates, but not the times, of each trade execution (regardless of whether or not the trade represents an average-price series of executions).51 Since there could be many broker-dealers trading a given security on a given day of interest, to reconstruct trading on the market for one security on one day could involve many, perhaps hundreds, of EBS requests. Consequently, EBS data, alone, are not generally useful for price or short sale manipulations analysis, order flow analysis, depth-of-book analysis, or any large-scale market reconstructions in which the timing of events is required to build a useful picture of the market.52
-In addition, though the EBS system provides the names associated with each account in which a trade has been placed, these names are based on the separate records of each broker-dealer providing data to the EBS system, and the same party may be identified by a different name across multiple broker-dealers. Experience of staff at the Commission has shown53 that it is difficult to perform cross-broker customer analysis of trading since the same customer may be known by different names depending on the account and broker-dealer through which it traded.
-The EBS system also typically requires SRO and Commission staff needing EBS data to request the information from each broker-dealer, and complete responses from each broker-dealer may take days or weeks depending upon the scope of the request. As a result of these various limitations, the EBS system is generally only used by regulators in narrowly-focused enforcement investigations that generally involve trading in particular securities on particular dates or with specific broker-dealers.
-b. Equity Cleared Reports
-In addition to the EBS system and Rule 17a-25, the SROs and the Commission also rely upon the NSCC54 equity cleared report for initial regulatory inquiries.55 This report is generated on a daily basis by the SROs, is provided to the NSCC, and shows the number of trades and daily volume of all equity securities in which transactions took place, sorted by clearing member. The information provided is end-of-day data and is searchable by security name and CUSIP number.56 This information is also provided to the Commission upon request. Since the information made available on the report is limited to the date, the clearing firm, and the number of transactions cleared by each clearing firm, its use for regulatory purposes is quite limited -- equity cleared reports basically serve as a starting point for certain types of investigations, providing a tool the Commission can use to narrow down the clearing firms to contact concerning transactions in a certain security.
-c. SRO Audit Trails
-In addition to EBS data and equity cleared reports, the SROs and the Commission rely on data collected through individual SRO audit trails. Most SROs maintain their own specific audit trails applicable to their members. For example, the National Association of Securities Dealers ("NASD")57 established its Order Audit Trail System ("OATS")58 in 1996, which required NASD (n/k/a FINRA) members to report certain trade and order data on Nasdaq-listed equity securities. OATS was later expanded to include OTC equity securities. Similarly, the NYSE implemented its Order Tracking System ("OTS")59 in 1999 under which its members were required to report certain trade and order data on NYSE-listed securities. Beginning in 2000, several of the current options exchanges implemented the Consolidated Options Audit Trail System ("COATS").60 In addition, many of the exchanges have created their own audit trails to assist in surveillance activities.
-Recently, FINRA expanded its OATS requirements from covering only Nasdaq-listed and OTC equity securities to covering all NMS stocks.61 To avoid duplicative reporting requirements, the NYSE, NYSE Amex LLC (n/k/a "NYSE MKT LLC") ("NYSE Amex"), and NYSE ARCA, Inc. ("NYSE Arca") subsequently replaced their OTS audit trail requirements for members who are also members of either FINRA or Nasdaq (and therefore subject to OATS requirements) with rules that allow these members to satisfy their reporting obligations by meeting the new OATS requirements.62
-Although these developments with respect to the scope of FINRA's OATS rules reduce the number of audit trails with disparate requirements, they still do not result in a comprehensive audit trail that provides regulators with accurate, complete, accessible, and timely data on the overall markets for which regulators have oversight responsibilities. In particular, data collected by FINRA pursuant to FINRA's Rule 7400 series ("OATS data") does not provide a complete picture of the market because though OATS collects data from FINRA members with respect to orders and trades involving NMS stocks, OATS does not include trade or order activity that occurs on exchanges, or at broker-dealers that are not FINRA or Nasdaq members. Nor does OATS include exchange quotes, principal orders submitted by FINRA members registered as market makers, or options data.63 In performing its own regulatory oversight of the markets, FINRA has chosen to create an internal process in which it augments the data it collects via OATS with trade execution data from other exchanges with which it has a regulatory services agreement. This process provides FINRA with a wider view of the markets than that provided by OATS alone, but linking data in this fashion does not yield fully accurate results.64 For these reasons, the Commission believes that the augmented OATS data currently falls short of providing an efficient source of data for analyzing cross-market activities, or tracking an order through its entire cycle from generation through routing to execution, modification or cancellation.
-OATS data also suffers from a lack of timeliness, partly as a result of the problems with the accuracy of the data as collected, and partly because of its lack of completeness. When FINRA receives an end-of-day OATS file from a member, it takes an hour for FINRA to acknowledge receipt of the report and approximately another 24 hours to determine if there is a syntax error65 in the report.66 During this time, FINRA performs over 152 validation checks on each order event reported to OATS. Thus, FINRA performs over 40 billion separate checks each day to ensure OATS data conforms to all applicable specifications.67 Each of these checks can result in OATS data submissions being rejected and generating an error message.68 As a result of these validation checks, almost 425,000 reports per day, on average, are rejected and must be corrected.69 In addition to the 24 hours needed to identify errors within a report, it takes another two business days to determine whether a file that is syntactically correct nevertheless contains errors in content related to internally-inconsistent information about processing, linking, and routing orders. Once a member is advised of such errors, the member has up to five business days to re-submit a corrected file. However, error corrections are limited to only those that are required to remedy internal inconsistencies within a given member's submission. Cross-firm inconsistencies in which, for example, one member reports routing an order to a second member, but the second member does not report receiving or processing such an order, are identified as unmatched or unlinkable data records, but neither firm corrects these types of reporting errors. The net result yields an historical data record of market activity that contains a small but permanent number of incorrect or irreconcilable trade and order events.70
-Given the time it takes to process each OATS file, and the nature of the process in which errors are detected, reported back to members, and then corrected, inter-firm surveillance by FINRA typically does not begin until 5 business days after receipt of OATS data. In addition, the final product of the FINRA process is available to FINRA, but is not stored in a market-wide database or a central repository that is readily accessible to other regulators. This is because SROs do not typically have access to the internal systems of another SRO, though they may share some sources of underlying data.71
-Because the Commission does not have direct access to OATS data and other SRO audit trails and because each SRO only has direct access to its own audit trails, requests must be made to the Intermarket Surveillance Group ("ISG")72 or SROs to conduct an analysis on order data. It can take days or weeks, depending on the scope of the information requested, to receive responses to requests. Once the responses to its requests for information are received, the Commission, or any SRO undertaking the same task, must commit a significant amount of time and resources to process and cross-link the data from the various formats used by different SROs before it can be analyzed and used for regulatory purposes. Whether or not this process is successful depends on the accuracy, completeness, and format of the data received, as well as how readily data from different SROs can be reliably linked. For example, staff at the Commission working on the analysis of the May 6, 2010 "Flash-Crash" found it was not possible to use the data from existing audit trails to accurately or comprehensively reconstruct exchange and ATS equity limit order books for NMS securities as required to fully analyze the events of that day.73
-A further difficulty in using existing audit trails to conduct cross-market surveillance is the lack of consistency in both format and content among the various audit trails. Not all SROs collect data using the OATS format. In addition, each options exchange maintains its own COATS audit trail in a different format and includes different supplemental data items in its audit trail. These differences make it difficult and labor intensive for regulators to view options trading activity across multiple markets, and the lack of any combined equity and options audit trail is a significant impediment to regulators performing cross-product investigations and analyses.
-An additional shortcoming of existing SRO audit trails is the lack of customer identifiers. In general, existing SRO audit trails only identify the broker-dealer handling the order and not the account holder or the person exercising investment discretion for the account holder, if different. This limitation makes the process of identifying the customers involved in unusual trading patterns or market events very difficult. Even determining whether or not an unusual trading pattern exists is challenging if the data does not identify trades by a single customer at multiple broker-dealers. Requests therefore must be made to one or more broker-dealers to obtain information about the customer or customers behind an order. Multiple requests may be necessary before the information is obtained. EBS data may have to be requested as a supplement. A further challenge arises in any type of customer-based cross-market analysis because there is no standard convention for how customers are identified at different broker-dealers – the same party directing trades across multiple venues, or through different broker-dealers, can be known by many different names.
-Not having customer information at the early stage of surveillance can also impair the accuracy, and thus efficacy, of certain surveillances. The patterns that emerge when trade and order activity is aggregated across all customers of a broker-dealer often exhibit characteristics that can be quite different from the (initially) unobservable patterns of trade and order activity of each individual customer at that broker-dealer. This could result in what are known as "false positive signals," in which market activities that initially are flagged as being potentially manipulative by a surveillance system are later found not to be potentially manipulative once more detailed customer data from the broker-dealer is requested and analyzed. In contrast, potentially manipulative activities may be missed by a surveillance system that cannot identify the customers behind each order or trade if those activities are otherwise obscured by non-manipulative activities of other customers of the same broker-dealer such that the aggregate patterns of trading do not appear potentially manipulative.
-Given the various limitations described above, the Commission does not believe that existing audit trails, with their current features, provide regulators with an efficient or adequate method of monitoring and surveilling the market for NMS securities. The Commission notes, for example, that FINRA summarizes the current cross-market systems as follows: "The current systems in place to achieve effective cross-market surveillance, such as the ISG, are incomplete. For example, the ISG audit trail data has numerous shortcomings, including: (1) it does not capture quote/orders away from a market's inside market (i.e., those quotes/orders below the best bid or above the best offer); (2) it currently identifies participants of a trade only to the clearing broker, not down to the executing broker level; (3) data submitted by participants is not validated; (4) certain data fields are not mandatory; and (5) there are no service level agreements to ensure that participants submit timely and accurate information."74
+This scenario illustrates the reporting requirements to CAT for an Industry Member that creates a new principal order, routes it to an exchange, and then the order is executed on the exchange.
+For this scenario, Industry Member Broker 1 is required to report the following events:
+• The creation of a New Order (Principal)
+• The route to an exchange as an Order Route event
+Note that the execution will be reported by the exchange, Broker 1 does not need to report the fill received.
+
+ 
+ 
pubdate: N/A effdate: N/A
- 2. Regulatory Improvements with a Consolidated Audit Trail
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Introduction, Objectives, Regulatory Improvements with CAT
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2.1.2. Customer Order Routed to Exchange as Agent
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Customer Order Routed to Exchange as Agent
+ Compliance User: Industry Member
Keywords:
- NMS Plan,
- Quality of Audit Trail,
- Surveillance,
- Investigation,
- Customer-ID,
- Risk-Based Examination,
- Market Manipulation,
- Tips,
- Complaints,
- Cross-Market,
- Broad-Based Market Events,
- Market Analysis,
- Reporting Requirements,
+ Average Price Bases,
- The NMS plan required by the Rule, if approved by the Commission, will improve the quality of audit trail data by, among other things: (1) identifying with a unique "Customer-ID" the account holder(s) with respect to an account at a registered broker-dealer and, if different, any person authorized to give the broker-dealer trading instructions for such account; (2) identifying the time of each key event in the life of an order according to synchronized business clocks; (3) requiring the reporting of comprehensive order lifecycle data; and (4) including all NMS securities in one audit trail. As discussed below, the Commission believes that these improvements should have the potential to result in the following: (1) improved market surveillance and investigations; (2) improved analysis and reconstruction of broad-based market events; and (3) improved market analysis. In addition, a consolidated audit trail has the potential to result in a reduction in disparate reporting requirements and data requests.
-a. Improved Market Surveillance and Investigations
-A consolidated audit trail will expand the data available for regulators to perform surveillance and investigations for illegal activities such as insider trading, wash sales, or manipulative practices. In particular, a consolidated audit trail will help surveillance and investigations by facilitating risk-based examinations, allowing more accurate and faster surveillance for manipulation, improving the process for evaluating tips, complaints, and referrals ("TCRs"), and promoting innovation in cross-market and principal order surveillance.
-i. Risk-Based Examinations
-A consolidated audit trail will facilitate risk-based examinations. Risk-based examinations require access to accurate and timely data so that the scope of the examination can be properly set to cover the areas of identified risks. Regulators currently may request audit trail data directly from the broker-dealer, work with the broker-dealer to understand the format and definitions in the data, validate that information with a third party, and analyze the data to determine whether the initial assumptions concerning risk were valid. This effort requires significant resources from both the regulator and the broker-dealer, all of which may be wasted if the resulting analysis shows that the assumptions of risk justifying the examination of a particular subject were not founded. Thus, this resource-intensive process does not necessarily reveal the subjects most worthy of examination, and does not permit an effective pre-examination review of a subject's trading practices.
-In contrast, a consolidated audit trail would permit regulators, for example, to identify risks and appropriate subjects for examinations relating to certain types of trading by creating and comparing metrics based on the complete (and possibly cross-market) activities of a broker-dealer or customer. Signals based on such metrics could, for example, identify outlier patterns in the ratio of order activity to execution, which may be an indication of potentially manipulative practices. Currently, this method is impractical because, as described above, it requires the consolidation of many audit trails that store data in non-uniform formats, participant information in SRO audit trails often does not consistently identify the executing broker-dealer, and there is no uniform method of identifying customers.
-In sum, consolidated audit trail data that meets the minimum requirements for the NMS plan specified in the Rule would allow regulators to create a process that focuses much more of their resources on those firms for which specific activities over specific time periods warrant follow up. The subsequent examinations would thus be more precise, resulting in more efficient use of regulatory resources, potentially reducing the need for multiple document requests, and ultimately reducing the sometimes significant compliance burden on a broker-dealer or other subject.
-ii. Market Manipulation
-In addition to helping regulators focus their resources and better identify areas in which potentially manipulative trading activity may be occurring, a consolidated audit trail will greatly aid the analysis of the potential manipulation itself. The current methodology to analyze order and trade data requires a tremendous amount of time and resources to construct an accurate picture of when trades are actually executed. Typically, this includes: (1) broker-dealers and other registrants responding to multiple requests from the Commission and SROs; (2) SROs devoting regulatory resources to obtaining, analyzing, and reporting data requested by the Commission; and (3) Commission staff reconciling inconsistent order data provided by different SROs with respect to different markets.
-In addition, while SRO audit trail data identifies the dates and times of trades by a particular broker-dealer, SRO audit trail data does not reveal the identities of the customers initiating the trades executed by the broker-dealers. Accordingly, to identify customers placing trades through a broker-dealer, regulatory staff must obtain EBS data and integrate such data with SRO audit trail data. This is a cumbersome process because there is no automated process to link the two data sources. To determine the exact execution time for trades by a particular customer, regulatory staff must obtain a third set of data from the broker-dealer's trading and order handling system. These processes can take many months. In some cases, the laborious process of assembling the data delays other critical investigative or analytical steps. In other cases, investigators or analysts forego the process of determining when trades occurred, limiting their analysis to more accessible information. As a result, SRO and Commission staffs may fail to ascertain the full scope of misconduct under investigation or the causes of unusual market events at issue.
-Even more critically, the absence of reliable information about who initiated which orders makes detection of schemes that involve repeat instances of activity through accounts at multiple broker-dealers difficult. Schemes of this sort may be among the most harmful and difficult to police, but without a customer identifier that consistently and uniquely identifies responsibility for orders across all broker-dealers, no amount of technical sophistication and securities market insight can produce a data query or analysis to detect them.75
-With the data provided by the consolidated audit trail, regulatory staff would be able to conduct such analyses in a much shorter period of time. In addition, the process of analysis with a consolidated audit trail would be inherently more reliable than the manual reconstruction process currently available, reducing the risk of inaccuracies. Furthermore, the ability to process and meaningfully analyze audit trail data more quickly would allow regulatory staff to employ proactive methods of identifying potentially manipulative activities. The Commission therefore believes a consolidated audit trail would make the overall process of identifying and analyzing potentially manipulative trading practices much more focused, accurate, and efficient.76
-The timely availability of data to regulators also impacts the efficacy of detecting (and possibly mitigating the effects of) some types of market manipulation. For example, some pernicious trading schemes are designed to generate large "quick-hit" profits in which participants attempt to transfer the proceeds from the activity to accounts outside of the reach of domestic law enforcement as soon as the offending transactions have settled in the brokerage account (typically three days after execution). If the SROs detect such schemes and promptly report them to the Commission, the Commission potentially could seek asset freezes that limit the transfer of funds until charges against the account holder are resolved. The Commission believes that a consolidated audit trail in which uniform data about market activities are efficiently collected and processed soon after such activities occur, and in which data are available to regulators in a timely manner, would more frequently and effectively allow regulators to use this approach.
-iii. Tips and Complaints
-A consolidated audit trail also would significantly improve the processes used by the SROs and the Commission for evaluating tips and complaints about trading activity.77 It is not uncommon for market participants or those with experience in market data to sometimes note atypical trading or quoting patterns in publicly-available market data. A consolidated audit trail would allow regulatory staff to quickly determine whether a particular instance of an atypical activity (regardless of how it was originally identified), such as an abnormally high level of quote traffic, is worthy of further investigation.
-Today, such an analysis of TCRs is difficult and cumbersome. Even a preliminary review requires analysis by each exchange or ATS to identify the activity in question and to determine its scope. Regulators then must consolidate the analyses from each such market center to determine the identities of those responsible for the atypical activity in question. To the extent that the activity originates from several market participants, regulators must conduct additional analysis on each of those participants, and possibly other participants, to discover information that could identify the customer(s) originating the orders that created the atypical activity. Without a unique customer identifier included in the order and trade data, this may not be possible. The consolidated audit trail would significantly improve the multi-stage process, enabling regulatory staff to make efficient queries on orders and more quickly determine whether the TCR can be "closed" or if further analysis and investigation are warranted.
-iv. Cross-Market and Principal Order Surveillance
-Investigations of cross-market activity may be more efficient with a consolidated audit trail as such an audit trail may provide regulators with data not currently consolidated across markets and/or data not currently available to regulators such as broker-dealer principal orders, including market maker quotes. For example, in an attempt to manipulate the market, a broker-dealer could use numerous principal sell orders across multiple venues to give the misleading appearance of broad sell-side pressure, and then send a buy principal order at a favorable price to take advantage of the market momentum created by the misleading sell orders. This type of activity would be difficult to readily identify with current audit trails, but it could be the target of a routine surveillance of a consolidated audit trail. The Commission notes, for example, the statement of FINRA and NYSE Euronext that, "[p]articularly since the implementation of Regulation NMS in 2007, there has been a significant increase in market linkages, the result of which is that trading activity on one market can have a profound effect on other markets. This, in turn, has led to the realization that market manipulation, by its very nature, is facilitated cross-market where, for example, trading on one market is used to affect a security's price while trading on another market is used to take advantage of that price change."78
-In addition, the consolidation of order data with direct access for all relevant regulators may create opportunities for regulators to develop entirely new methods of surveillance, and to keep existing forms of surveillance up to date as new market practices and new market technologies continue to rapidly evolve. In fact, as described more fully below, SROs are required by the Rule to incorporate the expanded audit trail data into their surveillance systems.79
-b. Improved Analysis and Reconstruction of Broad-Based Market Events
-A consolidated audit trail will significantly improve the ability of regulators to reconstruct broad-based market events so that they and the public may be informed by an accurate and timely accounting of what happened, and possibly why. The sooner a reconstruction can be completed, the sooner regulators can begin reviewing an event to determine what, if any, regulatory responses might be required to address the event in an effective manner.
-For example, on the afternoon of May 6, 2010, the U.S. equity and equity futures markets experienced a sudden breakdown of orderly trading, when broad-based indices, such as the Dow Jones Industrial Average Index and the S&P 500 Index, fell about 5% in just five minutes, only to rebound soon after (the "Flash Crash"). Many individual equities suffered even worse declines, with prices in over 300 stocks and exchange-traded funds falling more than 60%. In many of these cases, trades were executed at a penny or less in stocks that were trading at prices of $30 or more only moments earlier before prices recovered to their pre-Flash Crash levels.80
-The Commission immediately formed an interdisciplinary team from across the Commission to analyze the events of May 6, 2010, identify possible causes, inform the public of what happened, and aid in formation of regulatory responses. The CFTC took similar steps. Within a few weeks, staff at the Commission and the CFTC released a joint preliminary report that described the event and, in general terms, the market conditions prior to and during the rapid decline.81 However, at that time the staffs were unable to definitively identify the specific conditions or circumstances that could have caused, contributed to, or exacerbated the event. Though the SROs and the Commission quickly implemented a single-stock circuit breaker pilot program as an initial response, a more complete regulatory response required a full and robust analysis of additional data.
-From the start of the investigation, many market participants had suggested that the sudden withdrawal of liquidity in the equity markets may have resulted in the rapid decline of prices as orders to immediately sell (many from retail investors) found no interest on the buy side (from market professionals).82 To fully understand how such conditions could occur, Commission economists needed to analyze the order books for thousands of equities. Commission staff requested order book data from several exchanges that sell such data or could readily put such data together, but this data did not represent the whole market. Commission staff attempted to use order data from OATS and several SRO audit trails to reconstruct order books for thousands of equities traded on exchanges that do not maintain or could not provide order book data. Although it was possible to link the data from different sources to show trading activity for a particular stock over a specific period of time, the accuracy, completeness, and content of the combined data sets were not sufficient to allow for an accurate reconstruction of the order books. This hindered staff in determining what happened to liquidity before, during, and after the Flash Crash. Two major problems were the inability to identify and eliminate duplicate orders from the data and the inability to accurately sequence events across the multiple data sources.
-As described in the final joint report issued by the staffs of the CFTC and the Commission on September 30, 2010, Commission staff were only able to create a comprehensive view of the order books by acquiring, processing, and aggregating four distinct data sets that each contained a subset of order book information from each of the four exchanges that could provide such information: Nasdaq ModelView, NYSE Openbook Ultra, NYSE ARCABook, and BATS Exchange.83 Given the enormous volume of data that needed to be processed (more than 5.3 billion records), even small changes to the integration and aggregation process took significant computer time to test and implement.
-By early July 2010, staff at the CFTC had completed a very detailed analysis of the full order book of the S&P 500 E-Mini futures contract and were able to show how liquidity in that contract had been eroding for most of the day. The CFTC's detailed second-by-second analysis of trading during the Flash Crash itself revealed how buy-side depth in the S&P 500 E-Mini futures virtually evaporated as broad market indices rapidly fell 5%.84 However, until a similar analysis could be completed in the equity markets, neither regulators nor the public would know whether an evaporation of liquidity was also present in the equity markets, and whether the timing of such an event preceded or followed the liquidity event in the futures market. Ultimately, it took Commission staff nearly five months to complete an accurate representation of the order books of the equity markets for May 6, 2010. Even then, the reconstruction was not fully complete and only contained an estimated 90% of trade and order activity for that day.85 However, it was sufficiently comprehensive to allow staff to perform a robust analysis of the equity markets revealing how "the decline in full-depth buy-side liquidity for the E-Mini precede[d] that of the SPY and [the stocks composing] the S&P 500," and how "drops in [stock] prices [became] increasingly more severe with ever-larger drops in liquidity."86
-Had there been a consolidated audit trail in place on May 6, 2010, regulators would likely have been able to much more quickly and efficiently perform these types of detailed analyses. This in turn could have dramatically shortened the time during which regulators, as well as the public, remained uncertain about what actually happened during the Flash Crash.
-c. Improved Market Analysis
-In addition to the surveillance and reconstruction benefits described above, a consolidated audit trail would also significantly improve the ability of regulators to monitor overall market structure, so that both the Commission and the SROs can be better informed in their rulemakings. In January 2010 the Commission published a concept release on equity market structure that discusses how the markets have rapidly evolved from trading by floor-based specialists to trading by high-speed computers. The concept release poses a number of questions about the role and impact of high-frequency trading strategies and the movement of trading volume from the public national securities exchanges to dark pools.87
-Over the past two years there has been considerable discussion about these topics by regulators, market participants, the media, and the general public. Nevertheless, numerous open questions remain because of a lack of consolidated market data, making certain types of market-wide analysis impractical. For example, existing research on high frequency trading cannot precisely identify high frequency traders. As a result, studies of high frequency trading have been limited in their ability to thoroughly examine such strategies and their impact on the market, leaving many open questions. Having more precise data on who is trading (and from which general patterns of order submission could be inferred) would help regulators better understand the impact of high frequency trading on markets. Similar analyses also could be performed for other aspects of general market structure, such as those discussed in the concept release related to dark pools and internalization. In addition, having access to a consolidated audit trail will provide the Commission and SROs with better data to conduct retrospective analyses of rules and pilots. Informed analysis of these topics requires consolidating audit trails so that quotes and trades across multiple exchanges can be linked (either by customer type or by specific customer) with order flow and trades from the many dozens of over-the-counter venues.
-d. Potential Reduction in Disparate Reporting Requirements and Data Requests
-The Commission believes that a consolidated audit trail will reduce the burdens on SROs and broker-dealers associated with producing regulatory data. In particular, the consolidated audit trail may reduce burdens from ad hoc data requests.
-The Commission believes that the creation of a consolidated audit trail may reduce the number and types of ad hoc requests made by regulators to market participants for data concerning their trading activities. In particular, regulators could use direct access to data in the consolidated audit trail for investigations or analyzing trends or broad market activities instead of requesting data from market participants. In addition, regulators could use this direct access to analyze the activities of a single trader across multiple markets, which today requires requests for data from multiple market participants. Regulators would therefore likely make fewer ad hoc requests. The Commission, however, does not believe that all ad hoc requests for data from market participants will be replaced by obtaining data from the consolidated audit trail. A detailed investigation of a particular firm may require types of data from that firm that are not stored in the consolidated audit trail, or that relate to periods prior to the implementation of the consolidated audit trail. In addition, in cases in which there are discrepancies, or even suspected discrepancies, between a firm's actual trading activities and what is stored in the consolidated audit trail's central repository, regulators are likely to request data directly from market participants for verification and investigative purposes.
+This scenario illustrates the reporting requirements to CAT for an Industry Member that routes a customer order to an exchange on an agency basis.
+For this scenario, Industry Member Broker 1 is required to report the following events:
+• New Order event for the customer order
+• Order Route event for routing the customer order to the exchange
+In this scenario, since the execution is passed back directly to the customer, no Order Fulfillment event is required to be reported.
+
+ 
+ 
pubdate: N/A effdate: N/A
- 3. Large Trader Reporting System Rule
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Introduction, Objectives, Large Trader Reporting System Rule
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2.1.3. Customer Order Fulfilled on Average Price Basis
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Customer Order Fulfilled on Average Price Basis
+ Compliance User: Industry Member
Keywords:
- Rule 3h-1,
- NMS Plan,
+ Two Industry Members,
- The Commission believes that a consolidated audit trail will be able to build upon various aspects of the large trader reporting system that was recently adopted by the Commission.88 Rule 13h-1, which establishes the large trader reporting system, requires large traders to identify themselves to the Commission and make certain disclosures to the Commission on Form 13H. Upon receipt of Form 13H, the Commission issues a unique identification number to the large trader, which the large trader then will be required to provide to those broker-dealers through which the large trader trades. Registered broker-dealers will be required to maintain specified transaction records for each large trader and to report that information to the Commission upon request. The Large Trader Rule requirements are designed to enable the Commission to promptly and efficiently identify significant market participants and collect data on their trading activity so that Commission staff can reconstruct market events, conduct investigations and bring enforcement actions as appropriate.
-Several commenters noted that portions of the requirements of Rule 13h-1 overlapped with certain provisions of proposed Rule 613 and requested that the Commission harmonize the rules.89 One commenter stated that the Commission should consider implementing only those portions of Rule 13h-1 that would not be affected by, or be redundant to, the implementation of the consolidated audit trail proposal.90 Another commenter suggested that the Commission mandate compliance only with those aspects of Rule 13h-1 that would operate as part of the consolidated audit trail – the large trader identifier in particular – so they could be leveraged in the creation of the consolidated audit trail.91 Yet another commenter believed that, upon implementation of the consolidated audit trail, it would not be necessary for large traders to identify themselves to their broker-dealers pursuant to Rule 13h-1, because the consolidated audit trail already would require broker-dealers to include a customer identifier for every order.92 The commenter explained that, if customer information is collected as part of the consolidated audit trail, the Commission and SROs could run queries to identify customers with significant trading volume.93
-The Commission believes that both Rules are necessary to enhance regulatory oversight of the markets and its members. Key aspects of Rule 13h-1 define the types of entities that are large traders, and who must register with the Commission and file and keep current certain background information on Form 13H. These aspects of Rule 13h-1 are not addressed by Rule 613 and would not be superseded by it. Rather, the information collected by the registration of large traders would further complement the data collected for a consolidated audit trail. To this end, Rule 613 requires that large trader identifiers also be reported to the central repository as part of any large trader's customer account information94
-The Commission does note, however, that other aspects of Rule 13h-1 may be superseded by Rule 613. Specifically, the trade reporting requirements of Rule 13h-1 are built upon the existing EBS system. To the extent that, as described in Section II.A.2.iv.d., data reported to the central repository under Rule 613 obviates the need for the EBS system, the Commission expects that the separate reporting requirements of Rule 13h-1 related to the EBS system would be eliminated.95
+This scenario illustrates the reporting requirements to CAT for an Industry Member that works a customer order through an average price account by routing one or more representative orders to the exchange. The Industry Member then fills the customer order on an average price basis.
+For this scenario, Industry Member Broker 1 is required to report the following events:
+• New Order event for the customer order
+• New Order event for the representative order created from the average price account
+• Order Route event for each representative order, or portion of the representative order, routed to the exchange
+• Order Fulfillment event to report the average price given to the customer
+
+ 
+ 
+ 
pubdate: N/A effdate: N/A
- B. Summary of Proposed Rule 613
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Introduction, Summary of Proposed Rule 613
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- NMS Plan,
- FINRA,
- Rule 613,
- Data Collection,
- SRO,
-
- Proposed Rule 613 would have required that the SROs propose an NMS plan that included provisions regarding: (1) the operation and administration of the NMS plan; (2) the creation, operation and oversight of a central repository; (3) the data required to be provided by SROs and their members96 to the central repository; (4) clock synchronization; (5) compliance by national securities exchanges, FINRA, and their members with Rule 613 and the NMS plan; and (6) a plan for the possible expansion of the NMS plan to products other than NMS securities. Specifically, proposed Rule 613 would have required the SROs to jointly file an NMS plan with the Commission to govern the creation, implementation, and maintenance of a consolidated audit trail and a central repository.97 The NMS plan would have been required to provide for an accurate, time-sequenced record of an order's life, from receipt or origination, through cancellation or execution. In particular, the proposed Rule would have required the NMS plan to require that the SROs and their respective members collect and provide to the central repository data for each "reportable event," defined to include the receipt, origination, modification, cancellation, routing, and execution (in whole or in part) of an order, with respect to any NMS security. This data would have been required to be collected and provided to the central repository in a uniform electronic format on a real-time basis.
-Under the proposed Rule, the data collected upon the receipt or origination of an order would have included: a unique order identifier; a unique customer identifier;98 a unique identifier for the broker-dealer receiving or originating the order; the date and time of receipt or origination of the order; and the "material terms of the order."99 For orders that are modified or cancelled, the data collected in real time would have included: the date and time the modification or cancellation was received or originated; the price and remaining size of the order; changes in the material terms of the order (if the order is modified); and the identity of the person giving the modification or cancellation.
-For orders that are routed, data collected in real time would have included: the unique order identifier, the date and time the order was routed; the unique identifier of the broker-dealer or national securities exchange routing the order; the unique identifier of the broker-dealer or national securities exchange receiving the order; if routed internally at a broker-dealer, the identity and nature of the department and desk to which the order was routed; and the material terms of the order.
-For orders received that were routed, data collected in real time would have included all the information for orders that are routed, except the identity and nature of the department and desk to which the order was routed, if routed internally at a broker-dealer; however, the date and time the order was routed would be replaced by the date and time the order was received.
-For the execution of an order, data collected in real time would have included: the unique order identifier; the date and time of execution; the execution size and price; the unique identifier of the SRO or broker-dealer executing the order; the capacity of the broker-dealer executing the order (i.e., principal, agency, riskless principal); and whether the execution was reported pursuant to an effective transaction reporting plan or the OPRA Plan.100
-Because certain information may not be readily available at the time of the reportable event, the proposed Rule would have required the NMS plan to require each SRO and its members to collect and provide to the central repository certain information, in a uniform electronic format, promptly after receipt of such information, but in no instance later than midnight of the day that the reportable event occurred or when the SRO or its member receives such information. Under the proposed Rule, this data would have included: the account number for any subaccounts to which the execution is allocated (in whole or part); the unique identifier of the clearing broker or prime broker, if applicable; the unique order identifier of any contra-side order; special settlement terms, if applicable; short sale borrow information and identifier; the amount of a commission, if any, paid by the customer, and the unique identifier of the broker-dealer(s) to whom the commission is paid; and, if the execution is cancelled, a cancelled trade indicator.
-The proposed Rule would have required that the SROs jointly file an NMS plan with the Commission within 90 days after approval of the Rule. In addition, the SROs would have been required to select a plan processor within two months of the effectiveness of the NMS plan, as well as provide the Commission a document outlining how the SROs would propose to expand the audit trail to include non-NMS securities and additional transactions. The proposed Rule also would have required the SROs to file proposed rule changes to require their members to comply with the requirements of the proposed Rule and the NMS plan within 120 days of the effectiveness of the NMS plan. The SROs would have been required to begin reporting data to the central repository within one year after the effectiveness of the NMS plan, and their members would have been required to begin reporting data to the central repository within two years after the effectiveness of the NMS plan.
-As proposed, the NMS plan would have been required to include specific plan provisions, detailing: the plan governance structure, the processes of admission and withdrawal of plan sponsors, the percentage of votes required to effectuate amendments to the plan, the allocation of central repository costs among the plan sponsors, and the appointment of a Chief Compliance Officer ("CCO") of the central repository. The proposed Rule would have required all plan sponsors to develop and implement a surveillance system, or enhance existing surveillance systems, reasonably designed to make use of the information contained in the consolidated audit trail. This information would be available to the Commission and the SROs for regulatory and oversight purposes only. The proposed Rule also would have required the NMS plan to require information be collected in a convenient and usable standard electronic data format, directly available and searchable electronically without any manual intervention for a period of not less than five years. This information would have been required to be available immediately, or, if immediate availability was not reasonably and practically achieved, any search query would have to begin operating on the data not later than one hour after the search query was made. Additionally, the proposed Rule would have required the NMS plan to include policies and procedures, including standards, to be utilized by the plan processor to ensure the security and confidentiality of all information submitted to the central repository, and all SROs and their employees, as well as all employees of the central repository, would have been required to agree to use appropriate safeguards to ensure the confidentiality of such data. The proposed Rule also would have required SROs and their members to synchronize their business clocks that are used for the purposes of recording the date and time of any event that must be reported under the proposed Rule consistent with industry standards. Further, the proposed Rule would have required the central repository to collect and retain, on a current and continuing basis, and in a format compatible with the other information collected pursuant to the proposed Rule, the national best bid and national best offer ("NBBO") information for each NMS security. Transaction reports reported pursuant to an effective transaction reporting plan filed with the Commission pursuant to, and meeting the requirements of, Rule 601 of Regulation NMS under the Exchange Act,101 and last sale reports reported pursuant to the OPRA Plan filed with the Commission pursuant to, and meeting the requirements of, Rule 608 of Regulation NMS under the Exchange Act also would have been required to be collected and retained.
-pubdate: N/A effdate: N/A
- C. Summary of General Comments on the Proposed Rule
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Introduction, Summary of General Comments on the Proposed Rule
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Comments,
-
- The Commission requested comments on all aspects of the proposed Rule, including the potential costs and benefits.102 In particular, the Commission encouraged commenters to identify, discuss, analyze, and supply relevant data regarding any such costs or benefits.103 In response, commenters provided views and opinions regarding the regulatory usefulness of a consolidated audit trail; the overall costs of the proposed Rule, focusing on those requirements that commenters believed would be the most costly or burdensome to implement;104 the process for creating and implementing a consolidated audit trail; and alternatives to the proposed Rule's approach to creating, implementing, and maintaining a consolidated audit trail. These comments are discussed below.
-pubdate: N/A effdate: N/A
- 1. Industry Support for a Consolidated Audit Trail
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Introduction, Summary of General Comments on the Proposed Rule, Industry Support for a CAT
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2.1.4. Order Routed between Two Industry Members and Subsequently Executed
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Order Routed between Two Industry Members and Subsequently Executed
+ Compliance User: Industry Member
Keywords:
- Opinions,
- FINRA,
- NYSE,
- NASDAQ,
- Commenters,
- SIFMA,
+ Multiple Industry Members,
- Commenters provided a wide range of opinions, and shared their concerns, regarding specific aspects of the proposed Rule.105 However, many of the commenters and their representatives who are involved with regulating and operating securities markets – as well as many of the commenters who otherwise populate data for, or make use of, existing audit trail systems (such as broker-dealers) – expressed support for the creation of a single consolidated audit trail.
-FINRA and NYSE Euronext, filed a joint letter, "vigorously support[ing] the establishment of a consolidated audit trail," and stating, among other things, that "the evolution of the U.S. equity markets and the technological advancements that have recently taken place have created an environment where a consolidated audit trail is now essential to ensuring the proper surveillance of the securities markets and maintaining the confidence of investors in those markets."106
-The NASDAQ OMX Group, Inc. similarly states that "[m]arket developments and fragmentation of market centers with varying market structures and levels of transparency have created inefficiencies and potential gaps in cross-market regulation," and that "[c]omplete transparency is the only way to ensure fair and orderly markets."107
-Other commenters also stated their general support for the creation of a consolidated audit trail. According to Direct Edge Holdings, LLC ("Direct Edge"), "[t]he proposed consolidated audit trail ('CAT') system would significantly enhance the capabilities of regulators to police trading across asset classes; replace existing audit trails and consolidate trading and execution data for the asset classes under the Commission's jurisdiction . . . enable regulators to create a more complete timeline of an order's lifecycle; and facilitate large-scale market reconstructions . . . ."108
-Although CBOE expressed some concerns in its comment letter about the "breadth, expense, and timetable of the Proposal"109 (concerns that were shared by other commenters),110 it "recognizes there are potential benefits to be obtained from CAT, and agrees that a central repository with uniform data submitted by all markets could enhance SRO and SEC oversight of the markets."111 CBOE further stated that, "[i]n particular, a CAT that contains a customer identifier on an order by order basis would enhance significantly the audit trails of the markets."112
-BATS Exchange, Inc. ("BATS") expressed general support for the Commission's proposal, stating, "[o]ver the last several years, liquidity has dispersed across multiple interconnected venues, such that no one market center can claim a majority share of equity securities transactions. However, regulatory tools have not evolved to keep pace with these changes, and the limited existing processes and data available to analyze inter-market trading are inadequate. As a consequence, regulators rely on inefficient processes to reconstruct intermarket trading activity, including ad hoc requests to members for trading data when a potential problem is identified."113
-Liquidnet, Inc. ("Liquidnet"), an ATS, generally stated that, "[i]n the long run, a properly-designed system that provides for centralized reporting of data should be more cost-efficient than the current patchwork system for collecting audit trail data."114 Liquidnet outlined seven specific benefits of a consolidated audit trail, ranging from "[reducing] the time that regulatory personnel must expend to request and collect data from market participants on a case-by-case basis," to "[reducing] the cost of reconstructing, analyzing, and reporting on significant market events such as those that occurred on May 6, 2010." 115
-The Securities Industry and Financial Markets Association ("SIFMA"), an industry group that represents, among other entities, hundreds of securities firms that could be impacted by the creation of a consolidated audit trail, "believes that a centralized and comprehensive audit trail would enable the SEC and securities self-regulatory organizations ('SROs') to perform their monitoring, enforcement, and regulatory activities more effectively."116 SIFMA further states that, "[i]n the current era of electronic trading, regulators need efficient access to order and execution data from both broker-dealers and exchanges. Indeed, a consolidated audit trail is a much-needed improvement over today's fragmented audit trail platforms."117 As did a number of other commenters,118 SIFMA also expressed concerns about, and suggested alternatives to, some specific aspects of the proposed Rule, which will be further discussed below.
-Finally, the Commission notes that members of the Financial Information Forum, whose participants include "trading and back office service bureaus, broker-dealers, market data vendors and exchanges," agree that "an enhanced audit trail system could increase the effectiveness of cross-market surveillance through better data availability and integration."119
-When the perspectives of these commenters are combined with the Commission's own experiences (as described above in Section II.A.1.c.), a common theme emerges: there is substantial room for improvement in the collection of and access to trading data beyond what is available today from existing audit trails and other sources. The Commission agrees with many of the commenters that one of the main benefits of a consolidated audit trail will be to improve the efficiency and adequacy of a regulatory process of collecting and accessing audit trail data that directly affects and impacts a significant number, and wide variety, of market participants.
+This scenario illustrates the reporting requirement when an order is routed from one Industry Member to another.
+
+ For this scenario, Industry Member Broker 1 is required to report the following events:
+• New Order event for the customer order
+• Order Route event for routing the customer order to Broker 2
+For this scenario, Industry Member Broker 2 is required to report the following events:
+• Order Accepted event for the received client order from Broker 1
+• Order Route event for routing the client order to the exchange
+
+ 
+ 
+ 
pubdate: N/A effdate: N/A
- 2. Commenters' Views on the Overall Costs of the Proposed Rule and the Resulting Framework of the Adopted Rule
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Introduction, Summary of General Comments on the Proposed Rule, Industry Support for a CAT
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2.1.5. Order Split and Routed to Multiple Industry Members, Exchange, and Filled
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Order Split and Routed to Multiple Industry Members, Exchange, and Filled
+ Compliance User: Industry Member
Keywords:
- Cost,
- Comments,
+ Routing Broker,
- With respect to general costs for the proposal, commenters expressed differing views. As discussed below, some commenters thought that the Commission overestimated the burdens of creating, implementing, and maintaining a consolidated audit trail, while others argued that the Commission had underestimated such burdens.
-Nasdaq was among those commenters that stated that the Commission had overestimated the burdens. Specifically, Nasdaq stated that "innovative technology exists to meet many of the Commission's goals at significantly lower costs than estimated in the Proposing Release," and that SROs should be able to weigh the costs and benefits of various designs.120 Other commenters also expressed similar opinions stating that a consolidated audit trail accomplishing the Commission's goals could be implemented for less than the preliminary estimates.121 Two firms with experience in processing and analyzing market data, FTEN and Thomson Reuters, each noted that current technology could convert data from disparate systems into a uniform format, resulting in a less costly implementation of the consolidated audit trail.122 FTEN stated that "currently available commercial systems are capable of immediately accomplishing CAT goals of real-time cross-market transparency, accountability and control with no implementation risk and for far less than the estimated multi-billion dollar price tag."123 It further suggested that "[t]he SEC should leverage already deployed and commercially available solutions that are in production use today by major market participants . . . ." and an "iterative approach [that] would leverage existing systems to capture order and execution data in real-time from liquidity destinations (exchanges, ECNs, ATSs and dark pools) and 'map' the data back to original trade submissions by market participants without requiring integration with, or changes to, market participants systems or to liquidity destination systems and without modifying existing order flow."124 Similarly, another commenter recommended a technology solution that could handle the required data in milliseconds and that "significantly reduces disk space required, which can potentially save millions of dollars when dealing with multiple terabytes of data."125 One commenter suggested an entirely different approach through the use of an "adaptive graph indexing-based architecture" as the basis for the consolidated audit trail platform, instead of using a central repository, and explained that this technology would keep trading data within each SRO.126
-On the other hand, numerous commenters expressed general concerns about the costs of implementing a consolidated audit trail relative to the benefits to be gained. For example, one commenter stated that "there can be no doubt whether market regulators need a consolidated audit trail;" however, the commenter questioned whether a system as costly as the consolidated audit trail was necessary to detect violations such as frontrunning, spoofing, and layering, which are violations the Commission has rarely pursued in the recent past.127
-As discussed above, many commenters expressed general support for the creation of a consolidated audit trail, but believed that, as proposed, the implementation would be too costly and that the Rule should be modified.128 Concern about the proposed real-time requirements for reporting data to the central repository was a common theme expressed by these commenters,129 including those who maintained that a requirement to provide data on a real-time basis would be too burdensome due to the extensive systems changes that would be needed to comply with such a requirement.130 Some of these commenters argued that a real-time reporting requirement would require many industry participants to build entirely new systems or undertake significant technological upgrades.131 SIFMA, in particular, estimated that the cost per broker-dealer to implement real-time reporting could be millions of dollars and that the cost of capturing options quotes in real time alone could exceed the Commission's $2.1 billion estimate for the annualized cost of the audit trail.132 SIFMA further argued that broker-dealers would incur costs associated not only with establishing and maintaining the infrastructure to support real-time reporting, but also due to regulatory risk if they are not able to achieve 100 percent compliance with the proposed Rule.133 While SIFMA opposed a real-time reporting requirement, and encouraged the Commission to adopt a next day or later reporting requirement,134 SIFMA also stated that "if the SEC determines to require reporting of certain data elements in real-time or near real-time, we believe such data should be limited to reporting of 'key business events.'"135 SIFMA further stated that, "if the definition of real-time allowed for reporting within minutes (e.g. 10-15 minutes) of the events, it would be substantially less intrusive on order management systems and may allow for greater flexibility in designing reporting systems architecture and more standardized content for events such as order modifications . . . ."136 SIFMA described how a reporting system using "drop copies"137 could be "achievable in the relative near term," although it noted that its proposed process would not, among other things, include a unique Customer ID or a unique order identifier.138
-Commenters also expressed general concerns regarding the costs of other aspects of the Proposed Rule. For example, Global Electronic Trading Company ("GETCO"), a market maker in equities and equity options, urged the Commission to consider whether quotation information already disseminated by SROs could be reported instead of requiring the SROs and their members to report all quotation information to reduce costs for the industry.139 Another commenter, Wells Fargo Advisors, argued that the inclusion of a unique customer identifier would add "tremendous incremental cost to the [consolidated audit trail]."140
-Many commenters provided suggestions and views on how the costs of creating and implementing a consolidated audit trail might be lowered. For example, financial technology firm, Correlix, Inc. ("Correlix"), stated that relying on existing infrastructure, where possible, could bring down the cost and amount of time it would take to implement the consolidated audit trail.141 Correlix further stated that existing technology already is able to provide "a complete end-to-end history of message and order data from the market participant to the execution venue's matching engine and back to the originator," and that allows clients to run customized queries and reports on the data.142
-A variety of commenters, including SROs and broker-dealers, also believed it would be more cost efficient to use the existing OATS infrastructure specifically as a basis for a consolidated audit trail, rather than to purchase or create an entirely new system.143 Commenters further argued that existing audit trails could be expanded economically and quickly.144
-In contrast, other commenters expressed the view that costs could be reduced not by using existing audit trail infrastructures, but rather by using new, innovative technology to create the consolidated audit trail.145 Noetic Partners, a financial technology firm, explained that technologies are currently available to build a system that would capture "full-depth" data with "compression and near-line storage" in a system that would enable fast retrieval and analysis of data, and opined that, based on existing technology, a consolidated audit trail could be implemented for substantially less than the Commission's preliminary estimates.146 This commenter stated that, based on available technology, a fully functional consolidated audit trail could be implemented in months, rather than years, at an initial cost of less than $100 million.147
-An aggregate analysis of the many specific opinions described above suggests that commenters' views regarding the costs of creating, implementing, and maintaining a consolidated audit trail fall into one of two general categories. One set of commenters expressed the view that many, if not all, of the requirements of the proposed Rule could be met in a cost-effective fashion if current audit trail systems were replaced with new technologies and systems. However, another set of commenters expressed the view that a number of the requirements of the proposed Rule would be very costly to implement, and, instead, suggested that the most cost-effective method of creating a consolidated audit trail would be to relax some of the proposed requirements and build upon the infrastructure of existing audit trail systems.
-Therefore, as discussed above and in detail below,148 in response to these comments, and specific comments discussed throughout this Release,149 the Commission is adopting Rule 613 with substantive changes to some of the specific collection, reporting, and data requirements of the Rule.150 The Commission believes that these changes significantly expand the solutions that could be considered by the SROs for creating, implementing, and maintaining a consolidated audit trail and provide the SROs with increased flexibility in how they choose to meet the requirements of the Rule compared with the requirements of the proposed Rule. For example, the Rule no longer requires real-time reporting151 or only one unique order identifier;152 thus, the Rule would accommodate an NMS plan based on the types of solutions proposed by SIFMA and FINRA. However, to guide the SROs in their development of the NMS plan, the Rule includes several specific considerations153 that the Commission intends to use to evaluate the submitted NMS plan and consider its costs and benefits.
-The changes from the Proposing Release provide the SROs with the flexibility to submit an NMS plan that provides creative solutions that harness innovative technology or that build on existing audit trail systems.
+This section illustrates the reporting requirement when a customer order is split and each slice is subsequently routed to different parties - external Industry Member and subsequently an exchange and to an ATS.
+
+ For this scenario, Industry Member Broker 1 is required to report the following events:
+• New Order event for the customer order
+• Order Route event for the routing of an order slice to Broker 2
+• Order Route event for the routing of an order slice to ATS 3
+For this scenario, Industry Member Broker 2 is required to report the following events:
+• Order Accepted event for the received client order from Broker 1
+• Order Route event for routing of the order to Exchange 1
+For this scenario, Industry Member ATS 3 is required to report the following events:
+• Order Accepted event for the received client order from Broker 1
+• Trade event when the order is matched
+
+ 
+ 
+ 
+ 
pubdate: N/A effdate: N/A
- 3. Comments on the Process for Creating a Consolidated Audit Trail
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Introduction, Summary of General Comments on the Proposed Rule, Comments on the Process for Creating a CAT
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2.1.6. Order Routed from an Exchange through a Routing Broker to another Exchange
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Order Routed from an Exchange through a Routing Broker to another Exchange
+ Compliance User: Industry Member
Keywords:
- NMS Plan,
- FIF,
- STA,
- Comments,
- SROs,
+ Broker,
+ Industry Member Broker 1,
+ original manual timestamp,
- The Commission received comments regarding the process through which a consolidated audit trail should be created. As proposed, the Rule required that the SROs submit an NMS plan setting forth the details for the creation, implementation, and maintenance of a consolidated audit trail within 90 days of approval of the Rule. A few commenters suggested that more time be allotted for the planning and design of the NMS plan.154 FIF and the Security Traders Association ("STA") recommended extensive, "up-front business analysis,"155 explaining that if conducted "during the CAT plan development process, [they] are confident that issues would emerge earlier in the process, leading to more efficient and cost-effective solutions."156 These commenters believed that the business analysis would require many discussions involving the Commission, the SROs and teams comprising members of the securities industry.157
-In this regard, several commenters suggested that the Commission undergo a RFP or request for information ("RFI") process to create and implement a consolidated audit trail.158 Specifically, FIF urged the Commission to perform a RFP process "to determine the best technical solution for developing a consolidated audit trail."159 FIF suggested that the Commission "should outline a set of goals and guiding principles they are striving to achieve as part of the adopted CAT filing and leave the determination of data elements and other technical requirements to [an] industry working group."160 Similarly, Direct Edge suggested that Commission staff should form and engage in a working group to develop an RFP for publication by the Commission.161 DirectEdge explained that an RFP process would facilitate the identification of the costs and benefits of the audit trail, as well as the consideration of a wider range of technological solutions.162 Further, commenters, including Broadridge Financial Solutions, Inc., a technology provider,163 also requested more specific information about the audit trail system to better assess the Commission's initial cost estimates and to determine the best approach to the consolidated audit trail.164
-To gather the necessary information, commenters argued that the timeframe for submitting an NMS plan should be extended. FIF and STA opined that the time needed to perform the analysis to produce a "detailed blueprint for CAT"165 would be closer to six months,166 rather than the proposed 90 days.167 As a basis for their suggestions, FIF provided a breakdown of the time and the types of work needed for FINRA's expansion of OATS to all NMS securities.168 FIF noted that over one-third of the time required for the project was spent on conducting business analysis, and that one-third of the time was spent on project development.169
-In response to these comments, the Rule requires the SROs to provide more information and analysis to the Commission as part of their NMS plan submission than would have been required under the proposed Rule. As discussed in more detail below, these requirements have been incorporated into the Rule as "considerations" that the SROs must address, and they generally mandate that the NMS plan submitted to the Commission for its consideration discuss certain important features and details of the NMS plan, such as how data will be transmitted to the central repository, as well as an analysis of NMS plan costs and impact on efficiency, competition, and capital formation, the process followed by the SROs in developing the NMS plan, and information about the implementation plan and milestones for the creation of the consolidated audit trail.170 These requirements are intended to ensure that the NMS plan is the result of a thorough and well-developed plan for creating, implementing, and maintaining the consolidated audit trail, and the Proposing Release highlighted the importance of these types of considerations. In Section III.C. below, the Commission also provides details about how it envisions regulators would use, access, and analyze consolidated audit trail data through a number of "use cases" to help the SROs prepare a sufficiently detailed NMS plan that addresses the requirements of the adopted Rule.171
-Because of the additional information and analysis required to be included in the NMS plan, the Commission is extending the amount of time allowed for the SROs to submit the NMS plan. Rule 613(a)(1) provides that "[e]ach national securities exchange and national securities association shall jointly file on or before 270 days from the date of publication of the Adopting Release in the Federal Register a national market system plan to govern the creation, implementation, and maintenance of a consolidated audit trail and central repository as required by this section." The Commission will publish the NMS plan submitted in accordance with Rule 608 of Regulation NMS under the Exchange Act172 for public comment and will approve the NMS plan if the Commission determines it is necessary or appropriate in the public interest, for the protection of investors and the maintenance of fair and orderly markets, to remove impediments to, and perfect the mechanisms of, a national market system, or otherwise in furtherance of the purposes of the Act. 173 The Commission also will consider whether the NMS plan submitted for its consideration would achieve the objectives of the Rule.
+This section will show the scenario when one exchange routes an order via a routing broker who is an Industry Member to another exchange.
+
+ For this scenario, the exchange that routes the order (Exchange 1) must report:
+• The route of the order to its routing broker
+• After the execution, a Fill of the routed order
+The routing broker (Industry Member Broker 1) must report the following events:
+• The receipt of the order from the exchange as an Order Accepted event
+• Order Route event for the route of the order to another exchange
+The exchange that accepts the routed order (Exchange 2) must report the following events:
+• The receipt of the order routed from Broker 1; and
+• Any subsequent order handling events, if applicable
+
+ 
+ pubdate: N/A effdate: N/A
+ 2.1.7. Manual Order Route Followed by Electronic Route, Merged Event
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Manual Order Route Followed by Electronic Route, Merged Event
+ Compliance User: Industry Member
+ Keywords:
+ This scenario illustrates the reporting requirements when an Industry Member manually routes an order to another Industry Member and follows up with an electronic route message.
+
+ For this scenario, the sending Industry Member Broker 1 is required to report:
+• New Order event for the customer order
+• Order Route event for the electronically routed order (inclusive of routedOrderID) to Broker 2 with both the electronic and original manual timestamp
+For this scenario, the receiving Industry Member Broker 2 is required to report:
+• Order Accepted event for the electronically received client order (inclusive of routedOrderID) from Broker 1 with both the electronic and original manual timestamp
+
+ 
pubdate: N/A effdate: N/A
- 4. Comments on Alternatives to the Proposed Consolidated Audit Trail
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Introduction, Summary of General Comments on the Proposed Rule, Comments on Alternatives to the Proposed Consolidated Audit
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2.1.8. Manual Order Route, Electronic Duplicate Order
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Manual Order Route, Electronic Duplicate Order
+ Compliance User: Industry Member
Keywords:
- Recommendation,
- Alternatives,
- FINRA,
- OATS,
+ CAT Reporting,
+ Industry Member Broker,
- Several commenters, many of whom generally supported the concept of a consolidated audit trail, recommended alternatives for how a consolidated audit trail should be created, implemented, and maintained. In particular, the Commission received comments suggesting various ways that the OATS system could be modified to serve as the central repository for the consolidated audit trail. FINRA submitted a blueprint for a modified version of OATS that listed certain changes to address the Commission's proposed requirements for the creation, implementation, and maintenance of the consolidated audit trail.174 The proposed modifications included, for example, the addition of data elements capturing whether an order was solicited, customer account type, a large trader identifier,175 and a unique identifier for branch office and registered representative to the data reported to OATS;176 using OATS to capture order and quote data from all national securities exchanges and eventually OPRA; the inclusion of options, fixed income securities, security-based swaps, principal orders and orders originating in firm-controlled accounts for purposes of working a customer order in OATS; the use of CRD numbers to identify broker-dealers; an exchange data processing gateway for OATS to validate submissions from exchanges; full access to regulators of queryable consolidated audit trail data through the FINRA web portal;177 and OATS' acceptance of limited drop-copy report information from broker-dealers on a 15-minute reporting basis.178 However, FINRA's blueprint provided that the large trader identifier should be used initially to identify market participants, as the complexities of tracking retail accounts, the infrequent amount of trading by retail investors, and the large number of such investors make requiring a unique customer identifier difficult.179
-Another commenter from the academic field believed that a modified version of OATS (including fields incorporating ultimate customer account information, a reduction in the time stamp standard to milliseconds or even microseconds, and standardized clock synchronization requirements), coupled with a requirement that exchanges must report to OATS, would allow OATS to fulfill the needs of the consolidated audit trail in a less costly manner than originally proposed.180 This commenter stated that the Commission's needs could be met by "a few tweaks to the existing trade reports and by extending OATS to cover all NMS stocks and executions at exchanges."181
-Several commenters, including SROs and broker-dealers, generally believed that it would be more cost and time efficient to use a form of OATS as a basis for the consolidated audit trail than to purchase or create a new system.182 For example, FINRA/NYSE Euronext stated that modifying existing systems would reduce both the time and cost to develop a consolidated audit trail, explaining that "the programming changes needed to comply with an entirely new system are substantially greater than expanding existing protocols,"183 while BATS suggested that significant cost savings may be realized by building a consolidated audit trail that "leverages elements of OATS."184 FINRA/NYSE Euronext also argued that existing audit trails could be expanded "economically and quickly,"185 noting that use of such systems, such as FINRA's OATS, could make the central repository unnecessary.186 Similarly, FINRA believed that using OATS as a foundation of the consolidated audit trail would make the consolidated audit trail easier to implement,187 as opposed to building a new system, which could take years to establish and would likely result in "negative unintended consequences" during development.188 FIF suggested leveraging FINRA's Trade Reporting and Compliance Engine as a basis for the coverage of debt securities.189
-Two SROs, BOX and CBOE, recommended the joint use of both OATS and COATS.190 BOX suggested an expansion of OATS and COATS to include customer information,191 and CBOE stated that it believed that certain aspects of OATS and COATS could be combined, with the addition of customer and routing broker information, and new formats.192 The Commission also received an alternative proposal from a commenter that was not based on OATS, but on a combination of automatically-generated drop-copies and the Financial Information eXchange ("FIX") protocol.193 SIFMA urged reporting on a T+1 basis as it believed real-time reporting would require significant changes to existing order management and trading systems.194 If T+1 reporting were not adopted, however, SIFMA's proposal suggested that certain data be provided to the central repository in near real time, such as data pertaining to "key business events" such as order receipt and origination, order transmittal, execution, modification, and cancellation. SIFMA's proposal listed the specific data elements to be reported for each event, but, to achieve quick implementation, did not include unique customer or order identifiers, or an identifier for algorithmic orders.195
-The Commission has considered the comments on alternative proposals, including those based on OATS, and has made significant modifications to the proposed Rule in light of such comments. Each of these modifications is discussed in detail in Section III. below. But the Commission notes more generally that, as adopted, Rule 613 does not prescribe a specific audit trail collection system or a particular method of data collection to be used for the central repository. In addition, the Commission believes that certain modifications to Rule 613, such as allowing data to be reported by 8: 00 a.m. Eastern Time the following trading day, rather than in real time as proposed, provide the SROs with a wider range of options for how they choose to meet the requirements of the adopted Rule compared with the requirements of the proposed Rule. This wider range of options could more easily accommodate an OATS-based approach or other approaches for the creation of a consolidated audit trail, as suggested by commenters, consistent with the requirements of Rule 613.
-The Commission notes, however, that OATS, in its current form, has certain limitations and does not include certain attributes that the Commission deems crucial to an effective and complete consolidated audit trail.196 Some of the limitations of OATS that would need to be addressed to meet the requirements of Rule 613 include:
-• At present, only FINRA members are required to report trade and order activity through OATS. The resulting exclusion of some exchange-based and other types of non-member activity could lead to significant gaps in the data as an order is generated, routed, rerouted, and finally executed, canceled, or modified;
-• OATS does not currently require the collection of market-making quotes submitted by registered market makers (in those stocks for which they are registered), resulting in further, significant gaps in the data;
-• OATS is a part of a process by which FINRA collects data from its members for its own regulatory use. OATS is not a central repository and therefore does not presently provide other regulators with ready access to a central database containing processed, reconciled, and linked orders, routes, and executions ready for query, analysis, or download; and
-• OATS does not presently collect options data, and does not afford regulators an opportunity to perform cross-product surveillance and monitoring;
-• OATS does not collect information on the identities of the customers of broker-dealers from whom an order is received. As discussed above in Section I., the Commission believes that the integrated inclusion of such data elements into a single consolidated audit trail provides many important regulatory benefits.
+This scenario illustrates the Phase 2a reporting requirements when an Industry Member manually routes an order but is unable to merge the manual and electronic copies of the order into a single message for CAT Reporting. The Industry Member may report a manual order route event without a routedOrderID, followed by an electronic event which must include electronicDupFlag = true.
+For this scenario, Industry Member Broker 1 is required to report:
+• New Order event for the receipt of the customer order
+• Order Route event for the manual route to Broker 2
+• Order Route event for the electronic route message sent to Broker 2 (marked with electronicDupFlag = true)
+For this scenario, Industry Member Broker 2 is required to report:
+• Order Accepted event once agreeing to the route from Broker 1
+• Order Accepted event for the receipt of the electronic order route from Broker 1 (marked with electronicDupFlag = true)
+
+ 
+ 
+ 
+ 
pubdate: N/A effdate: N/A
- III. Discussion
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Discussion
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Rule 613,
-
- A discussion of each of the key provisions of Rule 613, as adopted, is set forth below.
-pubdate: N/A effdate: N/A
- A. NMS Plan
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Discussion, NMS Plan
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Description,
- Implementation,
-
- pubdate: N/A effdate: N/A
- 1. Description of the Rule
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Discussion, NMS Plan, Description
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2.1.9. Manual Order, One Side Reports Merged Event
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Manual Order, One Side Reports Merged Event
+ Compliance User: Industry Member
Keywords:
- Implementation,
- NMS Plan,
- Comments,
+ Manual Order,
- a. Implementation of the Consolidated Audit Trail through an NMS Plan
-As proposed, the consolidated audit trail would have been created, implemented, and maintained through an NMS plan approved by the Commission. As proposed, Rule 613(a)(1) would have required each national securities exchange and national securities association to jointly file on or before 90 days from approval of the Rule an NMS plan to govern the creation, implementation, and maintenance of a consolidated audit trail and a central repository.197 The Commission would then have been required to publish the NMS plan for public comment pursuant to Rule 608 of Regulation NMS under the Exchange Act,198 and, following the period of public comment, would consider whether or not to approve the NMS plan. In the Proposing Release, the Commission stated its expectation that the exchanges and FINRA would "cooperate with each other and take joint action as necessary to develop, file, and ultimately implement a single NMS plan to fulfill this requirement."199
-The Commission requested comment on this approach. Specifically, the Commission requested comment on whether requiring the exchanges and FINRA to jointly file an NMS plan that would contain the requirements for a consolidated audit trail was the most effective and efficient way to achieve the objectives of Rule 613, or whether the Commission should require the exchanges and FINRA to standardize or otherwise enhance their existing rules. The Commission further requested comment on which approach would be most efficient in improving the ability to monitor cross-market trading, or to undertake market analysis or reconstructions, and why.
-Two commenters discussed how the consolidated audit trail should be created and implemented through an NMS plan.200 One noted that the Rule should provide the SROs with sufficient flexibility to develop an NMS plan that meets the overarching goals of the Commission.201 The second suggested that the Rule should "include only the elements needed for a [consolidated audit trail], and then leave it up to the SROs, [securities information processors] and involved vendors to develop the specifications for the data elements to be specified in the NMS plan, which would ultimately be subject to public comment and SEC approval."202
-Other commenters objected in principle to the use of an NMS plan to create and implement the consolidated audit trail.203 One commenter stated that implementing the consolidated audit trail through an NMS plan would be "difficult and inefficient," given the need "to respond and adapt quickly to new ways of trading and handling orders," and believed it would be difficult to jointly make necessary technology changes under an NMS plan because, based on the commenter's experience of collecting data for an existing audit trail, "technology changes and changes to technical specifications must be made regularly and promptly with respect to firm-specific reporting requirements, interpretations, and codes to keep up with complex and evolving trading and routing strategies."204 Another commenter argued that an NMS plan is "unnecessary … given all of the governance issues with NMS plans" because "[t]he Commission can get most of what it needs with a few tweaks to the existing trade reports and by extending OATS to cover all NMS stocks and executions at exchanges."205
-For the reasons discussed below, the Commission continues to believe that an NMS plan filed pursuant to Rule 608 of Regulation NMS206 is the most effective mechanism to implement the consolidated audit trail, and is adopting Rule 613 with a number of modifications and clarifications to address the concerns of commenters.207
-The Commission believes that the creation, implementation, and maintenance of the consolidated audit trail through an NMS plan will ensure that the SROs' expertise as the "front line" regulators of securities markets is drawn upon to develop the details of the consolidated audit trail, and to make appropriate adjustments as warranted to respond to changes in the securities markets and technology going forward. As such, under the Commission's approach, Rule 613 outlines a broad framework for the creation, implementation, and maintenance of the consolidated audit trail, including the minimum elements the Commission believes are necessary for an effective consolidated audit trail. Additionally, Rules 613(a)(1) and (a)(4), which require that each SRO jointly file and be a sponsor of the NMS plan, is being adopted as proposed. The Commission continues to believe that requiring all SROs to jointly file the NMS plan to establish the consolidated audit trail, as opposed to the flexibility provided by current Rule 608 of Regulation NMS under the Exchange Act,208 which permits any two or more SROs to submit an NMS plan, is appropriate because such a requirement is expected to result in an NMS plan that is the product of negotiation and compromise among all of the SROs; in this regard, the NMS plan submitted to the Commission also may be more readily implemented as the NMS plan should take into consideration the capabilities of every SRO.
-In response to the commenter that advocated granting additional flexibility to the SROs in developing the requirements of the NMS plan,209 the Commission has made significant modifications to the Rule in several respects to increase the options available to SROs in developing the requirements of the NMS plan.210 Furthermore, in instances where Rule 613 sets forth minimum requirements for the consolidated audit trail, the Rule provides flexibility to the SROs to draft the requirements of the NMS plan in a way that best achieves the objectives of the Rule. For example, Rule 613 requires the NMS plan submitted to the Commission for its consideration to require material terms of an order, such as order type, to be collected by the central repository.211 However, the Rule does not enumerate specific order types or prescribe the format or nature of how this information would be represented. This would be left to the SROs developing the NMS plan and allows flexibility for the future, when new order types may be introduced and added, if appropriate.
-Similarly, in response to the commenter stating that implementing the consolidated audit trail through an NMS plan would be "difficult and inefficient" given the need to respond and adapt quickly to new ways of trading and handling orders,212 the Commission notes that, while the NMS plan submitted to the Commission for its consideration must contain the minimum necessary elements for the consolidated audit trail, and any amendments to an effective NMS plan initiated by plan sponsors will require approval by Commission order, the SROs should have flexibility to accommodate a variety of technological and other market developments without amending the NMS plan (e.g., through the issuance and updating of technical specifications that are reasonably and fairly implied by the NMS plan). Underscoring this need to ensure the consolidated audit trail is regularly updated to remain compatible with best market practices, the Commission, as discussed in Section III.C.2.a.i., also has added general requirements to Rule 613 with regards to SROs monitoring and planning for the technological evolution of the consolidated audit trail. Further, as noted in Section III.B.3 below, the NMS plan must include a governance structure for the central repository that is designed to ensure efficient decision-making.
-The Commission has also considered the comment that recommended that the Commission should leave it to the SROs, securities information processors ("SIPs") and vendors to develop the specifications for the data elements in the NMS plan.213 The Commission agrees in principle with the commenter, and believes that market participants other than SROs also could have valuable insights regarding the design of the specifications for the data elements, the central repository, and other aspects of the Rule. To address this concern, the adopted Rule requires the SROs to explain in the NMS plan the process by which they solicited views of their members regarding the creation, implementation, and maintenance of the consolidated audit trail, a summary of the views of such members, and how the plan sponsors took such views into account in preparing the NMS plan.214 In addition, the Rule requires the NMS plan submitted to the Commission for its consideration to provide for the creation of an Advisory Committee to afford SRO members, and other interested parties as permitted by the NMS plan,215 the opportunity to have input on the creation, implementation, and maintenance of the consolidated audit trail.216 The Commission also notes that nothing in the Rule precludes the SROs, as plan sponsors, from consulting with others, including the SIPs and vendors, as they craft the NMS plan. Finally, pursuant to Rule 608(b)(1), the NMS plan will be published for public comment.217 Thus, all interested persons, including market participants, regulatory authorities, and the general public, will have an opportunity to provide meaningful comments on the details and costs of the NMS plan submitted to the Commission, which the Commission will review and consider.
-In response to the commenter that believed that the objectives of the consolidated audit trail could be achieved "with a 'few tweaks' to the existing trade reports and by extending OATS,"218 the Commission notes, as described above, that existing trade reports and the current OATS process combined do not meet many of the requirements the Commission believes are essential for a consolidated audit trail. The Commission therefore believes that an NMS plan, as noted above, provides an effective mechanism for the SROs to create, implement, and maintain a consolidated audit trail meeting such requirements. However, it also notes that the adopted Rule does not preclude the infrastructure, nomenclature, format, or any other aspects of an existing order audit trail system, such as OATS, from being used for the consolidated audit trail, provided the NMS plan proposing to establish such an audit trail otherwise meets the requirements of Rule 613. The Commission stresses that existing order audit trails lack critical information such as the identity of the customer, data on principal orders or quotes, and a way to link orders across markets – information that the Commission believes is essential to the consolidated audit trail.219
+This scenario illustrates the Phase 2a reporting requirements when an Industry Member manually routes an order to anther Industry Member. The sending Industry Member chooses to report a single merged order event with both a manual and systematized timestamp, but the receiving Industry Member reports the receipt of the order twice - once for the manual receipt of the order followed by an electronic duplicate event which includes the electronicDupFlag = true. Note that in Phase 2a, events with either manualFlag = true or electronicDupFlag = true will not be subject to the standard inter-firm linkage process.
+For this scenario, the sending Industry Member Broker 1 is required to report:
+• New Order event for the customer order
+• Order Route event for the electronically routed order (inclusive of routedOrderID) to Broker 2 with both the electronic and original manual timestamp
+For this scenario, the receiving Industry Member Broker 2 is required to report:
+• Order Accepted event for agreeing to the route from Broker 1 (with manualFlag = true)
+• Order Accepted event for the receipt of the electronic order route from Broker 1 (marked with electronicDupFlag = true)
+
+ 
+ 
+ 
pubdate: N/A effdate: N/A
- B. Elements of the NMS Plan
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Discussion, Elements of the NMS Plan
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- SRO,
- NMS Plan,
- Implementation,
- Submission,
- Minimum Requirements,
-
- As discussed above, the adopted Rule requires the SROs to submit an NMS plan to create, implement, and maintain a consolidated audit trail.220 As adopted, the Rule permits the SROs to consider a wider array of solutions, in creating, implementing, and maintaining a consolidated audit trail. The Rule, however, also sets forth certain minimum requirements of the consolidated audit trail that must be included in the NMS plan submitted by the SROs to the Commission for its consideration. The Commission believes that it is important to set forth certain minimum requirements to ensure that the consolidated audit trail will be designed in a way that provides regulators with the accurate, complete, accessible, and timely market activity data they need for robust market oversight. The minimum audit trail requirements that must be included in the NMS plan submitted by the SROs are discussed below.
-pubdate: N/A effdate: N/A
- 1. Recording and Reporting
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Discussion, Elements of the NMS Plan, Recording and Reporting
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2.2. Trade Scenarios
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Trade Scenarios
+ Compliance User: Industry Member
+ Keywords:
+ pubdate: N/A effdate: N/A
+ 2.2.1. Agency Order Cross
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Trade Scenarios, Agency Order Cross
+ Compliance User: Industry Member
+ Keywords:
+ New Order event,
+
+ This scenario illustrates the reporting requirements to CAT when an Industry Member (Broker 1) matches a Customer Buy order with a Sell order routed from another Industry Member (Broker 2).
+
+ For this scenario, Industry Member Broker 1 is required to report the following events:
+1) The receipt of the order from the customer (New Order event)
+2) The receipt of the order routed from Broker 1 (Order Accepted event)
+3) The execution (Trade event)
+Industry Member Broker 2 would report the following events:
+1) The receipt of customer order (New Order event)
+2) The route of the order to Broker 1 (Order Route event)
+The customer Order A at Broker 1 was fully executed, while the routed order from Broker 2 was partially executed.
+For ATS agency order cross, please refer to Section 2.2.1 step 10 for more details.
+
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.2.2. Internalized Trade against Proprietary Account
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Trade Scenarios, Internalized Trade against Proprietary Account
+ Compliance User: Industry Member
+ Keywords:
+ Trade Event,
+ Industry Member Broker 1,
+
+ This scenario illustrates the reporting requirements to CAT for an Industry Member that executes a customer order against its own proprietary account.
+For this scenario, Industry Member Broker 1 is required to report the following events:
+• The receipt of the customer order as a New Order event (New Order event)
+• The execution as a Trade event
+
+ 
+ pubdate: N/A effdate: N/A
+ 2.2.3. ATS Cross with Multiple Orders on One Side
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Trade Scenarios, ATS Cross with Multiple Orders on One Side
+ Compliance User: Industry Member
Keywords:
- Products,
- Covered Transactions,
- Orders,
- Quotations,
- Persons Required to Report,
- Central Repository,
- Reportable Ebents,
- Data Elements,
- Material Terms,
- Order Type,
- Special Handling Instructions,
- National Securities Exchange,
- National Securities Association,
- Broker-Dealer Identifiers,
- Customer Identifier,
+ Order,
+ ATS A,
- a. Products and Transactions Covered
-As proposed, Rule 613 would have applied to secondary market transactions in all NMS securities, which includes NMS stocks and listed options.221 In the Proposing Release, the Commission also addressed the possibility of expanding the scope of the consolidated audit trail over time. Specifically, proposed Rule 613(i) would have required the NMS plan to include a provision requiring each national securities exchange and national securities association to jointly provide to the Commission, within two months after effectiveness of the NMS plan, a document outlining how such exchanges and associations would propose to incorporate into the consolidated audit trail information with respect to equity securities that are not NMS securities, debt securities, primary market transactions in NMS stocks, primary market transactions in equity securities that are not NMS securities, and primary market transactions in debt securities. The document also would have been required to identify which market participants would be required to provide the additional data and to include an implementation timeline and a cost estimate for including such data in the consolidated audit trail.222 The Commission requested comment on whether expanding the consolidated audit trail to include the products and transactions specified above was an appropriate approach to the eventual expansion of the consolidated audit trail, and, if so, an appropriate and realistic timetable for doing so.
-Several commenters expressed opinions on the scope of the products and transactions proposed to be covered by the Rule and how their inclusion in the consolidated audit trail should be phased in under the Rule.223 One commenter urged the Commission to consider including additional asset classes in the scope of the products covered by the Rule, and specifically questioned the value of the consolidated audit trail without the inclusion of information on futures and other derivatives.224
-The Commission also received comment on the proposed Rule's approach for considering a possible future expansion of the products and transactions covered by the consolidated audit trail. One commenter believed that its technology would allow development of a platform that would support multiple asset classes and expansion of the consolidated audit trail for use by other regulators.225 Other commenters expressed general support for expanding the scope of products covered.226 One specifically suggested expanding the scope of the Rule, for example, to include the "creation of instruments that underlie the securities that make up [mortgage-backed securities] and [asset-backed securities]."227 Another suggested expanding the consolidated audit trail to all securities submitted to an exchange or clearing agency.228 Yet another commenter, however, argued against allowing the exchanges, through the NMS plan, to have primary responsibility for specifying the data requirements of non-exchange-traded asset classes, stating that exchanges lacked experience with these instruments.229
-The Commission has considered the comments discussed above and is adopting the Rule as proposed with respect to the scope of the securities that must be covered at this time, but, as described below, acknowledges the importance of a mechanism for considering other types of products in the future. Specifically, the adopted Rule requires that consolidated audit trail data be collected for all NMS securities.230 However, the Commission also is adopting the requirement that the NMS plan require the SROs to jointly submit a document outlining a possible plan for expansion of the consolidated audit trail, as proposed, but with three modifications from the proposed Rule.
-Rule 613(i) requires that the SROs jointly provide the Commission a document outlining how the SROs could incorporate the following additional products into the consolidated audit trail: equity securities that are not NMS securities, debt securities, primary market transactions in equity securities that are not NMS securities, and primary market transactions in debt securities ("expansion document"). The adopted Rule also requires the expansion document to include details for each order and reportable event that may be required to be provided, which market participants may be required to provide the data, an implementation timeline and a cost estimate. The first modification from the proposed Rule is a technical change clarifying that Rule 613(i) is requiring the SROs to provide the Commission with a document that outlines how an expansion of the consolidated audit trail could be accomplished in the future and is not, at this time, requiring that the SROs commit to expanding the consolidated audit trail beyond secondary market transactions in NMS securities.231 However, the Commission notes that Rule 613(i) retains the requirement that SROs include an implementation timeline and a cost estimate; in this regard, the Commission expects that the SROs will address fully in the expansion document how any such expansion of the consolidated audit trail could be implemented in practice, and that such document would include sufficient detail for the Commission to ascertain how the SROs could proceed with such expansion. The Commission would expect to make the expansion document publicly available on its website and to solicit a wide range of comment on it to further inform and facilitate the expansion of the consolidated audit trail if appropriate, taking into account the relevant considerations contemplated by Rule 613(a)(1). In addition, the expansion document could inform the detailed plans that are to be prepared at least every two years by the CCO of the NMS plan.232
-In addition, after considering the comments received relating to the potential expansion of the consolidated audit trail and how such an expansion might occur,233 the Commission is making the second modification to the proposed Rule to extend the deadline for submitting the expansion document from two months to six months from the date of effectiveness of the NMS plan approved by the Commission. The Commission believes that the additional four months will provide the time necessary after the approval of the NMS plan by the Commission for the SROs to consider how they might expand the consolidated audit trail to capture orders and trading in these additional securities and thus will aid the Commission in receiving an outline or plan from the exchanges and associations that has had the benefit of additional time for analysis and planning. Finally, given the extension of the deadline for submitting the expansion document and the importance of information regarding primary market information in NMS stocks relative to other types of transactions as discussed in Section III.B.1.a. below, the Commission is removing the requirement that the expansion document discuss all primary market transactions in NMS stocks and is, instead, as discussed later, requiring that a discussion of the feasibility, benefits, and costs of incorporating into the consolidated audit trail information about allocations in primary market transactions in NMS securities be addressed with the NMS plan submission.234 However, the expansion document must still include a discussion of primary market transactions in equity securities that are not NMS securities.
-The Commission agrees in principle with the commenters that advocated a phased approach to implementation.235 The Commission, however, has determined not to modify the proposed scope of the Rule, which applies to orders in NMS securities. The Commission also adopts substantially its proposed implementation timeframes that apply if and when the NMS plan is approved,236 except that the NMS plan may provide up to one additional year before small broker-dealers will be required to provide information to the central repository.237
-The Commission continues to believe that the Rule's requirement to include secondary market transactions in all NMS securities (i.e., both listed equities and options) is a reasonable first step in the implementation of the consolidated audit trail. In addition, the Commission believes that applying the Rule solely to NMS securities should allow for a less burdensome implementation of the consolidated audit trail as compared to applying the Rule to a broader set of securities,238 in large part because market participants already have experience with audit trails for transactions in these securities. And, as discussed in detail above,239 there are many significant benefits of a consolidated audit trail that includes NMS securities (even if it is only limited to NMS securities).
-With regards to a phased approach to implementation, the Commission notes that the data recording and reporting requirements would apply initially, as proposed, to the SROs but not to their members. This will allow members additional time to, among other things, implement the systems and other changes necessary to provide the required information to the central repository, including capturing customer and order information that they may not have previously been required to collect. Should the SROs determine that additional implementation phases might be appropriate (e.g., applying the Rule first to equities and then to listed options), the Commission notes that the Rule does not preclude the SROs from proposing such phases, so long as the outer time parameters specified in the Rule, which the Commission is adopting as proposed, are met.240
-The Commission agrees with commenters that the inclusion of additional products (even at a later date) could further enhance the ability of the SROs and the Commission to conduct effective market oversight for financial products currently trading in the marketplace.241 The Commission also believes that it could be beneficial for the consolidated audit trail to be expanded over a reasonable period of time to include information on primary market transactions in equity and debt securities, as this data could be used to quickly assess potential violations of various rules under the Exchange Act such as, for example, Regulation M and Rule 10b-5.242 For example, the primary market transaction data would allow regulators to more quickly identify whether any participant in an offering sold short prior to the offering in violation of Regulation M. The primary market transaction data would allow for identification of the cost basis for purchases by intermediaries and make it easier to assess whether subsequent mark-ups to investors in primary offerings are fair and reasonable and, if not, whether there has been a violation of the antifraud provisions of the federal securities laws, including Rule 10b-5.
-The Commission considered the comment letter that agreed that "policing the market requires a comprehensive approach" but asserted the exchanges should not be primarily responsible for specifying requirements relating to asset-backed securities and other debt instruments, including swap instruments that are not exchange-traded.243 In response, the Commission notes the Rule requires the SROs to submit a document outlining a plan for the possible expansion of the NMS plan to non-NMS securities – namely debt securities and equity securities that are not NMS securities.244 The Commission also notes that FINRA, the SRO responsible for oversight of trading in the over-the-counter market, would participate in the preparation of such expansion document, and expects that FINRA would provide substantial input as to how the consolidated audit trail might be expanded to include non-NMS securities. Because the consolidated audit trail will be jointly owned and operated by the SROs pursuant to the NMS plan, however, the Commission believes that the involvement of all of the SROs in any potential expansion process is appropriate.
-The Commission also notes that any expansion of the consolidated audit trail to include transactions in non-NMS securities would be effected through public notice and comment, and take into account the relevant considerations contemplated by Rule 613(a)(1). Furthermore, adopted Rule 613(b)(7), discussed in more detail later in this Release,245 requires the NMS plan to include an Advisory Committee, which includes members of the plan sponsors and other interested parties as set by the NMS plan,246 that would be available to provide consultation on matters concerning the central repository, including the securities subject to the Rule. Therefore, the Commission believes that the participation of FINRA, the public, and the Advisory Committee should assist the SROs in devising a document outlining the expansion of the consolidated audit trail to other securities.
-The Commission continues to believe that the expansion document required by Rule 613(i) will provide valuable information to the Commission and help inform the Commission about the likely efficacy of expanding the scope of the consolidated audit trail to include information on equity securities that are not NMS securities, debt securities, primary market transactions in equity securities that are not NMS securities, and primary market transactions in debt securities. In addition, the expansion document will aid the Commission in assessing the feasibility and impact of the plan sponsors' proposed approach.
-The Commission acknowledges that plan sponsors will incur costs to prepare the expansion document. For example, plan sponsors will be required to address, among other things, details for each order and reportable event for which data may be submitted; which market participants may be required to provide the data; an implementation timeline; and a cost estimate. Thus, the plan sponsors must, among other things, undertake an analysis of technological and computer system acquisitions and upgrades that would be required to incorporate such an expansion. The Commission, however, believes that it would be beneficial to receive a document outlining how the plan sponsors could incorporate into the consolidated audit trail securities in addition to NMS securities, such as over-the-counter equity and debt securities, as soon as practicable. This is because such an expansion document will aid the Commission in assessing both the feasibility of expanding the audit trail to these additional securities, possibly including, as commenters urged, instruments that underlie mortgage-backed securities and asset-backed securities, and the resulting potential benefits to the securities markets as a whole if the consolidated audit trail is expanded in the manner described in the document submitted by the plan sponsors pursuant to Rule 613(i).
-b. Orders and Quotations
-As proposed, Rule 613 would have required that information be provided to the central repository for every order in an NMS security originated or received by a member of an exchange or FINRA. Proposed Rule 613(j)(4) would have defined "order" to mean: (1) any order received by a member of a national securities exchange or national securities association from any person; (2) any order originated by a member of a national securities exchange or national securities association; or (3) any bid or offer.247 In sum, the Commission proposed that the Rule cover all orders (whether for a customer or for a member's own account), as well as quotations in NMS stocks and listed options.248
-The Commission requested comment about the scope of its proposed definition of "order," including whether principal orders249 should be included in the scope of the consolidated audit trail and whether there are any differences between orders and quotations that should be taken into account with respect to the information that would be required to be provided to the central repository. The Commission also requested comment on whether non-firm quotations should be included in the consolidated audit trail and marked to show that they are not firm.250
-Commenters generally supported the inclusion of principal orders in the definition of "order,"251 but some expressed concern about including market maker quotations in the consolidated audit trail.252 In particular, these commenters thought that the volume of quotes proposed to be collected was so large that it would require market participants to increase the capacity of their systems that would transmit data to the central repository, and thus recommended that market maker quotations be exempted from the Rule's reporting requirements.253 One of these commenters specifically suggested that the Rule use the same approach as is currently used for the COATS – which contains order, quote (but only the top of market quote) and transaction data for all market participants.254
-The Commission also received two comments regarding the inclusion of non-firm orders and quotes in the consolidated audit trail. One commenter, consistent with the proposed Rule, stated that only firm orders and quotes should be included.255 Another commenter, however, believed that the proposed Rule did not go far enough, and stated that the Rule should require that information relating to indications of interest or similar communications be reported to, among other things, assist the SROs and the Commission in detecting "spoofing,"256 where a market participant enters and quickly cancels limit orders or quotations with the intent of having those non-bona fide orders or quotations change the NBBO or create a misperception of the available market liquidity to induce others to change their trading decisions.
-In addition to the comments regarding inclusion of principal and non-firm orders and quotes in the consolidated audit trail, some commenters suggested ways to narrow the definition of "order." One commenter would exempt "non-trading transfers of securities within a legal entity, such as internal journals of securities within a desk or aggregation unit," from the mandatory reporting requirements.257 Another commenter – an options exchange - recommended that the Commission only require consolidated NBBO data to be reported with respect to options quotations, noting that there are millions of quotes per day on its exchange and that certain options, including out-of-the-money options, are subject to a high volume of quotation updates but generate limited trading activity.258
-The Commission considered the comments regarding the scope of the quotes and orders that should be included in the Rule's definition of "order," and acknowledges that costs will be incurred by SROs and their members to record and report this information to the central repository and by the central repository to receive, consolidate, store and make accessible such information.259 The Commission also acknowledges that requiring the recording and reporting of all quotes and orders may entail more costs, such as additional development time and storage capacity, than if the Commission did not require the recording and reporting of market maker quotes or out-of-the-money options. Nevertheless, because the Commission continues to believe that many of the benefits of a consolidated audit trail can only be achieved if all orders and quotations are included, the Commission is adopting the definition of "order" in Rule 613(j)(4) (renumbered as Rule 613(j)(8)), as proposed, to include orders received by a member of an exchange or FINRA from any person, any order originated by a member of an exchange or FINRA, and any bid or offer, including principal orders.260
-The Commission believes it is important for the consolidated audit trail to capture information for all principal orders and market maker quotations because principal orders and market maker quotations represent a significant amount of order and transaction activity in the U.S. markets. Effective surveillance of their trading is critical to detecting a variety of types of potential misconduct such as manipulation and trading ahead. By providing regulators comprehensive information about principal orders and market maker quotations throughout the U.S. markets – information that is not available to regulators today using existing audit trails – the consolidated audit trail would allow regulators to efficiently surveil for manipulative and other illegal activity by market making and other proprietary trading firms. In addition, any comprehensive market reconstruction or other market analysis would need to take into account principal orders and market maker quotations – which, as noted above, constitute a large percentage of the orders and trades in today's markets – to provide a complete and accurate picture of market activity.
-Furthermore, the Commission believes that including principal orders and market maker quotations in the consolidated audit trail would permit SROs to more efficiently monitor the market for violations of SRO rules. Such monitoring requires determination of the exact sequence of the receipt and execution of customer orders in relation to the origination and execution of principal orders or market maker quotations. For example, SROs would be able to use the consolidated audit trail data to more efficiently detect instances when a broker-dealer receives a customer order and then sends a principal order or quote update to an exchange ahead of the customer order, potentially violating the trading ahead prohibitions in SRO rules.261
-In addition, information on principal orders or market maker quotations could be useful in investigating illegal "spoofing." The availability to regulators of comprehensive information about principal orders and market maker quotations would allow them to more efficiently and effectively identify the source of the orders or quotations and, thus, better determine whether the quoted price was manipulated or simply a response to market forces.
-A further example where information on principal orders and market maker quotations would enhance regulatory efforts is in reviewing "layering" or other manipulative activity. Layering is a form of market manipulation where orders are placed close to the best buy or sell price with no intention to trade in an effort to falsely overstate the liquidity in a security. Layering attempts to manipulate the shape of the limit order book to move the price of a security or influence the trading decisions of others. Layering is often effected with principal orders, so inclusion of principal orders in the consolidated audit trail would aid regulators in the detection of this manipulative practice.262
-The Commission considered the comment that recommended excluding certain quotations, such as those generated for out-of-the-money options, from the definition of "orders" required to be reported to the central repository.263 The Commission, however, believes that such quotations must be included in the consolidated audit trail. Although there may be a high volume of quotations in out-of-the-money options with limited resulting trading activity, the Commission believes that having a record of those quotations is necessary to allow regulators to surveil high-speed quoting strategies for manipulative or other illegal behavior and to assess the impact of market making and other high-frequency quoting behaviors on the quality of the markets. Including these quotations is necessary for example, because the Commission may investigate allegations of a broker-dealer engaging in the practice of flooding the market with out-of-the-money option quotations for the purpose of manipulating the price of the option or related security, or to overload exchange execution systems. Based on the foregoing, to ascertain whether any illegal activity might be occurring through the misuse of quoting, the consolidated audit trail must require all bids and offers to be collected and reported to the central repository.
-The Commission also considered the comment that asserted that "non-trading transfers of securities within a legal entity, such as internal journals of securities within a desk or aggregation unit" should be exempt from the reporting requirements of the Rule.264 In response to this comment, the Commission notes that Rule 613 does not require the reporting of such transfers because they are not "orders," as defined under Rule 613(j)(8). However, Rule 613 does require the NMS plan to require the reporting of the internal routing of orders at broker-dealers.265
-The Commission also considered the comment that recommended including indications of interest in the definition of "order."266 The Commission, however, is not including indications of interest in the definition of "order" for purposes of the consolidated audit trail because the Commission believes that the utility of the information such data would provide to regulators would not justify the costs of reporting the information. Indications of interest are different than orders because they are not firm offers to trade, but are essentially invitations to negotiate. As such, the Commission believes that indications of interest are less likely to be used as a vehicle for illegal activity, such as manipulation or layering, because they would be less likely to induce a response from other market participants.
-c. Persons Required to Report Information to the Central Repository
-Under proposed Rule 613(c)(5), each national securities exchange and its members would have been required to collect and provide to the central repository certain data for each NMS security registered or listed on a national securities exchange, or admitted to unlisted trading privileges on such exchange; and, under proposed Rule 613(c)(6), each national securities association and its members would have been required to collect and provide to the central repository certain data for each NMS security for which transaction reports would be required to be submitted to a national securities association. Proposed Rule 613(c)(7) would have required each national securities exchange, national securities association, and any member of such exchange or association to collect and provide to the central repository certain details, delineated in such Rule, for each order and each reportable event. The Commission requested comment on whether requiring SROs and their members to report the required order information to the central repository was appropriate.
-Several commenters broadly objected to the requirement that all broker-dealers report consolidated audit trail information to the central repository and/or proposed alternatives to such a requirement.267 One commenter suggested that introducing brokers should be permitted to rely on their clearing firms for reporting to the central repository, arguing that requiring separate reporting by introducing brokers and clearing firms "will only dilute the economic benefits realized by Introducing Brokers through such clearing arrangements and may result in increased costs to customers."268 This commenter also stated that it does not believe there is appreciable benefit to the Commission, FINRA or the markets in general in mandating reporting by introducing brokers.269
-Similarly, another commenter urged the Commission to exclude broker-dealers from the consolidated audit trail reporting requirements if they route their orders exclusively to another reporting firm that is solely responsible for further routing decisions, on the basis that this would essentially result in duplicative reporting.270 In addition, this commenter recommended the Commission exempt small broker-dealers from the reporting requirements if compliance would be unduly burdensome.271 Another commenter, a small broker-dealer that manually handles orders, specifically suggested that the Commission adopt a provision similar to FINRA Rule 7470, which provides FINRA staff the authority to grant exemptions to broker-dealers that solely handle orders manually from OATS recording and data transmission requirements.272
-Three commenters argued that broker-dealers should not be required to report quotation information to the central repository that is available from other market participants.273 Specifically, one commenter argued that broker-dealers should not be required to report information to the central repository that has already been reported to an SRO (e.g., market maker quotes) because the SRO would also be reporting the information to the central repository.274 Another commenter stated that it "believes that, rather than requiring quote reporting by broker-dealers, only the exchanges and FINRA (through its Alternative Display Facility and proposed Quotation Consolidation Facility) should be required to report quotations," and added that "[t]he exchanges and FINRA are in a position to provide quotation information at a lower cost and with more accuracy."275 Similarly, a third commenter urged the Commission to consider "whether surveillance systems could rely on quotation information disseminated by the SROs," instead of requiring all quotation data to be sent separately to the repository.276
-The Commission considered the comments objecting to the requirement that broker-dealers report all consolidated audit trail information to the central repository. However, for the reasons discussed below, the Commission is adopting the requirements as proposed with regard to the obligation of members to report required data to the central repository.277 Specifically, the Commission is adopting Rules 613(c)(5) and (6) as proposed. Rule 613(c)(5) provides that "[t]he national market system plan submitted pursuant to this section shall require each national securities exchange and its members to record and report to the central repository the information required by [Rule 613(c)(7)] for each NMS security registered or listed for trading on such exchange or admitted to unlisted trading privileges on such exchange," and Rule 613(c)(6) provides that "[t]he national market system plan submitted pursuant to this section shall require each national securities association and its members to record and report to the central repository the information required by paragraph (c)(7) of this section for each NMS security for which transaction reports are required to be submitted to the association."
-In essence, the Commission believes these provisions are appropriate because they require each party – whether a broker-dealer, exchange or ATS – that takes an action with respect to an order, and thus has the best information with respect to that action, to record and report278 that information to the central repository.279 For example, the broker-dealer originating an order – whether received from a customer or generated as a principal order – is in the best position to record the terms of that order, including the time of origination, as well as the unique customer and order identifiers. If the originating broker-dealer is required to record the time each order in a rapid series of principal orders is generated, for example, regulators will be able to more accurately reconstruct the sequence of those orders for purposes of conducting market surveillances for manipulative or other illegal activity, or for performing market reconstructions. In addition, requiring the originating broker-dealer to record the time an order was received from a customer could then help regulators more accurately determine whether the broker-dealer quickly traded ahead of the customer order. On the other hand, if the recording and reporting requirements initially applied only to the executing or routing broker-dealer, or the exchange in the case of market maker quoting, regulators would not know the precise time the order or quote was originated, and would not be able to implement or perform as efficiently effective surveillances, such as those discussed above. In addition, the lack of precise order origination time could interfere with the ability of regulators to perform accurate market reconstructions or analyses, particularly with respect to high frequency trading strategies. Thus, the Commission believes that every broker-dealer (and exchange) that touches an order must record the required data with respect to actions it takes on the order, contemporaneously with the reportable event, to ensure that all relevant information, including the time the event occurred, is accurately captured and reported to the consolidated audit trail.280
-While a broker-dealer will be required to record any actions it takes with respect to an order because such recordation would capture information, particularly the time stamp, which is needed by regulators for the reasons discussed above, the Commission notes that nothing in the Rule precludes the NMS plan submitted to the Commission for its consideration from allowing an introducing broker or other broker-dealer to use a third party, such as a clearing broker-dealer, to report the data recorded by the introducing broker or other broker-dealer to the central repository.
-The Commission acknowledges that SROs and their members will incur costs to record and report the audit trail data required by Rules 613(c)(5), 613(c)(6) and 613(c)(7).281 The Commission also acknowledges that, in some instances, the information required to be recorded and reported by some market participants, for example, market makers, may indeed be available from other market participants (in the case of market makers, the exchanges) and that there might be additional costs for all market participants to record and report information. However, for the reasons noted above, the Commission believes that requiring every market participant that touches an order to record and report the required audit trail data to the central repository, and thus requiring these market participants to incur these costs is appropriate. The Commission believes that such costs will depend on the exact details of how information is to be recorded and reported to the central repository, including whether third-parties, such as clearing-brokers or exchanges, facilitate the transmission of such data. But because these costs depend on details that are not being prescribed by the Commission, Rule 613 requires that the SROs must, in their proposal of the specific mechanisms by which data will be reported to the central repository, include cost estimates of their solution, as well as a discussion of the costs and benefits of the various alternatives considered but not chosen.282 More so, as discussed above in Section I, once the Commission receives the submitted NMS plan, it will be able to use such plan-specific details and costs estimates, as well as public comment on the NMS plan, in determining whether to approve the NMS plan.
-The Commission also considered the comment that small broker-dealers should be granted an exemption from the Rule,283 and, as discussed in Section III.D., is adopting Rule 613(a)(3)(vi), which provides that the NMS plan shall require each SRO to require small broker-dealers to provide audit trail data to the central repository within three years after effectiveness of the NMS plan, as opposed to within two years as proposed.284 The Commission believes that completely exempting small broker-dealers from reporting requirements would be contradictory to the goal of Rule 613, which is to create a comprehensive audit trail. In effect, an exemption to small broker-dealers from the requirements of the Rule would eliminate the collection of audit trail information from a segment of the broker-dealer community and would thus result in an audit trail that does not capture all orders by all participants in the securities markets for NMS securities. The Commission notes that illegal activity, such as insider trading and market manipulation, can be conducted through accounts at small broker-dealers just as readily as it can be conducted through accounts at large broker-dealers. In addition, granting an exemption to certain broker-dealers might create incentives for prospective wrongdoers to utilize such firms to evade effective regulatory oversight through the consolidated audit trail. The Commission recognizes, however, that small broker-dealers, particularly those that operate manual systems, might be particularly impacted because of their more modest financial resources and may need additional time to upgrade to an electronic method of reporting audit trail data to the central repository, and thus believes that allowing the NMS plan to permit such broker-dealers up to an extra year to begin reporting data to the central repository if the plan sponsors believe such an accommodation is reasonable, is appropriate. The Commission believes up to an additional year could allow small broker-dealers extra time to explore the most cost-effective and most efficient method to comply with the Rule. The Commission acknowledges that permitting small broker-dealers up to three years to begin reporting the required audit trail data to the central repository will delay the ability of regulatory authorities to obtain full information about all orders from all participants, which in turn will result in delaying the full regulatory benefit of the consolidated audit trail. However, the Commission believes that such an accommodation to small broker-dealers is reasonable, given the fact that small broker-dealers may face greater financial constraints in complying with Rule 613 as compared to larger broker-dealers. 285 The Commission also notes that many small broker-dealers are introducing broker-dealers and may be able to use their clearing broker-dealers to report the data to the central repository, thereby potentially reducing some of their costs.
-d. Reportable Events and Consolidated Audit Trail Data Elements
-As proposed, Rule 613 would have required SROs and their respective members to provide certain information regarding each order and each "reportable event" to the central repository. A reportable event would have been defined in proposed Rule 613(j)(5) to include, but not be limited to, the receipt, origination, modification, cancellation, routing, and execution (in whole or in part) of an order.
-For the reportable event of receipt and origination of an order, proposed Rule 613(c)(7)(i) would have required the reporting of the following data elements: (1) information of sufficient detail to identify the customer; (2) a unique customer identifier for each customer; (3) customer account information; (4) a unique identifier that would attach to an order at the time of receipt or origination by the member; (5) a unique identifier for the broker-dealer receiving or originating an order; (6) the unique identifier of the branch office and registered representative receiving or originating the order; (7) the date and time (to the millisecond) of order receipt or origination; and (8) the material terms of the order.
-For the reportable event of routing of an order, proposed Rule 613(c)(7)(ii) would have required the reporting of the following information by the member or SRO that is doing the routing, each time an order is routed: (1) the unique order identifier; (2) the date on which an order was routed; (3) the exact time (in milliseconds) the order was routed; (4) the unique identifier of the broker-dealer or national securities exchange that routes the order; (5) the unique identifier of the broker-dealer or national securities exchange that receives the order; (6) the identity and nature of the department or desk to which an order is routed if a broker-dealer routes the order internally; and (7) the material terms of the order.
-Rule 613(c)(7)(iii), as proposed, also would have required the collection and reporting by the SRO or member receiving a routed order of the following information: (1) the unique order identifier; (2) the date on which the order is received; (3) the time at which the order is received (in milliseconds); (4) the unique identifier of the broker-dealer or national securities exchange receiving the order; (5) the unique identifier of the broker-dealer or national securities exchange routing the order; and (6) the material terms of the order.
-For the reportable events of modification or cancellation of an order, proposed Rule 613(c)(7)(iv) would have required the following data be collected and reported: (1) the date and time (in milliseconds) that an order modification or cancellation was originated or received; (2) the price and remaining size of the order, if modified; (3) the identity of the person responsible for the modification or cancellation instruction; and (4) other modifications to the material terms of the order.
-For full or partial executions of an order, proposed Rule 613(c)(7)(v) would have required the following information to be collected and reported to the central repository: (1) the unique order identifier; (2) the execution date; (3) the time of execution (in milliseconds); (4) the capacity of the entity executing the order (whether principal, agency, or riskless principal); (5) the execution price; (6) the size of the execution; (7) the unique identifier of the national securities exchange or broker-dealer executing the order; and (8) whether the execution was reported pursuant to an effective transaction reporting plan or pursuant to the OPRA Plan.
-The Commission received comments on the information proposed to be recorded and reported to the central repository for each reportable event (i.e., the consolidated audit trail data elements) but did not receive comments on the proposed definition of reportable event in proposed Rule 613(j)(5) (i.e., the events that trigger consolidated audit trail reporting requirements). However, the Commission is making clarifying changes to proposed Rule 613(j)(5) (renumbered as Rule 613(j)(9)) to define a "reportable event" as including the original receipt of a customer's order by a broker-dealer; the origination of an order by a broker-dealer (i.e., a principal order); and the receipt of a routed order. Thus, Rule 613(j)(9), as adopted, provides that "[t]he term reportable event shall 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." The Commission believes these changes from the proposal are appropriate because they conform Rule 613(j)(9) to the provisions of Rule 613(c)(7). Specifically, Rule 613(c)(7) is structured around each "reportable event;" therefore, audit trail data is listed according to the data that must be reported upon "original receipt or origination" of an order (Rule 613(c)(7)(i)); "routing" of an order (Rule 613(c)(7)(ii)); "receipt of an order that has been routed" (Rule 613(c)(7)(iii)); "modification or cancellation" of an order (Rule 613(c)(7)(iv)); and "execution" of an order (Rule 613(c)(7)(v) and (vi)).
-As noted above, the Commission received comments on the information proposed to be recorded and reported to the central repository with each reportable event (i.e., the consolidated audit trail data elements) and, in response, is adopting the Rule with certain modifications from the proposed Rule with respect to certain of the consolidated audit trail data elements. In so adopting the Rule, the Commission acknowledges that costs will be incurred by SROs and their members to record and report this information to the central repository and by the central repository to receive, consolidate, store and make accessible such information.286 However, the Commission believes that the costs to SRO members for reporting this information, and the costs to the central repository for collecting and storing this information, will significantly depend on the exact details of how this information will be gathered and transmitted by the various types of market participants covered by Rule 613. The Commission is therefore requiring the SROs to include as part of the NMS plan submitted to the Commission for its consideration pursuant to the Rule, details of how each of the different data elements would be recorded, reported, collected, and stored, as well as cost estimates for the proposed solution, and a discussion of the costs and benefits of alternate solutions considered but not proposed. The Commission also notes that the SROs are not prohibited from proposing additional data elements not specified in Rule 613 if the SROs believe such data elements would further, or more efficiently, facilitate the requirements of the Rule.
-Once the SROs have submitted an NMS plan with these details, the Commission will be able to use this information to determine whether to approve the NMS plan. The Commission at this time is only directing the SROs to develop and submit a detailed NMS plan that includes each of the data elements. The Commission is not making a final determination of the nature and scope of the data elements to be included in the consolidated audit trail – as discussed above, these determinations will be made after the SROs submit the NMS plan, and the Commission and public have had an opportunity to consider the proposed data elements.
-Rather, at this time the Commission is only making a more limited determination. The benefits the Commission and the public will receive from being able to consider the detailed costs and benefits of the specific set of data elements submitted to the Commission for its consideration pursuant to the Rule justify the costs of preparing the NMS plan with such data elements included.
-A discussion of these consolidated audit trail data elements follows.
-i. Material Terms of the Order
-As proposed, Rule 613 would have required broker-dealers to report the material terms of the order upon origination or receipt of an order and upon routing, modification, and cancellation of an order.287 Proposed Rule 613(j)(3) (renumbered as Rule 613(j)(7)) defined material terms of the order to include, but not be limited to, the following information: (1) the NMS security symbol; (2) the type of security; (3) price (if applicable); (4) size (displayed and non-displayed); (5) side (buy/sell); (6) order type; (7) if a sell order, whether the order is long, short, or short exempt;288 (8) if a short sale, the locate identifier; (9) open/close indicator; (10) time in force (if applicable); (11) whether the order is solicited or unsolicited; (12) whether the account has a prior position in the security; (13) 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 (14) any special handling instructions.
-The Commission requested comment on whether there are any items of information that are required to be recorded and reported by existing audit trail rules, or to be provided to the SROs or the Commission upon request, that were not proposed but should have been included in the Rule. One commenter suggested that two data elements be added to aid regulators in detecting the original source of orders that violate laws or are involved in market manipulations.289 Specifically, this commenter recommended that the proposed Rule should capture the identity of the individual who originated the order (in addition to identifying the firm) and the system he or she used to originate the order.290 Another commenter questioned the need for information regarding whether an account has a prior position in a security.291 The commenter expressed skepticism about the value of knowing, in real time, whether the customer has a prior position in the security, since the length of time the position has been held would not be captured. This commenter also questioned how the Commission's requirement that the prior position in a security be reported would work in the situation where a client has multiple accounts but it is the first time the client has opened a position in one of the accounts.292 Another commenter provided specific information on the exact data elements that it could incorporate into the consolidated audit trail if it were chosen as the central processor under Rule 613.293
-The Commission considered the views of the commenter that questioned the value of knowing whether a customer has a prior position in a security. The Commission also considered the commenter's concern about potential reporting complications for clients with multiple accounts, as well as general comments urging the Commission to reduce the burdens of the Rule, and is adopting proposed Rule 613(j)(3) (renumbered as Rule 613(j)(7)) with modifications to delete certain data elements.
-After considering the commenters' views, and re-evaluating the necessity of requiring certain specific data elements, the Commission has determined not to require the locate identifier (if a short sale); whether the order is solicited or unsolicited; and whether the account has a prior position in the security. The Commission believes the consolidated audit trail can still achieve significant benefits without requiring the routine recording and reporting of these specific data elements to the central repository.294 While this information may be useful for certain investigations and market analyses, the Commission believes that this additional data could be readily obtained from a follow-up request to a broker-dealer if the other data required by proposed Rule 613(j)(3), particularly relating to the customer behind the order, is included in the consolidated audit trail. Thus, the Commission believes that it is unnecessary to require this additional data to be reported as a standard part of the consolidated audit trail. In effect, the Commission believes that the benefits of having these specific audit trail data elements are minimal. As such, the Commission does not believe the benefits to the Commission and the public to consider the detailed costs and benefits of such data elements justify the costs to SROs for including them in their NMS plan submission.
-In response to the commenter who recommended that the proposed Rule should capture the identity of the individual who originated the order (in addition to identifying the firm) and the system he or she used to originate the order,295 the Commission notes that Rule 613 defines "customer" as: "(i) the account holder(s) of the account at a registered broker-dealer originating the order; and (ii) any person from whom the broker-dealer is authorized to accept trading instructions for such account, if different from the account holder(s)."296 The Rule does not require the identification of the individual registered representative who placed the order.297 Further, the Commission does not believe that "the system he or she used to originate the order" is of significant enough regulatory value to require that information to be recorded and reported under Rule 613 at this time.
-(A) Order Type
-As proposed, the Rule would have required that members report the order type as an element of the material terms of an order. In the Proposing Release, the Commission explained that the proposed Rule does not specify the exact order types (e.g., market, limit, stop, pegged, stop limit) that could be reported under the Rule in recognition that order types may differ across markets and an order type with the same title may have a different meaning at different exchanges.298 The Commission also noted that markets are frequently creating new order types and eliminating existing order types. Thus, the Commission preliminarily believed that it would not be practical to include a list of order types in the proposed Rule as part of the required information to be reported to the central repository.
-The Commission received one comment in response to its request for comment on its proposed approach to handling order types. This commenter believed that the Commission did not think that order types were needed for the consolidated audit trail, and argued that this information is "essential for any attempts to use the order data to reconstruct the state of the limit order book at any point in time."299 The Commission agrees that information about an order's type is important and notes that the Rule, as proposed, did require order types to be reported.300 Thus, the Commission is adopting the Rule, as proposed, to require plan sponsors to include in the NMS plan submitted to the Commission for its consideration a requirement for SROs and members to report the order type as an element of the material terms of an order. The Rule, however, does not provide an exhaustive list of order types, as the Commission continues to believe that it is not feasible to do so in its Rule, for the reasons stated in the Proposing Release.301 Rather, the Commission believes the plan sponsors should be responsible for determining how to describe and categorize specific order types in the NMS plan or in the NMS plan's technical specifications, as there is more flexibility to amend such documents and the SROs would have the most familiarity with the variations among the order types on their markets. The Commission notes that specific order types may differ across markets, and even an order type with the same title may have a different meaning at different exchanges. Further, SROs regularly develop new order types to respond to changes in market structures and trading strategies, and any list of order types will likely need to be updated over time.
-(B) Special Handling Instructions
-The proposed Rule also would have required that that any special handling instructions be reported as part of the material terms of an order.302 The Commission specifically requested comment in the Proposing Release on whether the Rule should require, as part of the disclosure of special handling instructions, the disclosure of an individual algorithm that may be used by a member or customer to originate or execute an order, and, if so, how such an algorithm should be identified. The Commission received one comment noting the importance of requiring the special handling instructions to be included in the consolidated audit trail.303 This commenter believed that special handling instructions were important for reconstructing the limit order book.304 Regarding algorithms, commenters generally were not in favor of unique identifiers for algorithms.305 One commenter urged against requiring customer information at the level of "individual strategy, trading desk, or particular algorithm . . . ."306 Another commenter stated that the proposed rule should not require that unique customer identifiers be affixed to computer algorithms.307 This commenter pointed out that algorithms change daily, which would result in uncertainty about whether new identifiers are needed. Further, the commenter argued that firms would need to develop safeguards to ensure proprietary algorithms and trading strategies are not appropriated by competitors. This commenter suggested that, instead of requiring a unique customer identifier, the Commission could require that a "flag" be appended to orders generated by an algorithm.
-The Commission agrees with the commenter that supported the proposed requirement that special handling instructions be reported308 and is adopting this requirement as proposed.309 The Commission believes that such information will be useful to regulators in attempting to recreate an SRO's limit order book for market reconstructions. When performing market reconstructions, it is important for regulators not only to have information regarding what orders were on the book, but the conditions or special instructions attached to those orders. Such information can be of key importance in determining the amount of accessible liquidity at any price point and whether or not certain orders were entitled to be executed at various price levels.
-Additionally, the Commission considered the comments received regarding whether an individual algorithm should be reported and identified as part of an order's special handling instructions, and has determined not to adopt that requirement in recognition that algorithms change frequently and therefore it may be difficult to determine when and if new algorithm identifiers are necessary. The Commission also considered one commenter's concern regarding the proprietary nature of algorithms and the risk of competitors appropriating algorithms if they were required to be identified in the consolidated audit trail. However, the Commission notes that, because the disclosure of whether an order is a result of an algorithm that makes trading decisions based on a programmed investment strategy might be useful for the Commission and the SROs to sort or filter trade data to re-construct market events or to better evaluate potentially manipulative behavior or intent, the SROs may want to consider whether it would be feasible to include a "flag" or other indicator that would reveal whether an order was the result of an algorithmic trading calculation. Such a flag would not identify the actual algorithm used, but could instead indicate whether the order was the result of an algorithmic trade. Appending such a "flag" or indicator may aid regulatory authorities in their efforts to make preliminary assessments about market activity and better allow the SROs and the Commission to monitor the usage of algorithms over time. The Commission acknowledges that by not requiring that algorithms be recorded and reported to the central repository, the consolidated audit trail may not contain an audit trail data element that might prove useful to regulatory authorities. The Commission, however, believes that, should regulatory authorities need such information, regulators can submit a request for this information and obtain the information about whether the order was the result of an algorithm readily from the broker-dealer that handled the order.
-ii. Unique National Securities Exchange, National Securities Association and Broker-Dealer Identifiers
-The Commission proposed to require each member originating or receiving an order from a customer, and each national securities exchange, national securities association, and member that subsequently handles the order to report its own unique identifier to the central repository. Proposed Rule 613(c)(7)(i)(E) (renumbered as 613(c)(7)(i)(C)) would have provided that any member of an SRO, that originally receives from a customer or originates a principal order, shall collect and electronically report "the unique identifier of the broker-dealer receiving or originating the order." Similarly, proposed Rule 613(c)(7)(ii)(D) provided that the SRO or any member of such SRO that routes an order shall collect and electronically report "the unique identifier of the broker-dealer or national securities exchange routing the order." Proposed Rule 613(c)(7)(ii)(E) provided that the SRO or any member of such SRO routing an order shall collect and electronically report "the unique identifier of the broker-dealer or national securities exchange receiving the order." Proposed Rule 613(c)(7)(iii)(D) provided that the SRO or any member of such SRO that receives an order shall collect and electronically report "the unique identifier of the broker-dealer or national securities exchange receiving the order." Proposed Rule 613(c)(7)(iii)(E) provided that the SRO or any member of such SRO that receives an order shall collect and electronically report "the unique identifier of the broker-dealer or national securities exchange routing the order." Proposed Rule 613(c)(7)(iv)(E) required, for a modification or a cancellation of an order, the identity of the person giving such instruction. Proposed Rule 613(c)(7)(v)(F) provided that the SRO or any member of such SRO that executes an order in whole or part report "the unique identifier of the broker-dealer or national securities exchange executing the order." Further, the Commission proposed to require a member receiving an order from a customer to report, if applicable, "the unique identifier of the branch office and the registered representative receiving or originating the order."310
-Commenters generally supported the proposed use of unique identifiers for exchanges and broker-dealers.311 One commenter explained that cross-market surveillance efforts are unduly complicated if a single market participant has a different identifier for each market, and stated that the current market participant identifier ("MPID") system needed to be updated.312 This commenter, however, questioned whether it was necessary for branch office and registered representative information to be included in the consolidated audit trail, stating that the information would increase the amount of data reported to the consolidated audit trail, but would be useful only in certain circumstances.313 In another letter, the same commenter proposed to use Central Registration Depository ("CRD") numbers to uniquely identify broker-dealers.314 Under this system, the commenter suggested that SROs would be required to link the CRD numbers to unique MPIDs to create a cross-referenced database, so that data could be searched and retrieved at the firm level (by CRD number) or by the unique market center identifiers used by firms for each transaction on a specific market center.315 For activity not occurring on a national securities exchange, the commenter proposed continued reporting with MPIDs currently used for OATS reporting.316 Another commenter supported the use of MPIDs as unique identifiers for broker-dealers, suggesting that the MPIDs of the firms originating each order should be added to the trade report, but stated that only FINRA and the Commission should be allowed to access this information.317
-After considering commenters' views requesting additional flexibility with respect to the unique identifiers requirement for national securities exchanges, national securities associations, and members, the Commission has determined to adopt the Rule to require plan sponsors to include in the NMS plan submitted to the Commission for its consideration a requirement for such unique identifiers, substantially as proposed. The Commission, however, has made two technical changes to the Rule text from the proposal to: (1) add a defined term, "CAT-Reporter-ID," in adopted Rule 613(j)(2) to refer to these unique identifiers, and (2) expressly permit that a "code" be used that uniquely and consistently identifies the national securities exchange, national securities association, or member. Specifically, adopted Rule 613(j)(2) provides that "[t]he term CAT-Reporter-ID shall mean, with respect to each national securities exchange, national securities association, and member of a national securities exchange or national securities association, a code that uniquely and consistently identifies such person for purposes of providing data to the central repository."
-In response to the commenters that stated that firms' current MPIDs or CRD numbers may work as a viable unique broker-dealer identifier, the Commission believes it is appropriate to leave the decision of whether to specify an existing identifier, such as a firm's MPID or CRD number, or some other identifier such as one created under the unique legal entity identifier (LEI) standard under development by the International Standards Organization ("ISO") (ISO 17442),318 as the unique broker-dealer identifier, to the plan sponsors to assess and propose in the NMS plan. Therefore, while the adopted Rule continues to require the NMS plan to require these unique identifiers, the Rule does not specify which identifier to use, nor does the Rule specify the process for assigning unique broker-dealer identifiers.319 In this regard, the Commission expects the plan sponsors to establish a process, to be described in the NMS plan, by which every national securities exchange, and every member of a national securities exchange or national securities association, can obtain a CAT-Reporter-ID.
-The Commission also is adopting, substantially as proposed, rules requiring the NMS plan submitted to the Commission for its consideration to require each SRO and its members to report the unique identifier of the broker-dealer or SRO for each reportable event in the life of an order to the central repository, except to make two technical changes: to include the new defined term, "CAT-Reporter-ID" and to require the CAT-Reporter-ID or Customer-ID, if applicable, of the person giving a cancellation or modification instruction.320 Specifically, Rule 613(c)(7)(i)(C), as adopted, provides that any member of an SRO that originally receives from a customer or originates a principal order shall record and report "[t]he CAT-Reporter-ID of the broker-dealer receiving or originating the order." Rule 613(c)(7)(ii)(D) provides that any national securities exchange or any member of an SRO that routes an order shall record and report "[t]he CAT-Reporter-ID of the broker-dealer or national securities exchange routing the order." Rule 613(c)(7)(ii)(E) provides that any national securities exchange or member of an SRO that routes an order shall record and report "[t]he CAT-Reporter-ID of the broker-dealer, national securities exchange, or national securities association to which the order is being routed." Rule 613(c)(7)(iii)(D) provides that the SRO or any member of an SRO that receives a routed order shall record and report "[t]he CAT-Reporter-ID of the broker-dealer, national securities exchange, or national securities association receiving the order." Rule 613(c)(7)(iii)(E) provides that the SRO or any member of an SRO that receives a routed order shall record and report "[t]he CAT-Reporter-ID of the broker-dealer or national securities exchange routing the order." Rule 613(c)(7)(iv)(F) provides that the SRO or any member of an SRO that receives an instruction to modify or cancel an order shall record and report "[t]he CAT-Reporter-ID of the broker-dealer or Customer-ID of the person giving the modification or cancellation instruction." Rule 613(c)(7)(v)(F) provides that the national securities exchange or any member of an SRO that executes an order in whole or part shall record and report "[t]he CAT-Reporter-ID of the broker-dealer or national securities exchange executing the order." Rule 613(c)(7)(vi)(B) provides that, if an order is executed in whole or part, a member of an SRO shall record and report "[t]he CAT-Reporter-ID of the clearing broker or prime broker, if applicable."
-The Commission notes that CAT-Reporter-IDs will be reported to the central repository for each reportable event that the member or SRO is reporting to the central repository. The requirement to report CAT-Reporter-IDs in this manner will help ensure that regulators can determine which market participant took action with respect to an order at each reportable event. The Commission does not believe that the CAT-Reporter-ID of each member or market that touches an order needs to be tagged to and travel with an order for the life of the order, as long as the CAT-Reporter-ID of the member or exchange taking the action is reported to the central repository, and an order identifier(s) is reported at every reportable event of the order. The Commission believes the details of how these data are reported to the central repository, and the specific methodologies used by the central repository to assemble time-sequenced records of the full life-cycle of an order, is best left to the expertise of the SROs as they develop the NMS plan to be submitted to the Commission for its consideration. Instead, as adopted, Rule 613 requires that data in the central repository be made available to regulators in a linked fashion so that each order can be tracked from origination through modification, cancellation, or execution, and that the parties routing or receiving routes, or otherwise performing such actions, are identified for every reportable event.
-After considering the comment opposing the requirement to report to the central repository the unique identifier of the branch office and registered representative receiving or originating an order,321 the Commission has reconsidered the requirement in proposed Rule 613(c)(7)(i)(F) and is not adopting this requirement.322 While this audit trail data may be useful in the context of certain investigations or market analyses, upon further consideration, the Commission believes that this information need not be required by Rule 613 because it is not critical information to help identify the customer responsible for trading a security, nor to capturing the entire life of an order as it moves from origination to execution or cancellation. In addition, the Commission believes that a requirement that a unique identifier of the branch office and registered representative receiving or originating the order be reported may not provide enough information in an initial assessment of whether illegal or manipulative activity is occurring in the marketplace to warrant that this information be required in the audit trail created by Rule 613. Further, should regulators determine that the identity of the branch office and registered representative receiving or originating the order is needed to follow-up on a specific issue, they may request the information directly from the broker-dealer as broker-dealers are required to make and keep records identifying the registered representative that receives an order pursuant to Exchange Act Rules 17a-3(a)(6)(i)323 and 7a-4(b)(1).324 As such, the Commission does not believe the benefits of including this information in the consolidated audit trail justify the costs to SROs for requiring them to devise a methodology to identify the branch offices and registered representatives receiving or originating an order, and a mechanism for reporting this type of data to the central repository.
-iii. Unique Customer Identifier
-(A) Proposed Rule
-As proposed, Rule 613 would have required every SRO and broker-dealer to report a unique customer identifier to the central repository for any order originated by or received from such customer.325 Specifically, proposed Rule 613(c)(7)(i)(B) (renumbered as Rule 613(c)(7)(i)(A)) would have required that a national securities exchange, national securities association or any member of such exchange or association that originally receives or originates an order to collect and electronically report "a unique customer identifier for each customer." In the Proposing Release, the Commission noted that the unique customer identifier should remain constant for each customer, and have the same format, across all broker-dealers.326
-The Commission requested comment on possible ways to develop and implement unique customer identifiers. For example, the Commission solicited input about who should be responsible for generating the identifier; whether a unique customer identifier, together with the other information with respect to the customer that would be required to be provided under the proposed Rule, would be sufficient to identify individual customers; and whether there were any concerns about how the customer information would be protected. The Commission specifically requested comment on what steps should be taken to ensure that appropriate safeguards are implemented with respect to the submission of customer information, as well as the receipt, consolidation, and maintenance of such information in the central repository.
-(B) Comments on Proposed Rule 613(c)(7)(i)(B)
-The Commission received comments that supported the general notion that identifying customers in an audit trail would be beneficial for regulatory purposes.327 One commenter stated that a customer identifier on an order-by-order basis would "enhance significantly the audit trails of the markets."328 Similarly, another commenter agreed that identifying the customer would be useful to regulators for purposes of market surveillance and enforcement.329 Another commenter noted that it "fully supports more granularity in an order audit trail, such as obtaining high-level customer identity information (e.g., large trader identification), so that patterns of trading across multiple market centers can be quickly and readily identified, and [the commenter] agrees that the timeframe needed to identify customers should be greatly reduced; however, [the commenter] question[s] the utility of receiving the identity of both the beneficial owner and the person exercising the investment discretion, if different, for each and every order reported to the consolidated audit trail."330
-However, other commenters disagreed with the need for a unique customer identifier and the proposed Rule's requirements for reporting a unique customer identifier with every order. These commenters generally focused on the complexity and cost of the systems changes required to implement the unique customer identifier requirement for every customer;331 the complexity in the process for assigning unique customer identifiers;332 the alternative ways that a customer could be identified without requiring a unique customer identifier as proposed;333 and the concerns about how the privacy of customers might be compromised if every customer was assigned a unique customer identifier.334
-One commenter discussed the complexity and cost of the systems changes required to implement the unique customer identifier requirement, as set forth in the Rule.335 This commenter, who did not believe the Commission should require a unique customer identifier for every customer, noted the "complexity of the technology development work involved" in adding this identifier to the audit trail.336 The commenter added that the work required to update internal architecture to report customer identifiers would be "substantial" because broker-dealer systems and processes may access and maintain customer (and proprietary) identification information in different ways and at different levels of specificity, and that sales and trading systems would need to be modified to report the unique customer identifiers with every order. This commenter also noted the "significant costs" generally associated with requiring a unique customer identifier.337
-A few commenters also submitted their views on the complexity of the process for assigning unique customer identifiers.338 One commenter noted that the process for assigning unique customer identifiers that the Commission discussed in the Proposing Release (i.e., generating unique customer identifiers based on the input by a broker-dealer of a customer's social security number or tax identification number) would not create an administrative burden on individuals and non-broker-dealer entities.339 Another commenter, however, noted difficulties associated with implementing a centralized process for assigning, storing and utilizing standardized customer identifiers340 and another commenter characterized the "implementation of a centralized customer identification system" as a "monumental task."341 Another commenter believed that to satisfy the Rule's requirements, the industry would need to implement a completely new market-wide system to satisfy the unique customer identifier requirement, noting that this might not be feasible on the proposed timeline.342 Another commenter characterized the collection of a unique customer identifier as a "significant project unto itself."343 One commenter observed that given the large number of retail investors (some with multiple accounts), the complexities associated with tracking retail investors' accounts, and the relatively small and infrequent amount of trading by typical retail investors, the Rule should not require unique customer identifiers for every customer.344 Another commenter urged the Commission to specify whether the process required that a unique customer identifier be submitted at the time an order is originated or received and the procedure to be followed if an identifier is not available.345
-A few commenters suggested alternative ways to identify a customer, rather than through a unique customer identifier.346 One commenter suggested that customers could be identified by amending the current trade report.347 Another commenter believed that "sophisticated analysis could identify trading activity that might be coordinated, without using an account identifier, and that regulators could then perform further analysis to determine who traded by using [EBS] and other methods already available to the staff."348 Another commenter noted that a possible method for identifying customers could be by linking customer information in EBS to trading information in OATS.349 Another commenter noted that "[i]t makes economical sense to use the current OATS and COATS audit trails and to expand those audit trails to include additional customer information, thereby providing a more complete audit trail for regulatory oversight for post trade analysis rather than building another audit trail system."350
-Commenters also discussed the need for both a large trader identification number under Rule 13h-1 under the Exchange Act, the Commission's Rule implementing the large trader reporting system,351 and a unique customer identifier under Rule 613.352 One commenter stated that the Commission could alleviate some of the burdens of the proposed Rule, and increase the effectiveness of an identification system, if it required only large trader identification numbers to be reported instead of requiring a unique customer identifier for every customer.353 This commenter believed that the Commission and the SROs are unlikely to be interested in routine transactions by small investors and would much more likely need accurate information about the orders of large traders because they are most likely to engage in transactions large enough to impact prices.354 Another commenter noted that an alternative would be to only identify entities that have sponsored or direct access to market centers via a relationship with a sponsoring market participant and to identify customers whose trading activity would be required to be disclosed pursuant to Rule 13h-1.355
-Certain commenters discussed concerns about how the privacy of customers might be compromised if every customer was assigned a unique customer identifier.356 One commenter, noting the Commission's discussion in the Proposing Release that the unique customer identifiers could be based on a customer's social security number or taxpayer identification number, believed that the Commission's approach raises "serious privacy concerns."357 Another commenter noted that "there is a legitimate privacy concern with having the unique customer identifier available to the marketplace, and creating a means to protect that privacy would add tremendous incremental cost to the [consolidated audit trail]."358 One commenter questioned how long and at what level customer information would be encrypted,359 and another noted that "[t]he proposal needs to clarify who will have access to customer data and how confidentiality will be ensured."360
-(C) Adopted Rule
-(1) Need for a Unique Customer Identifier
-The Commission recognizes that the implementation of the unique customer identifier requirement may be complex and costly, and the reporting of a unique customer identifier will require SROs and their members to modify their systems to comply with the Rule's requirements. The Commission, however, believes that unique customer identifiers are vital to the effectiveness of the consolidated audit trail. The inclusion of unique customer identifiers should greatly facilitate the identification of the orders and actions attributable to particular customers and thus substantially enhance the efficiency and effectiveness of the regulatory oversight provided by the SROs and the Commission. Without the inclusion of unique customer identifiers, many of the benefits of a consolidated audit trail as described above in Section II.2. would not be achievable.
-For example, unique customer identifiers will make regulatory inquiries and investigations more efficient by eliminating delays resulting from the current need to send information requests to individual market participants in search of this key information, as well as reducing the burden on regulators and market participants of such requests.361 The identity of the customer is often necessary to tie together potential manipulative activities that occur across markets and through multiple accounts at various broker-dealers. Existing audit trails, however, do not identify the customer originating the order and thus do not allow SRO and Commission regulatory staff to quickly and reliably track a person's trading activity wherever it occurs in the U.S. securities markets. A unique customer identifier connected to each order will allow the SROs and the Commission to more quickly identify the customer that originated each order and therefore potentially more quickly and efficiently stop manipulative behavior through the submission of orders. In certain cases this might limit the losses of parties injured by malfeasance who currently may suffer losses during the weeks or months that it can currently take for regulators to obtain customer information through written requests for information.
-Further, unique customer identifiers will aid regulators in reconstructing broad-based market events. Specifically, having unique customer identifiers will aid regulators in determining how certain market participants behaved in response to market conditions and may even reveal the identity of the market participant(s) who caused or exacerbated a broad-based market event. More so, unique customer identifiers would enable regulators to disaggregate the market activity of different participants in ways that could help address many important questions related to equity and equity options market structure, ranging from more detailed analyses of the potential impacts of high frequency trading, to studies of market liquidity, to trend analyses of the trading costs and general efficiency by which investors use our public markets to acquire or dispose of their securities holdings.
-The Commission has considered commenters' concerns about the complexity of the process for creating and assigning unique customer identifiers and understands and acknowledges that the process of creating and assigning unique customer identifiers may not be simple and may result in additional costs to SROs and their members.362 The Commission also considered the commenters' views that there may be alternative ways to identify the customer responsible for orders, and that, in the view of some commenters, every individual customer need not be identified for purposes of an audit trail. As noted above, the Commission believes that the identification of each customer responsible for every order is critical to the effectiveness of a consolidated audit trail and does not agree that the commenters' alternative means of identifying a customer would be as effective as the method proposed by Rule 613. For example, the Commission considered the comment that customers could be identified by amending the trade report, but this approach would fail to identify customers associated with orders that are not executed.363 Additionally, account numbers are assigned by broker-dealers for their own customers only, and account numbers vary between broker-dealers. Thus, the identity of a customer from a specific account number would not be apparent to regulators without the time-consuming requests for information Rule 613 specifically is seeking to avoid. The use of unique customer identifiers would permit regulators to readily trace market activity by the same customer back to that unique customer identifier even if such market activity were affected across multiple accounts and broker-dealers.
-The Commission also considered the recommendations of some commenters that the consolidated audit trail should use the large trader identifier instead of a unique customer identifier.364 The Commission, however, does not believe that the commenters' approach will address the regulatory need to obtain information on and to identify the holders of accounts for all order activity in the market for NMS securities because the use of the large trader identifier alone would identify only those traders that self-report as "large traders" pursuant to Rule 13h-1 and are assigned a large trader unique identifier. Thus, under the commenters' suggested approach, only a very small portion of customers – the very largest traders in the market – would be assigned a unique identifier for purposes of the consolidated audit trail. Smaller traders, however, also can be perpetrators of illegal activity, or otherwise impact the market. Accordingly, the Commission believes that information on all customers is necessary to achieve the goal of Rule 613.
-Despite the wide and disparate array of views from commenters on the costs, complexities, and most efficient methodologies to generate and collect unique customer identifiers, the Commission believes that the potential benefits of including this information in the consolidated audit trail justify the costs to the SROs in requiring that they develop and include a detailed framework for unique customer identification as part of the NMS plan to be submitted for consideration by the Commission and the public. Therefore, the Commission is adopting the Rule substantially as proposed to provide that the NMS plan must require every member to report a unique customer identifier to the central repository upon origination or receipt of an order as required by Rule 613(c)(7)(i)(A). The Commission, however, is changing the term "unique customer identifier," as used in the proposed Rule, to the term "Customer-ID." Adopted Rule 613(j)(5) defines the term "Customer-ID" to mean, "with respect to a customer, a code that uniquely and consistently identifies such customer for purposes of providing data to the central repository."365
-Given the complexity and the various existing options for identifying a customer, the Commission believes that the plan sponsors, by engaging in a detailed process that combines their own expertise with that of other market participants, are in the best position to devise a methodology for, and estimate the costs of, including customer identifiers in the consolidated audit trail. Once the NMS plan was submitted, the Commission and the public would then be able to consider the details and costs of such a framework.
-The Commission notes that the Rule does not specify the process for assigning the unique customer identifiers, or the format for such identifiers; rather, the Rule contemplates that the plan sponsors have the flexibility to determine the precise way to assign or "code" these identifiers. In this regard, the Commission expects the plan sponsors to establish a process by which every broker-dealer can, in a cost-effective manner, obtain a unique customer identifier, or Customer-ID, for each of their customer(s).366 The Commission also expects the plan sponsors to establish a process by which unique customer identifiers are reported to the central repository, and how this information is linked to the name and address of customers as stored in the central repository. The Commission further notes that Rule 613 does not specify that unique customer identifiers must be attached to every reportable event as orders are routed from one market or broker-dealer to another, or that these identifiers are reported at the same time and fashion as other customer-identifying information. Rather, the Commission is relying on the SROs, and other market participants,367 to develop a proposal that maximizes efficiency and security, and that data in the central repository be made available to regulators in a linked fashion so that each order, and all subsequent reportable events, can be readily traced back to one or more customers through their unique identifiers.
-In response to the commenter that questioned what should happen if a unique customer identifier was not available,368 the Commission notes that the Rule does not set out a process for addressing a situation where a unique customer identifier is not available to a broker-dealer and/or customer. Instead, the Commission believes that the plan sponsors are in the best position to address this situation as they develop the overall process for assigning unique customer identifiers. In response to the comment that requested the Commission specify whether a unique customer identifier is required to be reported at the time an order is originated or received,369 the Commission notes that Rule 613(c)(7)(i)(A) requires that the NMS plan require that this information be recorded contemporaneously with the reportable event, but permits the reporting of the identifier by 8: 00 a.m. Eastern Time on the trading day following the day such information has been recorded.370 In addition, in response to the commenter that believed that the consolidated audit trail should identify market participants with direct or sponsored access to markets,371 the Commission notes that under the Rule, to assure the Commission and the SROs of an accurate and complete audit trail for every action that every market participant takes with respect to an order, the sponsored party will be assigned a Customer-ID and the sponsoring broker-dealer will be assigned a CAT-Reporter ID under Rule 613.
-The Commission also considered the privacy and security concerns that commenters raised with respect to the use of Customer-IDs.372 In response to these comments, the Commission is revising proposed Rule 613, as discussed in more detail in Section III.B.2.e. below, to include additional mechanisms to safeguard the privacy and confidentiality of the audit trail data, including the Customer-ID, in large part to address the privacy concerns raised by commenters.373 In response to the commenter that questioned when and at what level customer information would be encrypted,374 the Commission notes that, while Rule 613 does not explicitly require that this information be encrypted, the Rule contains several safeguards to ensure the privacy and confidentiality of the audit trail data. Specifically, adopted Rule 613(e)(4) requires the NMS plan to include policies and procedures, including standards, to be used by the plan processor to ensure the security and confidentiality of all information reported to the central repository. In addition, one of the considerations the NMS plan must address is how the security and confidentiality of all information, including customer information, reported to the central repository, will be ensured.375 Based on these provisions, the Commission believes that plan sponsors would need to make sure customer information is protected, and the plan sponsors could require such data to be encrypted.
-Additionally, the Commission believes that privacy concerns also could be mitigated if the plan sponsors determine, as permitted by Rule 613, that the unique customer identifiers not travel with the order, and instead be reported to the central repository only upon the receipt or origination of an order. Therefore, if the plan sponsors make this decision, the SROs and their members will not be able to use the unique customer identifier to track the identity of a customer(s) or a customer's order flow.376 While the unique customer identifier will be linked to information that is sufficient to identify a customer (e.g., the name and address of the customer) and customer account information377 at the central repository, this information will be accessible only by regulators for regulatory purposes.378 The Commission also notes that the plan sponsors could determine not to require that a customer's social security number or tax identification number be used as a customer's unique identifier to the extent they believe that there are privacy and confidentiality concerns.
-(2) Definition of "Customer"
-As proposed, Rule 613(j)(1) (renumbered as Rule 613(j)(3)) defined "customer" as "[t]he beneficial owner(s) of the account originating the order; and [t]he person exercising investment discretion for the account originating the order, if different from the beneficial owner(s)." The Commission received two comments regarding the inclusion of beneficial owners in the definition of customer. One commenter questioned the use of a unique customer identifier for both a beneficial owner of an account and the person exercising investment discretion, if different, and noted that if a trade comes into question, the person exercising investment discretion, not the beneficial owner, likely will be the "first person of interest in any type of review or investigation of such trading activity."379 Another commenter requested further clarity regarding the definition of "customer" for purposes of Rule 613, and suggested that the Commission should define "beneficial owner" to be sure this term is applied correctly.380 This commenter specifically stated that "[t]he SEC should also provide a definition for the terms 'beneficial owner' and 'customer' to eliminate any doubts as to whom these labels apply. For example, is the 'customer' the entity directing the trade or the beneficial owner of the account?" and added that, "for registered investment advisers, the unique customer identifier should be associated with the investment adviser rather than the underlying beneficial owner. Frequently, investment advisers aggregate orders for multiple beneficial owners in 'bulk' orders that are routed together and allocated on an average-priced basis to ensure best execution."381 In response to commenters' concerns about the use of the term "beneficial owner," the Commission is revising Rule 613(j)(1), as proposed (renumbered as Rule 613(j)(3)), to state that "[t]he term 'customer' shall mean: (i) [t]he account holder(s) of the account at a registered broker-dealer originating the order; and (ii) [a]ny person from whom the broker-dealer is authorized to accept trading instructions for such account, if different from the account holder(s)." The Commission believes that the revised Rule will provide it with the customer information required to achieve the objectives of the consolidated audit trail.382
-In adopting this revised definition, the Commission is clarifying its intent that, with respect to the "account holder" reference under Rule 613(j)(3), the NMS plan submitted to the Commission for its consideration must require broker-dealers to capture information on only the individuals or entities that currently are required to be recorded in the books and records of the broker-dealer pursuant to Rule 17a-3(a)(9) under the Exchange Act.383 Because this provision does not require broker-dealers to obtain information about their account holders beyond what they are required to obtain today, the Commission believes the modification to the proposed Rule is appropriate because it will reduce the proposed Rule's burden on broker-dealers in recording and reporting information about a "customer," as that term will be defined under Rule 613(j)(3). The Commission notes that, under the Rule, as adopted, for joint accounts – where two individuals are required to provide information under Rule 17a-3 of the Exchange Act for one account – information for both persons listed on the joint account would be recorded and reported under Rule 613.384
-The Commission also believes that it is important to capture the person that has authority to give trading instructions to a broker-dealer for an account, if different from the account holder, because such person likely will be of interest in a review or investigation of activity in such account. Thus, the Commission is modifying the proposed Rule to clarify its intent that under Rule 613 the NMS plan also must capture, in the definition of customer, "[a]ny person from whom the broker-dealer is authorized to accept trading instructions, if different from the account holder(s)."385 Knowing the identity of the person who is authorized to give the broker-dealer trading instructions for an account, whether the account holder or an adviser or other third party, is a vital component in the investigative process. Further, when investigating violations of the federal securities laws, it is important to promptly identify all potentially relevant parties who may have made trading or investment decisions, which could include both the person authorized to give the broker-dealer trading instructions for such account and the account holder.386
-Pursuant to the revised definition of "customer" under adopted Rule 613, for example, if an order is entered to buy or sell securities for the account of an investment company or other pooled investment vehicle (a "fund"), the Rule will capture, in the definition of customer, the fund itself or, if the account at the broker-dealer is held only in the name of the fund's investment adviser from whom the broker-dealer is authorized to accept trading instructions, the Rule will capture the investment adviser.387 If the account at the broker-dealer is held in the name of the fund itself, the Rule will capture both the name of the fund (pursuant to Rule 613(j)(3)(i)), as well as the name of the fund's investment adviser from whom the broker-dealer is authorized to accept trading instructions (pursuant to Rule 613(j)(3)(ii)). In addition, if an adviser enters an order on behalf of clients that each maintain separate accounts at the broker-dealer originating the order, using those accounts, the Rule would capture both the adviser – as the person providing trading instructions to the broker-dealer (pursuant to Rule 613(j)(3)(ii)) – and the clients, who are the account holders at the broker-dealer (pursuant to Rule 613(j)(3)(i)). If an adviser instead enters an order to buy or sell securities using its own account held at the broker-dealer originating the order, the Rule would capture the adviser (pursuant to Rule 613(j)(3)(i)) but would only capture any client accounts to which the adviser allocates executed trades (pursuant to Rule 613(c)(7)(vi)) if those client accounts were held separately at the same broker-dealer as well.
-Furthermore, in cases where multiple individuals in the same trading firm transact through a single account maintained at a broker-dealer in the name of that trading firm, the Rule will require the NMS plan to require recording and reporting of the Customer-ID of the trading firm associated with that account, and not the Customer-IDs of the individual traders who had placed the orders.388 The Commission understands that in some cases broker-dealers may have knowledge of the individual traders transacting within the same firm-wide account, and may even provide reports to the firm holding the account that summarizes trade activity according to individual trader. Because such information is not captured by the Rule, but may be useful in informing regulators about the potential manipulative activities, the SROs may wish to consider how such information might be incorporated into the consolidated audit trail in the future.
-The Commission is also modifying a related provision of the Rule, Rule 613(c)(7)(i)(A), to reflect that more than one Customer-ID must be provided upon original receipt or origination of an order if the account holder and the person authorized to give the broker-dealer trading instructions for such account are different or if more than one person is an account holder for the account (such as, for example, joint account holders). Specifically, Rule 613(c)(7)(i)(A) provides that "Customer-ID(s)" (i.e., multiple Customer-IDs) must be provided for each customer, if that is applicable. In addition, the Commission notes that every "customer," as defined by Rule 613(j)(3) will be assigned a Customer-ID; thus, two Customer-IDs maybe associated with one order under the Rule.
-iv. Unique Order Identifier
-As proposed, the Rule would have required the NMS plan to require each member of an exchange or FINRA to attach, to each order received or originated by the member, a unique order identifier that would be reported to the central repository and that would remain with that order throughout its life, including routing, modification, execution, or cancellation. Specifically, proposed Rule 613(c)(7)(i)(D) (renumbered as Rule 613(c)(7)(i)(B)) would have provided that the national market system plan shall require each national securities exchange, national securities association, and any member of such exchange or association to collect and electronically provide to a central repository details for each order and each reportable event, including, but not limited to, "a unique identifier that will attach to the order at the time the order is received or originated by the member and remain with the order through the process of routing, modification, cancellation, and execution (in whole or in part)." In the Proposing Release, the Commission stated that the use of such an identifier would allow the SROs and the Commission to efficiently link all events in the life of an order and help create a complete audit trail across all markets and broker-dealers that handle the order.389 Proposed Rules 613(c)(7)(ii)(A), 613(c)(7)(iii)(A), and 613(c)(7)(v)(A) would have required the reporting of a unique order identifier to the central repository for the reportable events of routing and execution. The Commission did not propose to mandate the format of such an identifier or how the identifier would be generated.
-The Commission requested comment on whether a unique order identifier that would remain with the order for its life would be necessary or useful for an effective consolidated audit trail. The Commission also specifically requested comment on, among other things, the feasibility and merits of its proposed approach for attaching a unique order identifier to an order, as well as on how multiple "child" orders that may result if the original "parent" order is subsequently broken up, or an aggregation of multiple original orders into a single order, should be addressed.
-Several commenters expressed opinions on the proposed unique order identifier requirement, with some noting that the Commission's proposal imposed "significant" burdens or challenges on market participants, and others offering alternatives to the Commission's approach to identifying orders.390 For example, some commenters suggested that the Rule permit the approach used for OATS reporting, in which the broker-dealer initiating or receiving an order would generate its own order identifier, but pass on a separate routing identifier to the entity to which it routes the order, which would generate its own order identifier, but retain and report that routing identifier as well, so that information about the order can be linked together as it is passed from venue to venue.391 One of these commenters also believed that the OATS approach would avoid certain complexities that could occur with a unique order identifier, such as when the original order is broken up into multiple "child" orders.392 In a subsequent comment letter, the commenter stated that it could require two new order event types that would allow customer orders handled on a riskless principal or agency basis to be linked to the related representative orders.393 Another of the commenters suggested that "the adopted CAT filing should require that an order be tracked through its lifecycle and [the Commission should] leave the technical details to [a] requirements analysis."394
-Another commenter was concerned that, if the originating firm's or customer's name was used as part of the unique order identifier, this could create "potential privacy information risks as every new destination (both internally across information barriers within a firm and externally across broker-dealers) would see where an order originated."395 Similarly, a third commenter supported the OATS approach of linking a series of separate order identifiers in part because it believed that, if a unique identifier were to pass from firm-to-firm, there was a risk that information about the origin of an order might be inferred.396 Yet another commenter recommended that the Commission standardize how the order identifier should be structured to ensure consistent reporting between firms, instead of leaving this decision to the plan sponsors.397
-The Commission has considered the comments received regarding the requirement that the NMS plan mandate a unique order identifier, and is adopting Rule 613 with significant modifications398 that provide more flexibility for the SROs, as the plan sponsors, to determine whether the NMS plan will require a single unique order identifier or a "series of order identifiers." Specifically, the Rule, as adopted, requires that every order have a "CAT-Order-ID," defined as "a unique order identifier or series of unique order identifiers that allows the central repository to efficiently and accurately link all reportable events for an order, and all orders that result from the aggregation or disaggregation of the order."399
-The Commission has modified the Rule from the proposal so that the SROs can draw upon their own expertise, as well as those of other market participants, in developing the most accurate and efficient methodology for tracking an order through its life. Thus, the SROs may submit an NMS plan in which they require a single unique order ID to travel with each originating order; the SROs may submit an NMS plan in which, as suggested by a number of commenters, a series of order IDs, each generated by different market participants, is reported to the central repository in a manner that allows for the accurate linking of reportable events; or the SROs may submit an NMS plan based on any other methodology that meets the requirements of the Rule.
-The Commission expects that the details of the methodology proposed by the SROs in the NMS plan will, in part, be based on how the generation and reporting of order identifiers would interact with other technical details involving order tracking in the consolidated audit trail, such as the potential for multiple orders to be aggregated, routed, and disaggregated. However, though the Commission is not prescribing a particular methodology, the Rule does require that SROs take into account a number of considerations, such as accuracy and cost, in designing their methodology.400
-The Commission notes that, with this modification, a wider array of possible solutions is now available to the SROs as they develop the NMS plan to be submitted to the Commission for its consideration, including those that may better accommodate the infrastructure of existing audit trails and thereby potentially, and possibly significantly, reduce implementation burdens. As indicated above, several commenters suggested that the Rule accommodate the linked order identifier approach, currently used by OATS.401 However, the Commission also notes that, though the adopted Rule could accommodate such an approach, there historically have been limitations on the accuracy and reliability of linking orders in OATS.402 It will therefore be very important for the NMS plan to demonstrate how the approach it has selected will ensure that information about all reporting events pertaining to an order will be efficiently and accurately linked together in a manner that allows regulators efficient access to a complete order audit trail.403 As discussed below, the reliability, accuracy, and confidentiality of the data reported to and maintained by the central repository, as well as the method by which the data in the central repository can be accessed by regulators, are considerations for the Commission in evaluating the NMS plan.404
-The Commission emphasizes that, under the adopted Rule, regardless of the specific method chosen by the SROs, all orders reported to the central repository must be made available to regulators in a uniform electronic format and in a form in which all events pertaining to the same originating order are linked together in a manner that ensures timely and accurate retrieval of the information for all reportable events for that order.405 The Commission believes the consolidated audit trail will still achieve significant benefits with this modification.
-The Commission recognizes the complexities of order routing in today's markets, including, as noted by a commenter,406 the frequent splitting of larger orders into numerous "child" orders or the bundling of smaller orders into one larger order. The Commission believes, however, that since, in today's complex markets, orders are currently and routinely aggregated and disaggregated, practical solutions to record such orders can be developed by the plan sponsors to ensure they are accurately and efficiently tracked through a variety of aggregation and disaggregation events.
-With regard to the concern expressed by a commenter that the use of an order identifier(s), as required by Rule 613, could provide the ability to deduce the origin of an order, thereby revealing confidential trading strategies or raising privacy concerns,407 the Commission notes that this commenter assumed that a unique order identifier "would very likely require members to include the originating firm's or customer's name as part of the identifier."408 The Commission believes, however, that the SROs will be able to devise a way to assign order identifiers – through random number sequences or otherwise – that would protect the identity of broker-dealers and their customers from disclosure to persons other than authorized regulatory personnel. The Commission also notes that, as discussed in Section III.B.2.e. infra, the adopted Rule requires the NMS plan submitted to the Commission for its consideration to incorporate a variety of policies and procedures to ensure the security and confidentiality of all information reported to the central repository.
-Furthermore, because the Rule requires the SROs to discuss the details of each aspect of the NMS plan submitted to the Commission for its consideration, the Commission and the public will be able to consider how well the methodology the SROs developed to link reportable events for the same order meets the considerations of accuracy and reliability, as well as those of security and confidentiality. The Commission will then be able to use this information in determining whether to approve the NMS plan submitted.
-v. Time Stamp
-The proposed Rule would have required SROs and their members to report the date and time, to the millisecond, that an order was originated or received, routed out, and received upon being routed, modified, cancelled, and executed.409 Specifically, proposed Rules 613(c)(7)(i)(H) (renumbered as 613(c)(7)(i)(E)), 613(c)(7)(ii)(C), 613(c)(7)(iii)(C), 613(c)(7)(iv)(B) (renumbered as 613(c)(7)(iv)(C)), and 613(c)(7)(v)(C) provided that the "time of order receipt or origination (in milliseconds)" would be recorded for every order originated or received, routed, modified, cancelled or executed, by a broker-dealer or SRO.
-Several commenters expressed opinions on the time stamp requirement. One commenter believed a millisecond standard was not precise enough, explaining that many exchanges currently execute orders in less than a millisecond.410 This commenter explained that, to detect the manipulative or fraudulent behavior of high frequency traders, it is necessary that time stamps be accurate to a level more detailed than the speed at which trades are executed; otherwise, it would not be possible to determine the time sequence in which trades occurred. The commenter suggested that reports from execution venues (e.g., exchanges, ATSs, dark pools, and large internalizers) should be required to be accurate to 0.01 milliseconds.411 This commenter also suggested that a more liberal time stamp standard of one second might be more appropriate for low-volume broker-dealers.412 Another commenter, however, expressed concern about the proposed millisecond time stamp requirement, explaining that, "[a]lthough firm systems tend to capture time stamps in milliseconds, reporting in milliseconds would require changes to internal systems given that existing audit trails such as OATS require reporting of time stamps accurate only to the second."413 Another commenter believed that, because computers have a certain rate of error when keeping time ("time drift"), it is difficult to sequence orders based on millisecond time stamps.414 As a result, according to this commenter, there is "no real value in requiring data to this level of specificity [based on milliseconds], especially if the goal of time stamping is to sequence the lifecycle of a single order as it moves from origination to execution."415
-The Commission has considered the comments regarding the precision of the proposed time stamp requirement for the consolidated audit trail and is adopting the millisecond time stamp requirement with modifications from the proposal.416 As adopted, the Rule provides that the NMS plan submitted shall require the time stamps as set forth in Rule 613(d)(3).417 Rule 613(d)(3) provides that the NMS plan must require each SRO and its members to "[u]tilize the time stamps required by paragraph (c)(7) of this section, with at minimum the granularity set forth in any national market system plan submitted pursuant to this section, which shall reflect current industry standards and be at least to the millisecond." Rule 613(d)(3) also provides that, "[t]o the extent that the relevant order handling and execution systems of any national securities exchange, national securities association, or member of such exchange or association utilize time stamps in increments finer than the minimum required by the national market system plan, such plan shall require such national securities exchange, national securities association, or member to utilize time stamps in such finer increments when providing data to the central repository, so that all reportable events reported to the central repository by any national securities exchange, national securities association, or member can be accurately sequenced." Rule 613(d)(3) further provides that "[t]he national market system plan shall require the sponsors of the national market system plan to annually evaluate whether industry standards have evolved such that the required time stamp standard should be in finer increments."
-The Commission notes that SIPs currently support millisecond time stamps418 and other entities in the securities industry currently conduct business in millisecond increments or finer.419 The Commission believes that, given the speed with which the industry currently handles orders and executes trades, it is important that the consolidated audit trail utilize a time stamp that will enable regulators to better determine the order in which reportable events occur. The entry time of orders can be critical to enforcement cases. For example, the timing between order origination and order entry is important in investigating possible market abuse violations, such as trading ahead of a customer order. In general, determining whether a series of orders rapidly entered by a particular market participant is manipulative or otherwise violates SRO rules or federal securities laws, otherwise being able to reconstruct market activity, or performing other detailed analyses, requires the audit trail to sequence each order accurately. The Commission believes that, for many types of common market activities that operate at the level of milliseconds or less, time stamps in increments greater than a millisecond would not allow this sequencing with any reasonable degree of reliability.
-In response to the comment that a millisecond standard is not sufficiently precise, as many exchanges currently execute orders in less than a millisecond,420 adopted Rule 613(d)(3) provides that the NMS plan must require that, to the extent that the order handling and execution systems of any SRO or broker-dealer utilize time stamps in increments finer than the minimum required by the NMS plan time stamps, such SRO or member must use time stamps in such finer increments when reporting data to the central repository, so that reportable events reported to the central repository by any SRO or member can be accurately sequenced. The Commission believes this approach will improve the accuracy of records with respect to the sequencing of events that occur very rapidly, especially with respect to those market participants that have elected to use time stamps in increments finer than a millisecond.
-The Commission recognizes, as a commenter noted,421 that computers have a certain rate of deviation when keeping time. The requirement that clocks be synchronized within a level of granularity to be specified in the NMS plan422 is designed to ensure that time drift does not exceed a defined level of deviation. However, the Commission believes that time stamps reported with a millisecond or finer granularity would still provide significant benefits even, contrary to one commenter's assertion,423 if the time drift between systems is larger than a millisecond. This is because such time stamps would still allow an accurate sequencing of reportable events as may commonly occur within in a single system, tied to a single clock, at levels of a millisecond or finer (e.g., high-frequency trading algorithms). Any drift of such a system's clock relative to the clocks of other systems may of course hinder the time-sequencing of cross-system events, but it would not preclude the ability of regulators from performing a detailed, accurate time-sequenced analysis of all the orders, cancellations, modifications, and executions performed by the specific system of interest.424 In this regard, the Rule is analogous to the current requirements for OATS reporting: FINRA requires clocks to be synchronized to the second, and requires time stamps to be reported to FINRA in seconds, unless those time stamps are captured by the FINRA member in milliseconds, in which case they must reported to FINRA in milliseconds (notwithstanding the clock sync remaining at a second).425
-The Commission acknowledges that changes (with their associated costs) might be required to internal broker-dealer systems to comply with a millisecond time stamp requirement. However, given the benefits outlined above, and the apparent widespread use of millisecond time stamps in the industry today,426 the Commission believes the cost of requiring the SROs to develop a plan that provides for millisecond time stamps, and to discuss the costs and benefits of the specific solution chosen, is justified.
-The Commission also acknowledges that broker-dealers who presently report time stamps to OATS in millisecond increments, but whose systems direct and capture their order activity in finer time increments, could incur costs associated with these time stamps being reported to the central repository with the same granularity at which they are recorded by the broker-dealers.427 The Commission recognizes that there may be alternatives to reporting events in finer than millisecond increments that enable the central repository to use a different method for accurately time-sequencing sub-millisecond events originating from within a system or systems on a single clock. Therefore, in developing the NMS plan to be submitted to the Commission for its consideration, if the SROs identify one or more such alternatives, the Commission believes that they should address such alternatives in the NMS plan,428 how such alternatives (i.e., an alternative to reporting in finer than millisecond increments) would ensure that reportable events may be accurately time-sequenced at the sub-millisecond level, and the costs associated with such alternatives both on their own terms and relative to a requirement to report events in the same sub-millisecond time stamp as used by a broker-dealer for directing and capturing orders.429
-The Commission also notes that, because millisecond time stamps may become inadequate to investigate trading as technology evolves and trading speeds increase, the adopted Rule requires that the NMS plan submitted to the Commission for its consideration require the plan sponsors to annually evaluate whether industry standards have evolved such that a finer increment time stamp is appropriate. As this approach is tied to the then-current industry standard used to assess whether to shorten the future time stamp increment, the Commission also believes that this approach helps assure that the time stamps in the consolidated audit trail will be in line with technological developments. Should the industry standard move to a finer time standard, the plan sponsors could modify the minimum standard required by the NMS plan by submitting an amendment to the NMS plan under Rule 608 of Regulation NMS. Such an amendment would need to be considered and would be subject to approval by the Commission, as well as subject to public notice and comment.430
-vi. Additional Routing Data Elements
-Proposed Rules 613(c)(7)(ii) and (iii) would have required that certain additional information be collected and reported specifically to allow regulators to track the life of an order through the routing process. The Commission requested comment as to whether information regarding the routing of orders would be necessary or useful for an effective consolidated audit trail, and asked if any information, in addition to the data elements proposed, should be included in the consolidated audit trail relating to routing.
-One commenter noted that the proposed Rule would capture the routing of an order internally within a broker-dealer, but not the routing of an order internally within an exchange from one execution system to another.431 This commenter also noted that, as proposed, the Rule would not require an SRO or member to report information indicating that an order was "flashed" or otherwise displayed in a "step-up" mechanism.432 The commenter believed that this information would be important for the consolidated audit trail to capture.433
-The Commission believes that it is important to capture the routing of an order internally within a broker-dealer to, for example, evaluate best execution practices.434 Capturing the time at which a broker-dealer received a customer's order and the time that such order was executed can help determine if the broker-dealer delayed acting on its customer's order. The time at which an order was routed can affect the evaluation of whether the broker-dealer fulfilled its best execution obligations, and, thus, the Commission believes that this internal broker-dealer routing information should be captured by Rule 613. The Commission, however, does not believe that data regarding order processing (i.e., management of an order) within exchange systems is as useful as data regarding internal routing within a broker-dealer435 because, for example, unlike broker-dealers, exchanges do not have best execution obligations. Further, any issues with an SRO's internal processing would occur at a single venue – the SRO – and, thus, there could be direct follow-up with the SRO. Additionally, the Commission notes that the consolidated audit trail will not collect information indicating whether orders were flashed or displayed in a "step-up" mechanism as it concerns an exchange's internal processing and dissemination to its members of an order in the instance when the exchange cannot execute the order because the exchange does not have any available trading interest at the NBBO (depending on the side of the order).436 Orders that are flashed or displayed through a "step-up" mechanism are not executable because they are displayed only to members of an exchange as an indication of a broker-dealer's interest. The Commission believes it is appropriate not to require the reporting of these flashed or "stepped-up" orders to the central repository because, as noted above, the Commission believes that the tracing of processes within an exchange is not as material to regulators as the routing of orders between markets. Further, as stated, SROs do not have the same legal obligations with regard to handling customer orders as broker-dealers; therefore, the Commission does not believe it is necessary, at this time, to require the consolidated audit trail to track an SRO's internal processing of orders.
-The Commission has considered the comments related to the data that is required to be recorded and reported when an order is routed and is adopting Rules 613(c)(7)(ii) and (iii) substantially as proposed.437 The Commission notes that the Rule requires that the NMS plan require the broker-dealer routing an order and the broker-dealer receiving a routed order – both actions that are defined as "reportable events" under Rule 613 – record and report the CAT-Reporter-ID of the broker-dealer routing the order and the CAT-Reporter-ID of the broker-dealer receiving the routed order. The Commission believes the requirement to report this information on both the routing and receiving end of a route is not duplicative but, rather, is useful. Specifically, information regarding when a broker-dealer received a routed order could prove useful in an investigation of allegations of best execution violations to see if, for example, there were delays in executing an order that could have been executed earlier. In addition, if a market participant is required to report when it receives an order, regulators could solely rely on information gathered directly from that market participant when examining or investigating the market participant. For example, if a regulator needs to investigate a delay between the time a market participant received an order and the time the market participant acted on the order, under Rule 613, as adopted, the regulator could use information recorded and reported by the market participant itself, rather than rely on information about the receipt and action taken on the order that would be provided by a third party. Information from a third party may be less accurate in general and may not accurately reflect events to the extent there are latencies in order transmission. In addition, the Commission relies on data such as that which would be recorded under Rule 613(c)(7)(ii) and (iii) to improve its understanding of how markets operate and evolve, including with respect to the development of new trading practices, the reconstruction of atypical or novel market events, and the implications of new markets or market rules. For these reasons, the Commission believes that it is important to have both the routing broker-dealer and the receiving broker-dealer report their CAT-Reporter-IDs to the central repository, and that such information could aid regulatory authorities when analyzing the trades of market participants.438
-To reflect terms that have been modified elsewhere in the Rule as adopted, the terms "unique order identifier" and "unique identifier" in Rule 613(c)(7)(ii) and (iii) have been replaced with the terms "CAT-Order-ID" and "CAT-Reporter-ID." In addition, Rule 613(c)(7)(ii) and (iii) now reflect the new time stamp requirement contained in Rule 613(d)(3). Specifically, Rules 613(c)(7)(ii)(C) and 613(c)(7)(iii)(C) provide that the time at which an order is routed or received must be recorded and reported pursuant to Rule 613(d)(3), rather than simply in milliseconds as proposed. The Commission believes these conforming changes are appropriate to reflect the revised terms in the adopted Rule.
-vii. Additional Modification, Cancellation, or Execution Data Elements
-In addition to the data elements discussed above, proposed Rules 613(c)(7)(iv) and (v) would have required that certain information be collected and provided specifically to allow regulators to track the life of an order through modification, cancellation, or execution. The Commission requested comment as to whether information required under the Rule as proposed would be sufficient to create a complete and accurate consolidated audit trail, and asked if any information, in addition to the data elements proposed, should be included in the consolidated audit trail relating to modifications, cancellations, or executions.
-In response, one commenter noted that broker-dealer order management systems may differ in their treatment of order modifications and cancellations, as some, for example, may capture or report only modified data elements, and not necessarily all of the elements of a modified order.439 The commenter recommended that the consolidated audit trail accommodate such differences, and further suggested requiring only the submission of the order identifier for a cancelled order, not the order's other data elements.440 Another commenter believed that, "[a]s in the case of the current OATS system, execution data provided to the consolidated audit trail should identify where the trade was publicly reported and have a common identifier that links the audit trail execution reports for the buy and sell orders to the public trade report."441
-After consideration of the comments regarding the specific audit trail data required for orders that are modified, cancelled, or executed, the Commission is adopting Rules 613(c)(7)(iv) and (v) substantially as proposed, with a modification to require that the NMS plan include a requirement that the CAT-Order-ID for such orders also be recorded and reported to the central repository. This modification is designed to ensure that an order identifier be reported for orders that have been modified or cancelled. The Commission believes that the order identifier is a critical piece of information that will efficiently link an order across markets. Adopted Rules 613(c)(7)(iv) and (v) will also require that the NMS plan submitted to the Commission for its consideration require the recording and reporting of the CAT-Reporter-ID of the broker-dealer or Customer-ID of the person giving the modification or cancellation instruction to reflect the new terminology of the adopted Rule. In addition, Rules 613(c)(7)(iv) and (v) reflect the new time stamp requirement contained in Rule 613(d)(3), as adopted. Specifically, Rules 613(c)(7)(iv)(C) and 613(c)(7)(v)(C) provide that the time at which an order is modified, cancelled, or executed must be recorded and reported pursuant to Rule 613(d)(3), rather than simply in milliseconds as proposed.
-The Commission believes it is necessary to require the NMS plan to require the information under Rule 613(c)(7)(iv) and (v) for each order and reportable event because it will assist the Commission and SROs in identifying all changes made to an order (including an execution) and those market participants responsible for the changes (or execution). The Commission believes this information, in combination with the proposed information pertaining to order receipt or origination, will provide regulators with a comprehensive view of all material stages and participants in the life of an order. Among other things, this order information should help regulators investigate suspicious trading activity in a more efficient manner than is currently possible. Regulators will have access to information identifying the customer behind the order and will also see how a customer's order is handled across markets. This data also will improve regulators' understanding of how markets operate and evolve, including with respect to the development of new trading practices, the reconstruction of atypical or novel market events, and the implications of new markets or market rules. In addition, the Commission believes that most of the data proposed to be recorded and reported by the Rule for order modification, cancellation, and execution is data that most broker-dealers already generate in the course of handling an order pursuant to the existing audit trail requirements of several SROs.442
-The Commission notes that regulatory staff at an SRO or the Commission could use execution information required under Rule 613(c)(7)(v), which will be consolidated with the other audit trail information required under Rule 613 to, for example, detect patterns of reported and unreported transactions effected by a broker-dealer in a particular security by comparing the data reported to the central repository regarding an execution with information reported pursuant to a transaction reporting plan or the OPRA Plan. Depending on the results of that analysis, regulators may undertake further inquiry into the nature of trading by that broker-dealer to determine whether the public received accurate and timely information regarding executions, and whether the broker-dealer complied with the trade reporting obligations contained in SRO rules. Patterns of reported and unreported transactions by a particular broker-dealer could also be indicia of market abuse, including the failure to obtain the best execution for customer orders, or possible market manipulation. Thus, the ability to compare the consolidated order execution data, including customer information, with the trades reported to the consolidated tape would be an important component of an effective market surveillance program that is not possible today because regulators currently do not have access to comprehensive cross-market audit trail data, and the process of identifying customers is very labor intensive, time-consuming, and error prone.
-In response to the commenter that recommended that the consolidated audit trail accommodate differences in the treatment of modifications by broker-dealer order management systems (i.e., those that report only the modified data elements, not the entire order), and suggested that only an order identifier be reported for a cancellation, not the cancelled order's other data elements,443 the Commission notes that Rule 613 does not require all of the data elements of a modified order to be reported to the central repository. The Rule only requires the NMS plan to require the reporting of the CAT-Order-ID; the date and time the modification is received or originated; the CAT-Reporter ID of the broker-dealer or the Customer-ID of the person giving the modification instruction; if modified, the price and remaining size of the order; and any other changes to the material terms of the order. The adopted Rule also requires the NMS plan to require the date and time a cancellation is received or originated and the CAT-Reporter-ID of the broker-dealer, or Customer-ID of the person, giving the cancellation instruction to be reported to the central repository. The Commission believes this will ensure that regulators can determine the market participant or person responsible for the cancellation of an order,444 and the date and time of the cancellation.
-In response to the commenter that suggested that the Rule should require that the execution data be linked with the public trade report using a common identifier,445 the Commission notes that Rule 613(c)(7)(v)(G) requires the NMS plan submitted to the Commission for its consideration to require that, for an order that has been executed, the SRO or member that executes the order must report to the central repository whether the execution was reported pursuant to an effective transaction reporting plan or OPRA, as applicable. The Commission has considered the commenter's further suggestion that a common identifier link the audit trail execution reports for the buy and sell orders to the public trade report and is not mandating such a requirement under Rule 613; the Commission believes that Rule 613 and its requirements provide a sufficient initial framework for collecting audit trail data that will enhance the ability of regulators to surveil the market for NMS securities.446 Accordingly, the Commission is adopting Rule 613(c)(7)(v)(G), as proposed, which requires that the plan sponsors include in the NMS plan submitted to the Commission for its consideration a requirement that the broker-dealer report to the central repository whether a trade was reported pursuant to an effective transaction reporting plan or OPRA.
-e. Rule 613(c)(3): Information to Be Recorded Contemporaneously with the Reportable Event and Reported to the Central Repository by 8:00 a.m. Eastern Time on the Trading Day Following the Day Such Information Has Been Recorded
-i. Proposed Rule 613(c)(3)
-As proposed, Rule 613(c)(3) would have required the NMS plan to require each SRO and member to collect and provide to the central repository, on a "real time" basis, key data for each order and each reportable event, including the origination or receipt of an order, as well as the routing, cancellation, modification, or execution of the order.447 Specifically, the proposed Rule would have provided that "[t]he national market system plan submitted pursuant to this section shall require each national securities exchange, national securities association, and member to collect and provide to the central repository the information required by paragraphs (c)(7)(i) through (v) of this section on a real time basis."448 In the Proposing Release, the Commission noted that "real time" meant "immediately and with no built in delay from when the reportable event occurs."449
-ii. Comments on Proposed Rule 613(c)(3)
-The Commission received a variety of comments about the achievability of the real-time requirement; the accuracy of audit trail data that would be collected and provided in real time; the necessity, merits and usefulness of real-time audit trail data; the costs of real-time reporting; and the proposed Rule's requirement that all audit trail data be collected and reported in real time. These comments are discussed below.
-Several commenters believed that reporting data on a real-time basis was achievable.450 Of these comments, one commenter stated that its current systems could be used to support real-time reporting, and that real-time reporting may be easier to achieve than intraday or end-of-day batch processing.451 Similarly, another commenter, endorsing the use of FIX Protocol, stated that FIX Protocol is already widely used throughout the financial industry, and that "[a]ll FIX messages are generated in real time for trading."452
-A significant number of commenters, however, expressed concern about the proposed requirement that the audit trail data be collected and provided to the central repository in real time.453 Some of these commenters focused on the effect a real-time reporting requirement would have on their systems, and the systems changes that might be needed to achieve real-time reporting. Specifically, commenters argued that a real-time collection and provision requirement would require many industry participants to build entirely new systems or to undertake significant technological upgrades to comply with a real-time reporting requirement.454 Other commenters stated that real-time reporting would strain their order handling systems and result in latencies and delays in the processing of customer orders.455 Additionally, one commenter questioned the ability of a real-time consolidated audit trail system to handle periods of immense volume, like the volume on May 6, 2010.456
-Other commenters who expressed concern about the real-time reporting requirement questioned the accuracy of data that would be reported in real time.457 One commenter, for example, noted that there would not be an opportunity for data validation if consolidated audit trail data were required to be reported in real time.458 Another commenter stated that the real-time processing required by real-time reporting would create data integrity issues and, thus, lead to poorer data quality as compared to an approach with a more liberal timeframe, such as next day, or "T+1," reporting.459 FINRA similarly commented that the data integrity issues that arise when audit trail data is provided on a T+1 basis would be exacerbated by a real-time system.460 FINRA stated that it performs over 40 billion data validations of order events submitted through OATS every day, and requires its members to repair rejected OATS data.461
-A number of commenters discussed whether a real-time reporting requirement is necessary. One commenter stressed that the real-time availability of data would facilitate the identification of cross-market events and their origins.462 This commenter explained that a platform developed using FTEN and SMARTS technology would include real-time risk management and surveillance capabilities.463 However, most commenters did not believe that real-time data typically would be useful to the Commission and SROs.464 One commenter explained that using audit trail data before having an opportunity to validate it "may result in a severely distorted picture of trading and interfere with effective oversight."465 Another commenter stated that "real-time order information is inherently incomplete and could even be inaccurate and therefore misleading to the users of the data."466 Some commenters were of the view that the Commission had significantly overvalued the regulatory benefit of real-time data.467 One of these commenters noted that, "[b]ased on its experience in conducting surveillance, [it] does not believe that it is essential that all of the information proposed to be captured in the CAT be received real time or near-real-time."468 A commenter suggested that, to the extent any information had to be submitted in real time, it should be limited to data related to certain key events, such as order receipt and origination, order transmittal, execution, modification, and cancellation.469 Other commenters generally questioned the value of real-time audit trail data, arguing that regulators would still need to rely on traditional investigative techniques, such as taking testimony, to establish securities law violations.470 Another commenter believed that "[m]any potential uses for the data, including enforcement inquiries probing market behavior, may require either multiple days' worth of data, or data from other markets that is not available on a real-time basis," limiting the ability to use such real-time data provided by the consolidated audit trail.471
-Some commenters questioned whether the substantial costs that would be associated with providing the data on a real-time basis would outweigh the benefits.472 One commenter believed that "the SEC has significantly overestimated the incremental utility of real-time data over data received on a T+1 basis" and that "the costs associated with the breadth of real-time reporting proposed by the Commission would be significant and far outweigh the minimal regulatory benefit gained by such a reporting system."473
-Some commenters who questioned the value of the real-time reporting requirement also suggested that the Commission consider a different timeframe for the reporting of audit trail information. Several commenters, for example, suggested a later timeframe for reporting audit trail data to the central repository. One commenter, an exchange, stated that "[o]ur strong preference would be for submission of information to the central repository through a batch process after the close of the trading day involved."474 Another commenter suggested a compromise whereby broker-dealers would be subject to next day (or later) reporting requirements, while the SROs could leverage their existing real-time monitoring tools and provide real-time trading information for use in the consolidated audit trail.475 Several commenters recommended that the Commission permit end-of-day reporting.476 One commenter noted that end-of-day reporting would alleviate some of the practical challenges firms would face with a requirement to identify beneficial owners on a real-time basis.477 Another commenter suggested that a reporting deadline of 10-15 minutes would be substantially more workable than a "real-time" reporting requirement.478 Finally, one commenter suggested that broker-dealers and SROs should retain audit trail information, and submit it only upon regulatory request, so that the central repository would only collect data needed for investigations or surveillance purposes.479
-One commenter, who did not specifically advocate either real time or reporting on an end-of-day basis, supported a requirement that all trades be reported in a standardized format that will be accessible to the SEC at the end of each trading day.480
-Some commenters suggested alternative means of collecting audit trail information, assuming such audit trail data would not be on a real-time basis and would not be through the reporting regime set forth by Rule 613. For example, one commenter suggested the Commission consider "a consolidation" of [OATS] and [COATS], audit trails that are produced on a T+1 basis; and a review of the prospect of extracting specific real-time data from surveillance reports currently used by SROs to perform post trade analysis, such as the Large Option Position Report . . . and large trader reports, to obtain real-time risk information that may impact a particular NMS issue or the market in general."481 This commenter believed that a requirement of real-time reporting should be considered only after other available sources of data have been carefully reviewed, and only to the extent that such a requirement is both necessary and economically feasible.482 Another commenter, however, urged the Commission not to "lower its expectations for the CAT and accept a more limited audit trail based exclusively on existing systems."483 One commenter suggested that the Commission consider a "hybrid" approach that would enhance elements of the quotation and transaction information reported in real time, while collecting and reporting more specific order information on a T+1 basis or later.484
-Two commenters commented on the meaning of "real time."485 One commenter noted that "[our members] request clarification on the definition of real-time data submission as it relates to each data element required by CAT. The granularity/definition of real-time for each element will have a major impact on SROs, their members and CAT system development from both a data quality and database design perspective . . . ."486 The other commenter noted that the "[t]he term 'real time' is used throughout the document, but never defined. (There are several distinct meanings in the computer industry.)"487
-The Commission also received comments specifically relating to the cost of reporting the audit trail information in real time under the Rule as proposed. One commenter believed it would cost $1.25 million in initial costs to comply with the Rule as proposed.488 The commenter divided its $1.25 million estimate into development costs of $750,000 and hardware costs of $500,000 (including hardware, circuits, etc.).489 In addition, this commenter believed the development timeframe would be 9-12 months "once final architecture is drafted," and would require approximately 6,000 hours of development work.490 Notably, this commenter said that "[t]he assumptions that drove this analysis were that any real time reporting of order events would leverage the capabilities contained within the [OATS] reporting today and that the revised real time system would retire the legacy systems of Bluesheets, OATS, OTS and TRACE."491 With respect to ongoing costs to provide information, this commenter also stated that it believed the Commission had underestimated the ongoing costs of the proposal.492 However, another commenter, who opined that the goals of the consolidated audit trail could be achieved for significantly lower costs than the Commission originally estimated, stated that, if the Rule permitted market participants to modify existing systems for collecting and reporting audit trail information, the consolidated audit trail objectives could "be achieved and perhaps even surpassed."493
-iii. Adopted Rule 613(c)(3)
-As described in detail below, the Commission is adopting Rule 613 with two significant modifications to the proposed requirement that the NMS plan submitted to the Commission for its consideration require the collection and provision of key audit trail data to the central repository on a "real time" basis. First, the Rule, as adopted, no longer requires the real-time reporting of consolidated audit trail data but, instead, provides that order event audit trail data must be reported "by 8: 00 a.m. Eastern Time on the trading day following the day such information has been recorded by the national securities exchange, national securities association or member."494 Second, the adopted Rule clarifies that this data is to be recorded "contemporaneously with the reportable event," instead of in "real time."495
-(A) Reporting of Audit Trail Data by 8: 00 a.m. Eastern Time on the Trading Day Following the Day Such Information Has Been Recorded
-The Commission has considered the commenters' concerns regarding a "real-time" reporting requirement for audit trail data, including its achievability and cost effectiveness; the accuracy of audit trail data recorded and reported in real time; and the necessity, merits, and usefulness of real-time audit trail data.496
-On the one hand, the Commission recognizes that there may be very considerable costs imposed on the industry if audit trail data was required to be reported to the central repository in real time – indeed, the Commission, in the Proposing Release, estimated the costs of creating a real-time consolidated audit trail by assuming that such a requirement would necessitate the wholesale creation of new industry-wide systems. On the other hand, the Commission also received a variety of comments suggesting that real-time reporting could be achieved in a cost-effective manner.497 And yet other commenters suggested a hybrid approach. For example, SIFMA commented that, although it believed real-time reporting as originally proposed by the Commission would be too costly, intra-day reporting of a subset of audit data delayed 10-15 minutes would be possible. SIFMA further described how such reporting might be accomplished through the use of "drop-copy" data.498
-With respect to concerns about the accuracy of consolidated audit trail data if real-time reporting were required, the Commission recognizes that the real-time reporting of data could result in accuracy issues to the extent SROs and broker-dealers would need to re-enter the required audit trail data into a separately prepared regulatory report containing the required audit trail data for submission to the central repository, as is the case today with OATS reports.499 The Commission notes, however, that the use of certain existing technologies, such as "drop copies" described by SIFMA, could provide reliable and accurate audit trail data to the central repository because such "drop copies" would reflect the information captured by an SRO or member's order management and execution systems to enter, route, modify, and execute or cancel orders.
-The Commission believes that, whether or not real-time reporting of data is required, the creation, implementation, and maintenance of a consolidated audit trail will likely be a complex and significant undertaking for the industry. It therefore recognizes the practical advantages of a more incremental, or more gradual, approach to such an undertaking. After considering the many comments received on the use of real-time data by regulators, the Commission has recognized that, although there might be some additional benefits to receiving data and monitoring the markets intra-day (such as for certain enforcement investigations and the facilitation of real-time cross-market surveillance), the majority of the regulatory benefits gained from the creation of an industry-wide consolidated audit trail, as described in the Proposing Release, do not require real-time reporting. Indeed, the extent of the potential uses of a consolidated audit trail discussed in Section II.A.2., supra, which do not rely on a real-time reporting requirement, illustrate the value of a consolidated audit trail even if data is not reported in real-time. Instead, the Rule, as adopted, provides that the NMS plan must require that order event data be reported "by 8: 00 a.m. Eastern Time of the trading day following the day such information has been recorded by the national securities exchange, national securities association or member."500
-The Commission notes that, while the Rule provides that the NMS plan must impose a reporting deadline of 8: 00 a.m. Eastern Time of the trading day following the day such information has been recorded by the national securities exchange, national securities association or member, the Rule also provides that the NMS plan may accommodate SROs and members that voluntarily satisfy their reporting obligations earlier.501
-The Commission acknowledges that, by replacing the requirement that the SROs develop a plan for real-time reporting with a requirement for reporting by 8: 00 a.m. the next trading day, the Commission has precluded the possibility that, as some commenters suggested, a mandatory real-time reporting NMS plan might be developed by the SROs for consideration by the Commission and the public.502 However, given the overall scope and complexity of creating a consolidated audit trail, the Commission has determined that it would be more beneficial to have the SROs and their members focus on those key aspects of a consolidated audit trail that the Commission believes would be the most useful for improving regulatory oversight and monitoring (including, but not limited to, the use of unique customer identifiers, the ability to accurately link an order across its lifecycle, the inclusion of market making quotes, and the addition of options data), rather than focus on how to develop an NMS plan for real-time reporting that may not yield benefits that are equally as useful.503 The Commission also believes that, as a consequence of this modification, the Rule, as adopted with the 8: 00 a.m. reporting deadline, will more readily accommodate a consolidated audit trail that could build upon existing audit trail infrastructures. Meeting the requirement of the Rule may no longer necessitate the creation of completely new infrastructures. In particular, the Commission notes that the OATS technical specifications require OATS data to be reported by 8: 00 a.m. the following calendar day.504 Thus, the Rule, as adopted, would permit the SROs to submit an NMS plan to the Commission for its consideration with reporting timeframes comparable to OATS' requirement, with which all FINRA members are presently capable of complying.505 As a result, broker-dealers might need to make fewer systems changes to comply with the Rule than they would have had to make if real-time reporting were required, though, as discussed in Section II.C.4., supra, OATS in its present form would still need to be modified to meet certain of the other requirements of this Rule.506 Nevertheless, as suggested by many commenters, fewer systems changes to comply with the Rule should lead to lower costs incurred by broker-dealers.507
-An additional consequence of the Commission's decision not to require real-time reporting is that, since meeting the requirements of the Rule may no longer necessitate the wholesale creation of new systems, the Commission's proposed cost estimates, which were based on this assumption, may no longer be applicable. As discussed in Section II.C.2., supra, the Commission believes that given the many different ways in which the SROs may develop an NMS plan that meets an 8: 00 a.m. reporting requirement, the costs of such reporting will be highly dependent on the details of the specific plan proposed. The Rule, as adopted, therefore directs the SROs to provide these details, along with associated costs, in the NMS plan submitted to the Commission for the Commission and the public to consider. The Commission will be able to consider this information when determining whether to approve the NMS plan submitted.
-(B) Recording of Audit Trail Data Contemporaneously with the Reportable Event
-As noted above, the Rule as proposed would have required SROs and their members to "collect" audit trail data "on a real time basis." In response to commenters who commented on the meaning of "real time," the Commission is adopting this provision with modifications from the proposed Rule. Specifically, Rule 613(c)(3), as adopted, requires that "[t]he national market system plan submitted pursuant to this section shall require each national securities exchange, national securities association, and member to record the information required by paragraphs (c)(7)(i) through (v) of this section contemporaneously with the reportable event."
-The Commission believes that the term "contemporaneously" better reflects its intent, as noted in the Proposing Release, that information should be collected immediately and with no built-in delay from when the reportable event occurs. While, in response to commenters, the Commission is no longer requiring the real-time reporting of information, the Commission believes it is important for SROs and broker-dealers to "record" the events contemporaneously. The Commission expects that compliance with this requirement will not be difficult for SROs and broker-dealers with automated systems, which will contain much, if not all, of the data to be reported to the central repository as a result of processing and saving a record of any actions taken by the SRO or broker-dealer. On the other hand, broker-dealers that do not use automated systems will have to ensure that reportable events are manually recorded as they are occurring. In addition, the adopted Rule uses the term "record" in Rule 613(c)(3), instead of the proposed term "collect," because the Commission believes that term more accurately reflects its intent that a contemporaneous record be made when an order event occurs.
-f. More Flexible Format for Reporting Consolidated Audit Trail Data to the Central Repository
-In the Proposing Release, the Commission expressed its preliminary view that data would need to be collected and provided by SROs and their members to the central repository in a uniform electronic format to assure regulators that they will have ready access to comparable cross-market data.508 Specifically, Rule 613(c)(2), as proposed, provided that "[t]he national market system plan submitted pursuant to this section shall require each national securities exchange, national securities association, and member to collect and provide to the central repository the information required by paragraph (c)(7) of this section in a uniform electronic format."
-However, the Commission received comments suggesting that audit trail data does not necessarily need to be provided by SROs and their members to the central repository in a uniform electronic format, and that such data instead could be converted automatically into a uniform format by the central repository or a third party using existing technology, which could result in lower cost for the securities industry than originally estimated.509 Specifically, two commenters indicated that technology exists today to convert or "normalize" data that may be produced from disparate systems into a uniform format and that, as a result, implementation of the consolidated audit trail could be simpler and less costly than originally contemplated by the Commission.510 One of these commenters stated that a number of risk management services and surveillance systems currently receive automatically-generated copies, or "drop copies," of order and execution messages, in real time, from a variety of broker-dealers and exchanges, and convert that information into a common standard format.511 Two other commenters suggested that firms that currently use FIX should be allowed to continue utilizing FIX,512 stating that FIX's prevalence in the financial industry would make it cheaper and easier to use FIX as the protocol of the consolidated audit trail.513 Another commenter stated it could collect information directly from exchanges and other sources of information to minimize reporting obligations, and could leverage its own technology to get information directly from exchanges.514
-In response to these comments, the Commission has modified this aspect of the proposed Rule. Specifically, adopted Rule 613(c)(2) allows the NMS plan to provide that SROs and their members can report data either "in a uniform electronic format" or "in a manner that would allow the central repository to convert the data to a uniform electronic format, for consolidation and storage."515 In light of the comments that data from multiple sources could be converted into a uniform format,516 this modification provides SROs with the flexibility, in devising the NMS plan, to better accommodate a range of proposals, including those based on leveraging technology in a cost-effective manner by permitting data to be converted to a uniform electronic format at the broker-dealer level or at the central repository. The Commission does not believe this change will reduce the accuracy or accessibility of the audit trail data provided to regulators (since the Rule still requires data to ultimately be provided to regulators in a uniform electronic format).
-Further, by providing the SROs the ability to use a number of approaches to normalization, broker-dealers and SROs may not need to make substantial changes to their order management and execution systems to comply with Rule 613; instead, the central repository or the broker-dealers could convert such data into a uniform electronic format, and the Rule now provides the plan sponsors with the flexibility to use this approach in the NMS plan submitted to the Commission for its consideration. The Commission believes that, to the extent it avoids requiring broker-dealers and SROs to make substantial changes to their order management and execution systems to comply with Rule 613 regarding a uniform electronic format, this type of approach could be a more efficient and cost-effective method for collecting the specified audit trail data required by the Rule.517 The Commission expects that the NMS plan submitted for its consideration will specify how any normalization approach that might be included in the plan will lead to accurate and reliable data.518
-g. Timeframe for Reporting Other Data Elements to the Central Repository
- -While most order and execution information would have been required to be reported to the central repository on a real-time basis under the proposed Rule, the Commission also recognized that not all information required to be reported to the consolidated audit trail would be available to the SROs and their members in real time.519 In general, the audit trail data required under this timeframe reflected information not typically available until later in the order handling and execution process. This information that would have been provided on an extended timeframe included: (1) the account number for any subaccounts to which the execution is allocated (in whole or part); (2) the unique identifier of the clearing broker or prime broker (if applicable); (3) the unique order identifier of any contra-side order(s); (4) special settlement terms (if applicable); (5) the short sale borrow information and identifier; (6) the amount of a commission, if any, paid by the customer and the unique identifier of the broker-dealer(s) to whom the commission is paid; and (7) the cancelled trade indicator (if applicable) (collectively, "supplemental audit trail data").520 Proposed Rule 613(c)(4) would have permitted the supplemental audit trail data to be reported to the central repository promptly after the national securities exchange, national securities association, or member received the information, but in no instance later than midnight of the day that the reportable event occurs or the SRO or member receives such information.
-The Commission solicited comments on proposed Rule 613(c)(4) and its requirement that certain audit trail information not available in real time be reported promptly after the national securities exchange, national securities association, or member received the information, but in no instance later than midnight of the day that the reportable event occurs or the SRO or member receives such information. One commenter believed that the timeframe for reporting the specific consolidated audit trail data listed above should be lengthened to T+1 or later.521 This commenter was concerned that requiring broker-dealers to report certain data elements by midnight could disrupt the trading of certain products.
-ii. Adopted Rule 613(c)(4)
-After considering the commenter's views on proposed Rule 613(c)(4), the Commission is adopting the Rule with three modifications from the proposed Rule. First, to parallel the 8: 00 a.m. deadline by which order event data must be reported to the central repository under adopted Rule 613(c)(3), adopted Rule 613(c)(4) requires that the NMS plan provide that supplemental audit trail data be reported by 8: 00 a.m. Eastern Time on the trading day following the day the member receives the audit trail data, and provides that the plan may accommodate voluntary reporting prior to 8: 00 a.m. Eastern Time, but shall not impose an earlier reporting deadline on the reporting parties.
-Second, the adopted Rule no longer requires the reporting of (1) special settlement terms, (2) the amount of commission, if any, paid by the customer, and the unique identifier of the broker-dealer to whom the commission is paid, and (3) the short sale borrow information and identifier. Third, adopted Rule 613(c)(4) requires that the NMS plan provide for the reporting of certain customer identification and customer account information by 8: 00 a.m. Eastern Time on the trading day following the day the member receives such data, instead of in "real time," as proposed.522 These modifications are discussed in more detail below.
-(A) Reporting Timeframe
-In response to the comments regarding the timing for reporting of consolidated audit trail data elements,523 the Commission is adopting Rule 613(c)(4) with modifications to the timeframe for reporting supplemental audit trail data. Specifically, the Rule no longer requires that supplemental audit trail data be reported "promptly" after the broker-dealer receives the information but no later than midnight of the day that the reportable event occurred; rather, adopted Rule 613(c)(4) requires the NMS plan to provide that supplemental audit trail data be reported by 8: 00 a.m. Eastern Time on the trading day following the day the broker-dealer receives such information. Although the NMS plan may permit broker-dealers to report such information prior to that time, it may not require such earlier reporting. The Commission believes it is appropriate that there be an extended timeframe for reporting this data because this information (e.g., allocation to subaccounts) might not be available until later in the order handling and execution process and, on balance, the Commission does not believe it is necessary that it be reported to the central repository "promptly". Instead, the modification to Rule 613(c)(4), as proposed, now requires that the NMS plan provide that the supplemental audit trail data be reported by 8: 00 a.m. Eastern Time following the day the member receives the information, which parallels the adopted Rule 613(c)(3) timeframe for reporting event data. The Commission believes this more flexible standard should reduce implementation burdens and simplify the requirements of adopted Rule 613, without materially reducing the utility of the consolidated audit trail.
-The Commission notes that it has made a clarifying change to Rule 613(c)(4), as proposed, to specify that the obligation to report the supplemental audit trail data to the central repository only falls on a broker-dealer, and not on a national securities exchange or national securities association.524 The Commission believes that this change is appropriate because only broker-dealers receive the types of audit trail data described in Rule 613(c)(vi) through (viii).525
-(B) Elimination of Certain Data Elements
-As previously noted, proposed Rule 613(c)(4) would have required that the following information be reported to the central repository: (1) the account number for any subaccounts to which the execution is allocated (in whole or part); (2) the unique identifier of the clearing broker or prime broker (if applicable); (3) the unique identifier of any contra-side order(s); (4) special settlement terms (if applicable); (5) the short sale borrow information and identifier; (6) the amount of a commission, if any, paid by the customer and the unique identifier of the broker-dealer(s) to whom the commission is paid; and (7) cancelled trade indicator (if applicable).526
-After considering general comments suggesting that the Commission reduce the proposed reporting obligations under Rule 613, the Commission is not requiring the following data elements to be reported to the central repository: (1) special settlement terms; (2) the amount of commission, if any, paid by the customer; (3) the unique identifier of the broker-dealer to whom the commission is paid; and (4) the short sale borrow information and identifier.527 While this data may be useful in the context of certain investigations or market analyses, upon further consideration, the Commission believes that these data elements should not be required by Rule 613 because the Commission does not typically find that these particular audit trail data elements provide enough information relevant to an initial assessment of whether illegal or manipulative activity is occurring in the marketplace to warrant that they be required as a standard part of the audit trail created by Rule 613. If the Commission or the SROs find that such information would be useful to their regulatory responsibilities, they may request the information directly from the broker-dealer with the obligation to record this information, although requests related to short sale borrow information may pose unique challenges. In effect, the Commission believes that the benefit of having these specific audit trail data elements in the consolidated audit trail at this time is unlikely to justify the recording and reporting burden on broker-dealers of providing these elements, particularly in light of the other information required to be reported under Rule 613 and the regulators' ability to obtain this information through a follow-up request. The Commission notes that, if the SROs believe that having such data elements as part of the consolidated audit trail could be useful to their regulatory responsibilities, the SROs could determine to require SROs and their members to record and report such data as part of the NMS plan.
-With respect to the account number for any subaccounts to which the execution is allocated (in whole or in part) – an audit trail data element that will be required by Rule 613(c)(4), as adopted – the Commission notes that obtaining allocation information is important because part of the goal of Rule 613 is to obtain audit trail information for the life of an order, which would include how an order was ultimately allocated (i.e., to which specific customer and account). The Commission notes, however, that the Rule requires the NMS plan to require a broker-dealer to report only the account number of any subaccounts to which an execution is allocated that is contained in its own books and records for accounts and subaccounts it holds; there is no obligation for the broker-dealer to obtain any additional information about accounts or subaccounts from other broker-dealers or non-broker-dealers who submitted the original order. The Commission further notes that broker-dealers will remain subject to existing regulatory requirements, including recordkeeping and suitability requirements (e.g., "know your customer" rules). Including the account number of any subaccounts to which an execution is allocated in the consolidated audit trail will allow regulators to understand how an allocation of the securities was made among customers of a broker-dealer to, for example, determine if the broker-dealer was favoring a particular customer, to better understand the economic interests of the customer, or as it relates to possible enforcement actions. Similarly, having information regarding the identity of the clearing broker or prime broker for the transaction, the identity of any contra-side order(s), and a cancelled trade indicator by 8: 00 a.m. Eastern Time on the trading day following the day that the member receives such information will aid the Commission and the SROs in knowing all of the parties that touched an order (including the clearing broker, prime broker, and contra-side party to the order), and whether the order was cancelled. The Commission believes that all of this information will facilitate regulatory improvements as discussed above in Section II.A.2.
-(C) Movement of Certain Data Elements from Event Data to Supplemental Audit Trail Data
-As proposed, Rule 613 would have required that, in addition to the Customer-ID, customer account information and other specified information sufficient to identify a customer be reported in real time.528 The Commission requested comment about the feasibility of this requirement. Several commenters expressed concern over the proposed requirement that customer information be reported in real time upon origination or receipt of an order.529 One commenter believed that leakage of customer information could "negatively impact investor willingness to trade in the U.S. markets,"530 and, instead, urged regulators to rely on EBS to provide customer information.531 Another commenter did not think it was feasible to provide customer information in real time.532 Another commenter suggested that the Commission "pare down its list of data points to focus on what would appear on a trade ticket and certain client demographic information."533 This commenter explained that its suggested approach "makes sense because for most brokers pulling trade ticket information from frontend systems will be straightforward, and client demographics should be easily pulled and populated onto a system for easy retrieval."534 Another commenter was of the view that only customer information regarding the person exercising investment discretion for the account originating the order, such as an investment adviser, should be required to be reported.535 This commenter explained that if a trade is not executed an investment advisor would not typically provide information about the owners of the underlying accounts to the broker-dealer and thus this commenter suggested that it would be more practical to disclose underlying account information in relation to executed trades.536 Another commenter suggested that there be a "requirements analysis" that considers the availability of order and trade data, and noted that allocation data is not available at the time of order entry.537
-In recognition of commenters' concerns that this information may not be available in real time538 and to reduce the reporting burdens on broker-dealers, the Commission is moving data elements, including the customer's name, address, and account information, and large trader identifier (if applicable) (collectively defined as "customer attributes") from the order event data category to the supplemental audit trail data category.539 As a result, the Commission is adopting the Rule to provide that the NMS plan require that customer attributes540 including the customer's name, address,541 and customer account information be reported under Rule 613542 no later than 8: 00 a.m. Eastern Time on the trading day following the day that the member receives the information.543 The Commission expects that the Customer-ID will be able to be linked to the customer attributes in the consolidated audit trail.
-The Commission believes that, to realize many of the objectives of a consolidated audit trail, the specific attributes of a customer must be recorded and, when needed, made available to regulators. Without these customer attributes, the data recorded is effectively anonymized, which would prevent regulators from using the enhanced consolidated audit trail data to take any enforcement action against specific individuals. The Commission believes customer attributes544 are necessary because regulatory authorities need to accurately and efficiently identify the customer to effectively surveil and analyze the markets, and enforce the securities laws. For example, as noted in the Proposing Release,545 a trader may trade through multiple accounts at multiple broker-dealers. Being able to identify the account holder aids in the identification and investigation of suspicious trading activity. Accordingly, the unique customer identifier that is required to be reported to the central repository for original receipt, origination, modification, or cancellation of an order,546 and that links together all reportable events by the same customer, must ultimately link back to information regulators could use to identify the party. With this information, regulators could more quickly initiate investigations, and more promptly take appropriate enforcement action. While this information could be requested from broker-dealers by the Commission and the SROs on a case-by-case basis, the Commission believes that achieving these benefits requires having such information maintained in a uniform format that is readily accessible to the Commission and the SROs.
-Furthermore, in response to the commenters concerns with respect to the confidentiality of this sensitive information,547 and as discussed in more detail below, the adopted Rule includes requirements for enhanced safeguards with respect to the privacy and confidentiality of consolidated audit trail data, including customer information.548
-In response to the commenter who suggested only information appearing on the trade ticket and certain client demographic information549 be collected, the Commission notes that it may be feasible for the NMS plan to allow customer identifying and account information to be reported by a broker-dealer to the central repository only when the customer opens or closes an account (or at the time the consolidated audit trail is first implemented for pre-existing accounts) -- this information may not need to be re-reported with every order.550 Under this approach, the specified customer attributes may be stored in the central repository and automatically linked to an order whenever an order with the applicable Customer-ID is reported. As the Commission noted in the Proposing Release,551 broker-dealers today, as part of their books and records requirements, must take reasonable and appropriate steps to ensure the accuracy of the customer information with respect to orders received.552 Following adoption of the Rule, and the creation and implementation of the consolidated audit trail, broker-dealers will continue to be subject to this requirement as they report customer information to the central repository. The Commission believes that allowing the specified customer attributes to be reported to the central repository by 8: 00 a.m. Eastern Time on the trading day following the day that a broker-dealer first receives this information appropriately balances the regulatory need with the practical burdens of supplying it in real time as originally proposed.
-In response to the commenter who stated that an investment adviser would not typically provide information about the owners of the underlying accounts to the broker-dealer if the trade is not executed,553 the Commission notes that, in the case of an adviser that enters an order to buy or sell securities using its own account held at the broker-dealer originating the order, the Rule, as adopted, would only require the NMS plan to require the capture of information about the owners of the underlying client accounts for which the order was placed if there is an executed trade, and if the executed trade is allocated (pursuant to Rule 613(c)(7)(vi)) to the accounts of the adviser's clients at the same broker-dealer.554 However, the Commission notes that, in the case of an adviser that enters an order on behalf of clients that each maintain separate accounts at the broker-dealer originating the order, using those accounts, the Rule would require the NMS plan to require the capture of both the adviser – as the person providing trading instructions to the broker-dealer (pursuant to Rule 613(j)(3)(ii)) – and the clients, who are the account holders at the broker-dealer (pursuant to Rule 613(j)(3)(i)), even if the order did not result in execution.
-Finally, in the Proposing Release,555 the Commission specifically requested comment on whether there are laws or other regulations in other jurisdictions that would limit or prohibit members from obtaining the proposed customer information for non-U.S. customers. The Commission also requested comment on how members currently obtain such information. If broker-dealers did encounter special difficulties in obtaining customer information from other jurisdictions, the Commission requested comment on how the proposed consolidated audit trail requirements should be modified to address such difficulties.
-The Commission received one comment on this issue.556 The commenter expressed concern that, if broker-dealers were forced to refuse orders from non-U.S. customers because the laws of another jurisdiction prohibited disclosure of certain customer information, U.S. broker-dealers would be penalized and trading activity may shift offshore.557 The commenter recommended that the Commission adopt a limited exemption that would allow broker-dealers to accept orders from non-U.S. broker-dealers without providing customer information, in recognition of the fact that these broker-dealers are subject to regulation in their home countries.558
-In the Rule, as adopted, "customer" is defined as "(i) [t]he account holder(s) of the account at a registered broker-dealer originating the order; and (ii) [a]ny person from whom the broker-dealer is authorized to accept trading instructions for such account, if different from the account holder(s)." Under this definition, the non-U.S. broker-dealer referred to above is the "customer" of the U.S. broker-dealer for purposes of the rule. The U.S. broker-dealer would be required to record customer information for transactions in NMS securities only with respect to its foreign broker-dealer customer. There is no requirement to record information about the customers of such foreign broker-dealer. Because the Rule as adopted does not require a non-U.S. broker-dealer placing orders in NMS securities through a U.S. broker-dealer to provide information about its customers to the consolidated audit trail, the Commission believes that the requested limited exemption is unnecessary.
-Although the Commission is aware that the privacy laws of some, but not all, foreign jurisdictions may hinder a foreign broker-dealer's ability to disclose personal identifying and account information of their customers absent customer authorization, the Rule as adopted does not require the foreign broker-dealer to disclose this information about its customers.559 Accordingly, a non-U.S. customer desiring to trade in the U.S. markets would be permitted to do so through a foreign broker-dealer without having to disclose its personal data to the consolidated audit trail. Because the Rule as adopted does not require a foreign broker-dealer to disclose personal identifying and account information of its customers to the consolidated audit trail, the Commission does not believe that trading in NMS securities will shift offshore as a result of the customer identification requirements.
-h. Clock Synchronization
-As proposed, Rules 613(d)(1) and (2) required that the NMS plan filed with the Commission include a requirement that each SRO and its members synchronize their business clocks that they use for the purposes of recording the date and time of any event that must be reported to the time maintained by the National Institute of Standards and Technology ("NIST"), consistent with industry standards.560 The SROs and their members also would have been required to annually evaluate the clock synchronization standard to determine whether it should be changed to require finer increments, consistent with any changes to industry standards.561 This clock synchronization would have been required to occur within four months after effectiveness of the NMS plan.562
-A few commenters expressed concerns with the Commission's proposed approach to clock synchronization, and a few commenters provided comments specifically relating to the Commission's estimated costs relating to clock synchronization.563 One commenter preferred a synchronization standard measured in seconds and believed that synchronizing at the millisecond level would require specialized software configurations and expensive hardware.564 This commenter also was of the view that there could be material problems with systems latency if processors were required to re-synchronize clocks every few seconds to address "time drift" issues – further deviations from the time maintained by the NIST that may occur after a clock is synchronized.565 Another commenter suggested that a clock synchronization standard shorter than the three second standard currently required by FINRA for OATS compliance might be impossible to achieve across market participants.566 A third commenter was concerned that implementing clock synchronization could require firms to make modifications to a variety of related applications.567 One commenter noted that synchronizing clocks to milliseconds would require costly specialized software and hardware.568
-On the other hand, one commenter – a provider of data capture and time stamping technology – noted that "[t]he advent of relatively low cost GPS receivers that derive absolute timing information accurate to better than 0.1 micro-seconds has significantly eased the problem of clock synchronization across multiple global locations," that "[s]uch technology costs a few thousands of dollars per installation," and that "[i]t is already in use by exchanges and high frequency traders."569 Another commenter expressed support generally for the Commission's proposed approach to clock synchronization.570
-After considering the comments received on this issue, the Commission is adopting Rule 613(d)(1) as proposed. As this provision requires that the NMS plan require clock synchronization consistent with industry standards, the Commission expects the NMS plan that is submitted to specify the time increment within which clock synchronization must be maintained, and the reasons the plan sponsors believe this represents the industry standard. The Commission notes that FINRA currently requires its members to synchronize their business clocks used for OATS reporting to within one second of the time maintained by NIST.571 The Commission believes that the current industry standard for conducting securities business is more rigorous than one second. For example, as one commenter noted, technology used today by exchanges and high frequency trading firms synchronizes clocks to increments well within the millisecond level.572 The Commission recognizes, as another commenter noted, that some firms may need to upgrade their technology to meet the industry standard,573 and that there will be attendant costs for such upgrading.574
-The Commission continues to believe that it is appropriate to require members of the securities industry to synchronize their clocks to the time maintained by NIST. Effective clock synchronization is essential to maintaining an accurately time-sequenced consolidated audit trail, particularly one where time stamps will be in millisecond increments or less. Because the consolidated audit trail will capture trading activity occurring across markets, if the business clocks used by SROs and their members for the purposes of recording the date and time for reportable events are not properly and consistently synchronized, the consolidated audit trail data will not be accurately time-sequenced. It is critical for the consolidated audit trail to allow regulators the capability to accurately determine the order in which all reportable events occur.575
-The Rule as proposed required that both the SROs and their members annually evaluate the clock synchronization standard to determine whether it should be changed to require finer increments, consistent with any changes in the industry standard.576 The Commission believes that the obligation to evaluate the clock synchronization standard annually should be borne by the SROs as the plan sponsors, not SRO members. The Commission believes that it is appropriate for the SROs, as regulators of the securities markets and users of the consolidated audit trail data, to have the obligation to evaluate whether a change in the clock synchronization standard is warranted.577 Therefore, the adopted Rule provides that the NMS plan shall require SROs to evaluate annually the clock synchronization standard set forth in the NMS plan.578
-The Commission recognizes, as a commenter noted,579 that time drift is an issue that must be addressed by the plan sponsors, to prevent a deterioration of the accuracy of the data in the consolidated audit trail. Therefore, the Commission expects the NMS plan to address the maximum amount of time drift that would be allowed before clocks must be re-synchronized, and why this is consistent with the industry standard.
-As with many other aspects of the Rule, the costs of this requirement are highly dependent on the details of the solution proposed by the SROs because the Commission is leaving it up the SROs to determine the maximum allowable time drift. As such, the SROs must discuss in their submitted plan the clock-synchronization standard they proposed, what alternatives were considered, and the rationale behind their choice. Once the NMS plan is received, the Commission, as well as the public, will be able to consider the extent to which the proposed synchronization standard supports the ability of regulators to fully achieve the benefits afforded by the creation of a cross-market consolidated audit trail.
+This scenario illustrates the reporting requirement when an ATS performs a cross that has multiple orders on one side. For this case, the ATS must report:
+• The receipt of the three orders involved in the execution (three Order Accepted events)
+• Two Trade Events
+
+ 
+ 
+ 
+ 
+ 
+ 
pubdate: N/A effdate: N/A
- 2. Central Repository
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Discussion, Elements of the NMS Plan, Central Repository
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2.2.4. Negotiated Trade
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Trade Scenarios, Negotiated Trade
+ Compliance User: Industry Member
Keywords:
- NMS Plan,
- Receipt,
- Consolidation,
- Retention of Data,
- Audit Trail Data,
- NBBO Information,
- Transaction Reports,
- Last Sale Reports,
- Retention,
- Timeliness,
- Accuracy,
- Integrity,
- Completeness,
- Consolidated Data,
- Access,
- Confidentiality,
+ Industry Member,
+ New Order,
+ New Order and Trade,
- a. Central Repository as a Facility of the SROs
-As proposed, Rule 613(e) required that the NMS plan provide for the creation and maintenance of a central repository,580 which would have been a "facility" of each exchange and FINRA.581 The central repository would have been jointly owned and operated by the exchanges and FINRA, and the NMS plan would have been required to provide, without limitation, the Commission and SROs with access to, and use of, the data reported to and consolidated by the central repository for the purpose of performing their respective regulatory and oversight responsibilities pursuant to the federal securities laws, rules, and regulations.582 Each of the exchanges and FINRA would have been a sponsor of the plan583 and, as such, would have been jointly responsible for selecting a plan processor to operate the central repository.584
-The Commission requested comment on the need for a central repository to receive and retain the consolidated audit trail information, whether there would be alternatives to creating a central repository for the receipt of order audit trail information, and whether it would be practical or appropriate to require the SROs to jointly own and operate the central repository.
-A few commenters discussed the proposed ownership structure of the central repository.585 One commenter argued that the central repository should be owned and operated by the Commission, or a non-SRO formed specifically to operate the central repository, and expressed concern that the central repository could be used by SROs as a source of revenue through the imposition of penalties.586 Another commenter recommended that the Commission own the repository and not outsource it to a third party, explaining that, in systemically important events, it may be necessary to have immediate and direct access to the data, without an intermediary.587 Yet another commenter noted that the decision to use OATS or another system as the basis for the consolidated audit trail system should be separate from the choice of the party that will be responsible for building and operating the central repository.588
-The Commission received a couple of comments specifically regarding the costs of the creation and maintenance of the central repository. FINRA, in one of its comment letters, submitted a "blueprint" for a version of a consolidated audit trail based on enhancements to OATS – though without certain key elements proposed to be required by the adopted Rule – and estimated initial costs for developing the repository to be between $100 million and $125 million, with ongoing annual costs to be between $30 million and $40 million.589 Another commenter suggested the use of cloud computing for the central repository which it believed would cost less than $10 million per year.590
-The Commission has considered the comments and is adopting as proposed the requirement in Rule 613(e)(1) that the NMS plan provide for the creation of a central repository. The Commission believes that having a central repository is important to ensuring access to consolidated data for the Commission and SROs, and for ensuring consistency, quality, and security in the audit trail data.
-As adopted, Rule 613(e)(1) does not dictate a particular audit trail collection system to be used as the central repository for the consolidated audit trail, but, instead, delineates the required core features of such a system.
-The Commission considered the commenter's recommendation that it should own the central repository591 but determined that such ownership is not necessary as long as the central repository has the core features articulated in the Rule, the Commission and SROs have full access to the audit trail data for regulatory purposes, and the central repository is a facility of each SRO subject to Commission oversight.592 The Commission notes that, because the central repository will be jointly owned by, and a facility of, each SRO, it will be subject to Commission oversight. The Commission will have unfettered access to the data in the central repository without being its owner.
-The Commission also considered the comment that the central repository should be owned by a non-SRO specifically formed to operate the central repository.593 The Commission, however, believes that it will have more regulatory authority over the central repository as a facility of each SRO than it would have if the central repository were owned or operated by a non-SRO. First, the Commission has the statutory obligation to oversee the SROs, including facilities thereof, and to ensure that SROs enforce compliance by their members with the respective SRO's rules, and the federal securities laws, rules, and regulations.594 Second, a facility of an SRO is subject to the rule filing requirements of Section 19(b) of the Exchange Act.595
-In response to the commenter who expressed concern that the plan sponsors would use the central repository to generate revenue through penalties,596 the Commission notes that any penalty provisions must be provided in the NMS plan submitted to the Commission for its consideration, or in a future amendment to the NMS plan, if the NMS plan is approved. The Commission will review the NMS plan submitted for its consideration, which also will be subject to public notice and comment, to assure itself that the NMS plan is designed to be applied fairly and otherwise in a manner consistent with the Exchange Act. The Commission expects that the NMS plan's penalty provisions would provide sufficient detail regarding the circumstances in which any penalties would apply, and any restrictions on how payments of such penalties may be used, to permit the Commission to determine that such penalty provisions are fair and consistent with the Exchange Act. As the central repository will be a facility of the plan sponsors, the rules governing it must be consistent with the Exchange Act.597 In addition, future amendments to the penalty provisions would either be reviewed as an amendment to the NMS plan, under Rule 608 of Regulation NMS, or, because the central repository is a facility of the SROs, as a proposed rule change of the central repository under Section 19 of the Exchange Act.598 Additionally, the Commission has the authority to review any action taken or failure to act by any person under an effective NMS plan, pursuant to Rule 608(d)(1) of Regulation NMS.599 Lastly, any penalty provisions included in the NMS plan approved by the Commission will be subject to the Commission's inspection and examination program of SROs to ensure they are implemented fairly in a manner consistent with the Exchange Act.600
-In response to the comments regarding the costs of the creation and maintenance of a central repository, the Commission notes that the costs would be highly dependent on the decisions the SROs make with respect to each of the areas in which the Commission has provided flexibility to the SROs in crafting the NMS plan to be submitted to the Commission for its consideration. For example, cost estimates could vary depending on whether the NMS plan requires unique order identifiers or permits "a series of order identifiers." Such cost estimates also could vary because the Rule does not specify details regarding, among other things, the security and confidentiality procedures of the central repository, the system for assigning customer identifiers, the format(s) of data reported to the central repository, the methods by which regulators will access data in the central repository, whether an annual independent evaluation will be required, how reportable events related to the same order will be linked, or how errors will be processed. Such information will be known only after the filing of the NMS plan and, thus, the Commission believes it is appropriate to defer consideration of such costs until the NMS plan is submitted for its consideration. Once it is submitted, the Commission will be able to use this information in determining whether to approve the NMS plan.
-The Commission notes that other provisions of the Rule that are applicable to the central repository, discussed below, have been modified from the proposal, including provisions relating to the format in which the data may be reported,601 and to the security and confidentiality of the consolidated audit trail data.602
-b. Receipt, Consolidation, and Retention of Data
-1. Audit Trail Data
-In addition to providing for the creation and maintenance of the central repository, Rule 613(e), as proposed, also would have required the central repository to receive, consolidate, and retain all data reported by the SROs and their members pursuant to the Rule and the NMS plan.603
-The Commission is adopting, substantially as proposed, the provisions in Rule 613(e) regarding the responsibility of the central repository to receive, consolidate, and retain the audit trail data, but with a few modifications to reflect changes the Commission made to other sections of Rule 613.604
-The first change to Rule 613(e)(1) is a conforming change to the modification in adopted Rule 613(c)(2) that permits the NMS plan to provide that audit trail data be reported to the central repository either in a uniform electronic format, or in a manner that would allow the central repository or a third party to convert the data to a uniform electronic format for consolidation and storage.605 Given the need for cross-market comparability and ready access,606 the adopted Rule requires that, to the extent the NMS plan does not require that data be reported to the central repository in a uniform electronic format, the central repository must convert the data to a uniform electronic format for consolidation and storage.607 The Commission notes that, regardless of whether the NMS plan submitted to the Commission for its consideration elects to have the central repository normalize audit trail data reported, the Rule requires the central repository to consolidate and store the data in a uniform electronic format.
-The second change to Rule 613(e)(1) reflects the Commission's view that, while it is appropriate to provide the plan sponsors with the flexibility to determine how an order will be identified, audit trail data must be stored in the central repository in a manner that will allow order information to be retrieved in a timely and accurate fashion. Accordingly, adopted Rule 613(e)(1) requires that the audit trail data consolidated in the central repository be stored "in a form in which all events pertaining to the same originating order are linked together in a manner that ensures timely and accurate retrieval . . . for all reportable order events for that order." The Commission notes that, regardless of whether the NMS plan submitted to the Commission for its consideration elects to use a series of order identifiers or a unique order identifier, the Rule requires the central repository to be able to link together all reporting events pertaining to an order.
-In looking ahead to considering the overall cost of creating, implementing, and maintaining a consolidated audit trail in connection with the NMS plan, the Commission recognizes that, in addition to the costs to SRO members who would be required to record and report data to the central repository, there also will be costs associated with creating and maintaining a central repository. These costs may include: (1) the purchase and maintenance of servers and systems to receive, consolidate, and retain audit trail data, and to allow access to and searches on the data; (2) the development of policies and procedures relating to the timeliness, accuracy, completeness, security, and confidentiality of the data collected; (3) the development and maintenance of a comprehensive information security program for the central repository; and (4) dedicated staff, including a CCO.
-2. NBBO Information, Transaction Reports, and Last Sale Reports
-In addition to receiving, consolidating, and retaining audit trail data reported pursuant to Rule 613(c), Rule 613(e)(5), as proposed, would have required the central repository to collect and retain, on a current and continuing basis and in a format compatible with the information collected pursuant to Rule 613(c)(7),608 the NBBO information for each NMS security,609 as well as transaction reports reported pursuant to an effective transaction reporting plan filed with the Commission pursuant to, and meeting the requirements of, Rule 601 of Regulation NMS under the Exchange Act.610 In addition, last sale reports reported pursuant to the OPRA Plan filed with the Commission pursuant to, and meeting the requirements of, Rule 608 of Regulation NMS under the Exchange Act would have been required to be collected and retained.611
-One commenter expressed its belief that, "[a]s in the case of the current OATS system, execution data provided to the consolidated audit trail should identify where the trade was publicly reported and have a common identifier that links the audit trail execution reports for the buy and sell orders to the public trade report."612 The Commission believes that the proposed requirement for the central repository to collect and retain NBBO information, as well as transaction reports and last sale reports,613 would facilitate the ability of SRO and Commission staff to search across order, NBBO, and transaction databases. Moreover, inclusion of NBBO information would permit regulators to compare order execution information to the NBBO information readily as all of the information will be available in a compatible format in the same database. This information also would be available to the Commission to assist in its oversight efforts.
-Additionally, requiring the central repository to collect and retain the NBBO and transaction information in a format compatible with the order execution information would aid in monitoring for regulatory compliance (e.g., Rule 201 of Regulation SHO). Also, this information would be useful in conducting market analyses (e.g., how order entry affects NBBO prices and depth). The Commission believes that the requirement that the central repository collect transaction reports reported pursuant to the CTA, UTP, and OPRA plans614 would allow regulators to more efficiently evaluate certain trading activity. For example, a pattern of unreported trades may cause the staff of an SRO to make further inquiry into the nature of the trading to determine whether the public is receiving accurate and timely information regarding executions and that market participants are continuing to comply with the trade reporting obligations under SRO rules. Similarly, a pattern of unreported transactions could be indicia of market abuse, including failure to obtain best execution for customer orders or possible market manipulation. The Commission believes that having the quotation and transaction information currently collected with respect to NMS securities in the same data repository – and in a compatible format – as part of the consolidated audit trail would enhance regulatory efficiency when analyzing the data.
-After considering the comment on this provision,615 the Commission is adopting proposed Rule 613(e)(5)(ii) and (e)(5)(iii) (renumbered as Rule 613(e)(7)(ii) and (e)(7)(iii)), as proposed, and the requirement of proposed Rule 613(e)(5)(i) (renumbered as Rule 613(e)(7)(i)) for the NMS plan to require the central repository to collect and retain NBBO information for each NMS security substantially as proposed, but is clarifying that the NBBO information must include size and quote condition.616 NBBO size information is integral to determining whether best execution and order handling requirements were satisfied for a particular order because these requirements depend on the relationship between the size of the order and the displayed size at the NBBO. NBBO quote condition information is integral to determining whether or not quotes are immediately accessible. For example, quote condition information that identifies whether the quote reflecting the NBBO was automated, and therefore subject to trade-through protection, or manual617 may be an important consideration in determining whether the duty of best execution was satisfied. The NBBO price, size, and quote condition is used by regulators to evaluate members for compliance with regulatory requirements, such as the duty of best execution or Rule 611 of Regulation NMS.618 The Commission acknowledges that there will be costs to the central repository to purchase and to retain NBBO information, transaction reports, and last sale reports. However, the Commission believes that the benefits associated with having such information included in the central repository justify the costs to the SROs of requiring that they include this in the NMS plan submitted to the Commission for its review.
-3. Retention of Information
-As proposed, Rule 613(e)(6) would have provided that the NMS plan require the central repository to retain the information collected pursuant to Rule 613(c)(7) and (e)(5) in a convenient and usable standard electronic data format that is directly available and searchable electronically without any manual intervention for a period of not less than five years. The information would have been required to be available immediately, or, if immediate availability could not reasonably and practically be achieved, a search query would have been required to begin operating on the data not later than one hour after the search query is made.619
-One commenter suggested that the Commission modify the time standard for the availability of older data to a next day (or later) standard, as the need for regulators to have immediate access to the data diminishes over time. The commenter stated that a requirement that the data be made available the next day, or after another longer period of time, would be less burdensome on the consolidated audit trail system and less costly, while still meeting the needs of regulators.620 Another commenter believed that there could be difficulties in querying and analysis because the proposal did not specify how the data would be stored in the central repository.621
-In response to the commenters' concerns, the Commission is modifying the proposed Rule. Specifically, Rule 613(e)(8) (renumbered from proposed Rule 613(e)(6)) provides that "[t]he national market system plan submitted pursuant to this section shall require the central repository to retain the information collected pursuant to [Rules 613(c)(7) and (e)(7)] in a convenient and usable standard electronic data format that is directly available and searchable electronically without any manual intervention for a period of not less than five years." The adopted Rule does not require, as was proposed, that the consolidated audit trail data be available immediately, or if immediate availability cannot reasonably and practically be achieved, any search query must begin operating on the data not later than one hour after the search query is made.622
-The Commission believes that it is unnecessary for the Rule to require a timeframe within which consolidated audit trail data must be available or a timeframe for when a search must begin after the query is made because, as discussed below,623 the Rule, as adopted, includes a provision that requires the NMS plan to specifically address the "time and method by which the data in the central repository will be made available to regulators, in accordance with paragraph (e)(1) of this section, to perform surveillance or analyses, or for other purposes as part of their regulatory and oversight responsibilities."624 The Commission will consider the response to this provision contained in the NMS plan submitted by the plan sponsors to the Commission, regarding the time and method by which the data in the central repository can be accessed and used by regulators as part of their regulatory and oversight responsibilities – which would encompass queries – as it evaluates the NMS plan. The Commission believes this provision provides flexibility to the SROs to devise an access requirement that meets the needs of regulators in a cost-effective and timely manner, 625 rather than establishing a strict deadline for all data to be accessible from the central repository.
-c. Timeliness, Accuracy, Integrity, and Completeness of the Consolidated Data
-As proposed, Rule 613(e)(4)(ii) would have required the NMS plan to include policies and procedures, including standards, for the plan processor to ensure the timeliness, accuracy, and completeness of the data provided to the central repository. In addition, proposed Rule 613(e)(4)(iii) would have required that the NMS plan include policies and procedures, including standards for the plan processor to reject data provided to the central repository that does not meet these validation parameters, and for SROs and members to re-transmit corrected data. Finally, proposed Rule 613(e)(4)(iv) would have required that the NMS plan include policies and procedures, including standards, to ensure the accuracy of the consolidation by the plan processor of the data provided to the central repository.
-The Commission requested comment on these proposed requirements.626 The Commission asked if this approach was practical to ensure the integrity of the data, and whether there were alternative methods that would achieve the same purpose that would be preferable. The Commission also requested comment on how much latency would result from a validation procedure.
-The Commission received comments focusing concern on the potential for errors in the consolidated audit trail and the negative effects of errors in the consolidated audit trail.627 One commenter stated that the "key principles [that] best ensure that the regulatory goals of the consolidated audit trail are met in a cost efficient manner" include a system that "avoids data quality issues through data validation safeguards and a structure that reads data as close to the point of origin as possible to avoid data translation errors when data is processed through intermediary applications."628 Another commenter stated that "the CAT facility would also need a mechanism to identify and correct data that was inaccurate."629 Another commenter noted that, "if any other protocol [other than FIX] is used a translation is required to transform data into a different protocol. This introduces error and offers the potential for manipulation of the data. Using FIX means the SEC is looking at the original format of the data."630
-As a point of reference, summary data about OATS provided by FINRA to Commission staff indicates that approximately 0.25% of the intra-firm data reported daily by members contains errors. 631 Additionally, according to FINRA, when errors relating to the linkage of order reports are detected, members have no obligation to correct the errors.632 As a result, approximately 1-2% of each day's recorded events remain unmatched (i.e., multi-firm events, such as order routing, that cannot be reconciled).633 This deficiency in the OATS process diminishes the completeness and overall usefulness of the audit trail OATS creates.
-In a comment letter, FINRA discussed the challenge of obtaining accurate audit trail information if the data was required in real time, and it noted the actions it undertakes to ensure the accuracy and completeness of its audit trail data and minimize errors.634 FINRA stated that, "to ensure the integrity of OATS data submitted, FINRA performs over 152 separate OATS data validations on each order event, each of which can result in OATS data submissions being rejected and generating an error message.635 As a result, FINRA performs over 40 billion separate checks each day to ensure OATS data conforms to all applicable specifications.636 Members are then required by rule to repair and resubmit such data that did not meet OATS specifications.637 Although members' OATS compliance rates are very high on average, almost 425,000 reports per day, on average, are rejected and must be corrected.638 Accordingly, to use audit trail data before such validations have been performed may result in a severely distorted picture of trading and interfere with effective oversight."639
-With respect to mechanisms to ensure compliance by SROs with the requirements of the plan, one commenter stated that "Commission rules should focus on the reasonable design of systems, processes and procedures to fulfill their objectives and patterns and practice of noncompliance rather than looking to any failure as a rule violation. This is particularly important in the context of data errors or similar matters."640
-Finally, another commenter believed that "major market participants" should retain "detailed information of all network packets and trade data at both the ingress and egress of their infrastructure."641 This commenter believed that this information would not need to be forwarded to "any audit authority" but explained that such information could be used by regulators in the event a "denial of service" attack were to occur at a network level to slow market activities or hinder the flow of market information. This commenter further explained that having this information would "greatly improve confidence in the integrity of data and act as a further deterrence for fraudulent activity."642
-After consideration of the comments received, the Commission is adopting Rule 613(e)(4)(ii) substantially as proposed. Thus, the NMS plan must have policies and procedures, including standards, to ensure the timeliness, accuracy, and completeness of the data received. The Commission believes that audit trail data that is timely, accurate, and complete is critical to the usefulness and effectiveness of Rule 613. However, the Commission is adding the term "integrity" to the list of items that the policies and procedures adopted by the plan sponsors, as set forth in Rule 613(e)(4)(ii), must address.643 The addition of "integrity" is designed to help emphasize that data should not be subject to benign or malicious alteration, so that such data would be consistent and reliable at each point of transmission throughout its lifecycle (i.e., transmission from the SRO or member to the central repository, data extraction, transformation and loading at the central repository, data maintenance and management at the central repository, and data access by regulators). The Commission believes that the integrity of the audit trail data is critical to the usefulness and effectiveness of the consolidated audit trail.
-The Commission also is adopting Rule 613(e)(4)(iv), renumbered as Rule 613(e)(4)(iii), as proposed, which provides that the NMS plan submitted shall include policies and procedures, including standards, to be used by the plan processor to ensure the accuracy of the consolidation by the plan processor of the data reported to the central repository. The Commission believes that policies and procedures, including standards, to be used to ensure accuracy of the consolidated data are important and necessary because the benefits of ensuring that data is accurately reported to the central repository would be lost if the consolidation process is not as equally robust. The regulatory benefits of a consolidated audit trail are therefore based, in part, on the timeliness, accuracy, completeness, and integrity of the data ultimately available to regulators from the central repository.
-As described above in Sections III.B.1.f. and III.B.1.d.iv., the adopted Rule provides the SROs with more flexibility than the proposed Rule in developing (a) the format(s) of data to be reported to the central repository, and (b) the methods by which order identifiers will be used to link reportable events. Accordingly, the Commission expects the policies and procedures included in the NMS plan submitted to the Commission for its consideration to apply to both the transmission of audit trail data from SROs and their members to the central repository, and the consolidation and retention of that data, and other information collected pursuant to the Rule, by the central repository, including, but not limited to, any normalization or conversion of the data to a uniform electronic format, and procedures for how reportable events are accurately linked. The Commission believes that it is critical to the usefulness of the consolidated audit trail that the SROs and their members report data in a manner that is accurate and complete, and that the central repository takes any and all appropriate measures to consolidate and retain that data in the same manner. To the extent the data is not accurate or complete, the ability of SRO and Commission staff to utilize the data to accomplish the goal of the consolidated audit trail will be compromised.644
-In light of the comments the Commission received that noted the concern about the potential for errors in the consolidated audit trail, as well as the impact such errors may have on the consolidated audit trail,645 the Commission is revising Rule 613(e)(4)(iii) as proposed (renumbered as Rule 613(e)(6)(i)). Specifically, Rule 613(e)(6)(i) requires the NMS plan submitted to the Commission for its consideration to "[s]pecify a maximum error rate to be tolerated by the central repository for any data reported pursuant to Rule 613(c)(3) and (c)(4); describe the basis for selecting such maximum error rate; explain how the plan sponsors will seek to reduce the maximum error rate over time; describe how the plan will seek to ensure compliance with such maximum error rate and, in the event of noncompliance, will promptly remedy the causes thereof."646 Rule 613(e)(6)(ii) states that the NMS plan shall "[r]equire the central repository to measure the error rate each business day and promptly take appropriate remedial action, at a minimum, if the error rate exceeds the maximum error rate specified in the plan." Rule 613(e)(6)(iii) and (iv) provide that the NMS plan shall "[s]pecify a process for identifying and correcting errors in the data reported to the central repository pursuant to [Rule 613(c)(3) and (c)(4)], including the process for notifying the national securities exchanges, national securities associations, and members who reported erroneous data to the central repository about such errors, to help ensure that such errors are promptly corrected by the reporting entity, and for disciplining those who repeatedly report erroneous data; and . . . [s]pecify the time by which data that has been corrected will be made available to regulators."647
-As noted above, the Commission believes the availability of accurate consolidated data is a critical component of a useful and effective audit trail. Ideally, there would be no errors in the recording or reporting of any audit trail data element, and every data element of every reportable event would be accurately recorded by the SROs and their members, and then accurately reported to the central repository under Rule 613, resulting in a consolidated audit trail that reflects all actions relating to every order in the market for securities. However, because the Commission understands that, to some extent, errors in reporting audit trail data to the central repository will occur, the Commission believes it is appropriate to adopt a provision in Rule 613 that requires the NMS plan to set forth the maximum error rate to be tolerated by the central repository in the reporting of audit trail data, as well as to specify a process for identifying and correcting such errors.648
-The Commission notes that the Rule leaves to the plan sponsors the ability to determine the acceptable maximum error rate, although the Rule does require that the NMS plan must explain the basis for selecting such rate. The Rule also requires the NMS plan submitted to the Commission for its consideration to set forth how the plan sponsors will seek to reduce such maximum error rate over time, thereby increasing the accuracy of audit trail data. Further, the Rule requires the NMS plan to have in place a means to ensure compliance with the maximum error rate so that SROs and their members are incentivized to comply with the maximum error rate, and to set forth a plan for promptly remedying the causes for any noncompliance.
-Since the Rule leaves many of the specific details regarding error rates and error-correction processes for the plan sponsors to determine, and because the accuracy and completeness of data ultimately received by regulators is of such significance to the effective use of a consolidated audit trail, the Commission, as well as the public, would likely consider such details very important in their overall evaluation of the submitted plan. Furthermore, given that the approval of any plan by the Commission would, in part, be based on expectations of maximum error rates, the Commission believes it is equally important for objective measures to be reported that track how well the plan is meeting such expectations. Thus, to ensure the accuracy of the audit trail data generally meets these expectations, Rule 613(e)(6)(ii) also requires that the error rate identified in the NMS plan be measured each business day and that remedial action be taken if, on any given day, the error rate exceeds the maximum error rate set forth in the NMS plan.649
-The Commission also believes it is appropriate to require the SROs to formulate a process for identifying and dealing with errors, and to require that the SROs or the members reporting erroneous data be notified that an error in reporting has occurred.650 In addition, the Commission believes it is appropriate to require the SROs to develop a process to help ensure that errors are promptly corrected by the reporting SRO or member. The Commission understands that requirements similar to these are currently implemented by FINRA as part of their OATS process, though cross-firm errors, such as those leading to irreconcilable or unmatched routes, are not generally corrected under the OATS process.651 The Commission further believes that disciplining SROs and members that repeatedly report erroneous audit trail data, as required by Rule 613(e)(6)(iii), is appropriate given the need to maintain an accurate consolidated audit trail for regulatory purposes. Finally, given that the NMS plan submitted to the Commission for its consideration is required to specify a process for correcting errors, the Commission also believes it is appropriate to require, pursuant to Rule 613(e)(6)(iv), that the NMS plan submitted to the Commission for its consideration specify the time by which data that has been corrected will be made available to regulators. In reviewing the NMS plan submitted for its consideration, the Commission will therefore be able to consider the time that uncorrected but consolidated data (which was reported to the central repository by 8: 00 a.m. Eastern Time on the trading day following the day such information was recorded) would be available for use by regulators, the expected error rate of this data, and the time at which a corrected version of this data would be made available to regulators. These three parameters will help inform regulators as to the potential effectiveness of starting different types of surveillance and monitoring activities at different times.652
-The Commission acknowledges there would be costs to the central repository associated with developing policies and procedures related to the timeliness, accuracy, integrity, and completeness of data, including, but not limited to, processes for identifying and correcting errors in the audit trail data received, and measuring the error rate on a daily basis. However, the size of these costs depends significantly on the specific details of the NMS plan submitted to the Commission for its consideration. Once the SROs submit the NMS plan to the Commission for its consideration specifying the details, parameters, and estimated costs of such processes, as well as the maximum error rate expected under such processes, the Commission and the public will be able to consider this information when determining whether to approve the NMS plan.
-d. Access to the Central Repository and Consolidated Audit Trail Data for Regulatory and Oversight Purposes
-As proposed, each national securities exchange and national securities association, as well as the Commission, would have had access to the central repository for the purposes of performing its respective regulatory and oversight responsibilities pursuant to the federal securities laws, rules, and regulations.653 This access would have included all systems of the central repository, and the data reported to and consolidated by the central repository.654 In addition, the Commission proposed to require that the NMS plan include a provision requiring the creation and maintenance by the central repository of a method of access to the consolidated data.655 This method of access would have been required to be designed to include search and reporting functions to optimize the use of the consolidated data. The Commission requested comment on whether it should allow the consolidated audit trail data to be made available to third parties, such as for academic research.
-One commenter supported limiting access to the consolidated audit trail data to the Commission and SROs for regulatory purposes, but suggested it would also be appropriate to share the data with the CFTC.656 Other commenters supported the idea of providing "anonymized" data for academic use, as long as appropriate controls were established to assure regulators and market participants that confidential trading information could not be revealed.657 Specifically, one commenter endorsed the use of the data "with appropriate safeguards" by academic researchers, explaining that it will "promote understanding of the markets," and "lead to better policy decisions and thus more fair and orderly markets."658 Similarly, another commenter also supported the use of the data by certain third parties and stated that "[a]ccess to real-world data can help research immensely."659
-The Commission also received a comment that argued for extending access to the consolidated audit trail data to certain individuals who have a fiduciary responsibility to shareholders of a company. This commenter explained that such access would allow them to audit all trading activity in the equity or other derivative securities of that company.660
-The Commission recognizes there may be certain benefits to the types of expanded access to data in the central repository that has been suggested by various commenters, but, for the reasons discussed below, it is adopting the provisions in Rule 613 regarding access by regulatory authorities at the SROs and the Commission to the systems operated by the central repository, and to the data received, consolidated, and retained by the central repository, substantively as proposed in Rule 613(e)(3), but with one clarification regarding the requirement for access by regulators.661 Specifically, Rule 613(e)(3), as adopted, provides that "[t]he national market system plan submitted pursuant to this section shall include a provision requiring the creation and maintenance by the plan processor of a method of access to the consolidated data stored in the central repository that includes the ability to run searches and generate reports." As proposed, Rule 613(e)(3) would have provided that the central repository must have a "reporting function." The Commission believes that this language is ambiguous and may have implied that the central repository was required to do more than respond to search queries. Accordingly, the Commission is replacing the requirement in proposed Rule 613(e)(3) that the central repository provide "search and reporting functions" with the requirement that there be "the ability to run searches and generate reports." The change in language from that contained in the Rule, as proposed, is not intended to change the substance of the requirement.
-In response to the commenter who suggested sharing data with the CFTC, the Commission notes that it has shared information with the CFTC in the past and that it intends to continue sharing information when the situation so warrants. The Commission notes that, among other arrangements, it currently has information-sharing agreements with other regulators. The Commission also agrees with commenters that there may be benefits to allowing academics or other third parties to have access to data collected by the central repository. Academic and other third-party analyses are helpful to the Commission in performing its own evaluation of the economic costs and benefits of regulatory policy. The Commission also notes that one commenter believes that the ability of companies to detect manipulative trading activity in their securities could be enhanced if certain individuals, who have a fiduciary responsibility to shareholders, were given access to limited consolidated audit trail data. However, because the creation and implementation of the consolidated audit trail is in the formative stage, and in light of commenters' concerns about the privacy and security of the information, the Commission believes it is premature to require that the NMS plan require the provision of data to third parties.
-Though the Commission is not specifying a particular process, or any details, regarding the mechanism(s) by which regulators will access data in the central repository, the Rule requires the SROs to provide such details and cost estimates in its NMS plan submitted to the Commission for its consideration.662 Further, as discussed below in Section III.C.2.c., the Commission is providing the SROs with detailed regulator use cases for how regulators would likely make use of the data in the central repository. These regulator use cases are designed to help the SROs respond with sufficient details in the NMS plan submitted to the Commission for its consideration so that, along with associated cost estimates also required to be provided by the SROs, the Commission and the public will be able to fully consider the NMS plan submitted.
-e. Confidentiality of Consolidated Data
-Rule 613(e)(4)(i), as proposed, would have required that the NMS plan include policies and procedures, including standards, to be used by the plan processor to ensure the security and confidentiality of all information reported to, and maintained by, the central repository. The plan sponsors and employees of the plan sponsors and central repository would have been required to agree to use appropriate safeguards to ensure the confidentiality of such data, and not to use such data other than for surveillance and regulatory purposes.663 As proposed, Rule 613 also would have required the NMS plan to include mechanisms to ensure compliance by the plan sponsors and their members with the requirements of the plan.664
-In the Proposing Release, the Commission solicited comments regarding what steps should be taken to ensure appropriate safeguards with respect to the submission of customer information, as well as the receipt, consolidation, and maintenance of such information in the central repository. The Commission requested comment on the issue of appropriate safeguards to be put in place by the SROs and the central repository to help ensure confidentiality. The Commission also asked whether the proposed Rule should: (1) require that SROs put in place specific information barriers or other protections to help ensure that data is used only for regulatory purposes; (2) provide for an audit trail of the SROs' personnel access to, and use of, information in the central repository to help monitor for compliance with appropriate usage of the data; and (3) include a requirement that the NMS plan include policies and procedures to be used by the plan processor to ensure the security and confidentiality of information reported to, and maintained by, the central repository be expanded to include the content of any searches or queries performed by the SROs or the Commission on the data.665
-Several commenters expressed concern about how to best ensure the confidentiality of the data collected.666 One commenter generally argued that safeguards for the audit trail data had not been sufficiently addressed in the Proposing Release.667 Another commenter recommended that the operator of the central repository and the SROs be required to implement security policies, processes, and practices consistent with industry best practices for the protection of sensitive information and that such policies, processes, and practices be audited on an annual basis by a third-party expert.668 Similarly, one commenter suggested that vendors also should implement best practices with regard to security, reliability, and integrity of data.669 Another commenter stated that SROs should be subject to the same privacy and data protection standards as those to which broker-dealers are subject, and that SRO members should not be held responsible, and be indemnified by the SROs, for any breaches of customer or firm information.670
-One commenter offered several specific recommendations for enhancing the security of audit trail information.671 This commenter suggested that the Commission should expressly state who would have access to the data, when they could access it, and how they could use it, and further recommended that all data sent to the central repository be encrypted, and that certain fields be "masked" or be subject to delayed end-of-day reporting.672 In addition, this commenter suggested that the Commission and each SRO should adopt a robust information security program, and that the Commission should explain how it intends to treat requests for audit trail data.673
-Another commenter suggested that the Rule more explicitly enunciate permissible and impermissible uses of the consolidated audit trail and suggested including a requirement regarding the SROs' personnel access to and use of audit trail data, as well as a commitment by the Commission to review each SRO with respect to the adequacy of information barriers.674 Similarly, a commenter suggested that access to audit trail data be limited to employees of regulators whose function is to monitor and surveil that market.675 This commenter supported the restriction that consolidated audit trail data only be used for regulatory purposes.676
-One commenter asked how and at what level customer data would be encrypted.677 This commenter listed specific aspects of data encryption that would need to be addressed, and noted that potential burdens could be associated with encryption.678 Finally, one commenter recommended that the Commission express its intention to withhold audit trail data from the public pursuant to Freedom of Information Act ("FOIA")679 exemptions.680
-The Commission considered the concerns expressed by commenters about the sensitivity of much of the information that will be consolidated by the central repository, and believes that maintaining the confidentiality of customer and other information reported to the central repository is essential. Without adequate protections, market participants would risk the exposure of highly-confidential information about their trading strategies and positions.
-The Commission notes that that it currently has controls and systems for its own use and handing of audit trail information. Nevertheless, given the sensitivity of certain information that will be produced by the consolidated audit trail – as well as the fact that such information should be more readily available and provided in a more usable format than existing audit trail information – the Commission intends to review the controls and systems that it currently has in place for the use and handling of audit trail information. The Commission further intends to evaluate whether any additional controls and systems may be required to adequately protect the sensitive information provided to it under the consolidated audit trail.681
-In addition, adopted Rule 613(e)(4)(i) requires that the NMS plan include policies and procedures that are designed to ensure implementation of the privacy protections that are necessary to assure regulators and market participants that the NMS plan provides for rigorous protection of confidential information reported to the central repository. Specifically, adopted Rule 613(e)(4)(i)(A) requires that "[a]ll plan sponsors and their employees, as well as all employees of the central repository, agree to use appropriate safeguards to ensure the confidentiality of such data and agree not to use such data for any purpose other than surveillance and regulatory purposes, provided that nothing in [Rule 613(e)(4)(i)(A)] shall be construed to prevent a plan sponsor from using the data that it submits to the central repository for regulatory, surveillance, commercial, or other purposes as otherwise permitted by applicable law, rule, or regulation." Further, in response to a comment,682 adopted Rule 613(e)(4)(i)(B) adds the requirement to the Rule, as proposed, that the plan sponsors adopt and enforce rules that: (1) require information barriers between regulatory staff and non-regulatory staff with regard to access and use of data in the central repository, and (2) permit only persons designated by plan sponsors to have access to the data in the central repository.683 In addition, the Commission is modifying the Rule, as proposed, to require that the plan processor must: (1) develop and maintain a comprehensive information security program, with dedicated staff, that is subject to regular reviews by the central repository's CCO, (2) require the central repository to have a mechanism to confirm the identity of all persons permitted to access the data, and (3) maintain a record of all instances where such persons access the data.684
-The Commission believes these provisions should create a framework for the SROs to establish a thorough and exacting process for helping ensure the continued effectiveness of the confidentiality safeguards. Further, the Commission believes these additional provisions are appropriate because they clarify the types of confidentiality safeguards that the NMS plan submitted to the Commission for its consideration must have to preserve the confidentiality of the information that is received, consolidated, and retained by the central repository. The provision requiring information barriers is designed to, for example, protect and prevent audit trail data, which are to be used only for regulatory purposes, from being communicated to any personnel at an SRO that are engaged in non-regulatory or business activities. Additionally, the Rule's requirement that policies and procedures submitted as part of the NMS plan provide that: (i) only persons designated by the plan sponsors have access to the central repository data, (ii) the plan processor have a mechanism to confirm the identity of all persons permitted access to the data, and (iii) the plan processor maintain a record of all instances where such persons access the data. These provisions are designed to assure regulators and market participants that only designated persons are allowed access to the consolidated audit trail data, and that the central repository will have a method to track such access. With respect to the commenter that suggested the Commission more explicitly enunciate permissible and impermissible uses of the consolidated audit trail,685 the Commission notes that any security and confidentiality provisions included in the NMS plan approved by the Commission will be subject to the Commission's inspection and examination program of SROs to ensure that they are implemented fairly in a manner consistent with the Exchange Act.686
-The Commission believes that an outline or overview description of the policies and procedures that would be implemented under the NMS plan submitted to the Commission for its consideration would be sufficient to satisfy the requirement of the Rule. The Commission believes it is important for the NMS plan submitted to the Commission to establish the fundamental framework of these policies and procedures, but recognizes the utility of allowing the plan sponsors flexibility to subsequently delineate them in greater detail with the ability to make modifications as needed.
-The Commission considered the comment that asked when and at what level customer information would be encrypted.687 The Commission notes that, while Rule 613 does not require that this information be encrypted, the Rule contains several safeguards, discussed in this section, to ensure the privacy and confidentiality of the audit trail data. Based on these provisions,688 the Commission believes that plan sponsors would need to make sure customer information is protected, which could be accomplished by data encryption, if they so choose. Additionally, the Commission notes that the unique customer identifier is only reported once to the central repository – by the broker-dealer that is either originating the order or is the original recipient of the order. Because the unique customer identifier does not travel with the order as it is routed to other market participants, only the originating broker-dealer should be able to determine the identity of the customer of the order. The Commission considered the comment that recommended that the Commission express its intention to withhold audit trail data from the public pursuant to FOIA.689 The adopted Rule places no affirmative obligations on the Commission to provide information to any third parties. Further, the Commission believes there are bases under FOIA to withhold customer information, including 5 U.S.C. 552(b)(4) (trade secrets, commercial or financial information), 5 U.S.C. 552(b)(6) (personal information affecting an individual's privacy), and 5 U.S.C. 552(b)(8) (records related to examinations of financial institutions). The Commission intends to assert all appropriate exemptions in response to a FOIA request for information related to the consolidated audit trail's customer information.
-The Rule, as adopted, also states that the NMS plan must require the SROs to adopt penalties for non-compliance with any policies and procedures of the plan sponsors or central repository, described above, with respect to information security.690 The Commission believes this provision is appropriate because it provides an incentive to SROs to comply with the central repository's information security program. The Commission encourages SROs to include in their comprehensive information security program developed and maintained by the plan processor provisions for notifying any customer or other market participant whose information may have been compromised by a security breach, so that appropriate remedial steps may be taken.
-Additionally, given the importance of the security of data consolidated in the central repository, and in response to the commenter who recommended an annual third-party audit of the security of the central repository,691 the Commission has added Rule 613(e)(5) to require the NMS plan submitted to the Commission for its consideration to address whether there will be an annual, independent evaluation of the security of the central repository and (1) if so, provide a description of the scope of such planned evaluation, and (2) if not, provide a detailed explanation of the alternative measures for evaluating the security of the central repository that are planned instead. As with most information technology systems, the central repository's system will include measures to assure regulators and market participants of the security of the system. An independent evaluation of the security of the central repository could aid the central repository in identifying and correcting potential areas of weakness or risk. While the Commission is leaving it to the plan sponsors to determine whether the NMS plan will require an annual audit, given the confidential nature of information that will be stored at the central repository, the Commission believes that the NMS plan submitted to the Commission for its consideration must, at a minimum, address whether such an audit is appropriate.
-The Commission also notes that, as discussed below,692 it is adding a specific provision that requires the NMS plan submitted to the Commission for its consideration to discuss the security and confidentiality of the information reported to the central repository.693 With this information, the Commission, as well as the public, will be able review in detail how the NMS plan proposes to ensure the security and confidentiality of such information in deciding whether to approve the NMS plan.
-The Commission believes that, collectively, these provisions are appropriate because of the confidential and commercially valuable information that the central repository will contain. The Commission believes that the purpose and efficacy of the consolidated audit trail would be compromised if the Commission, the SROs and their members could not rely on the confidentiality and security of the information stored in the central repository. The Commission acknowledges there would be costs associated with a comprehensive information security program, including, but not limited to, compensating a CCO and a dedicated staff, and establishing policies and procedures, as well as for an annual, independent evaluation of the central repository's security (if such an evaluation is required by the NMS plan submitted to the Commission for its consideration) or alternative measures (if such an evaluation is not). Once the SROs have submitted the NMS plan to the Commission that, as required, contains details about the security and confidentiality of the audit trail data, the Commission and the public will be able to consider this information when evaluating the NMS plan.
+This scenario illustrates the reporting requirement when an Industry Member executes a customer order as the result of negotiating a trade with another Industry Member (e.g. through a system such as OTCLink). For this case, Industry Member Broker 1 (initiator) is required to report the following:
+• The receipt of the customer order in a New Order event
+• The execution of the order (Trade event)
+Industry Member Broker 2 (respondent) must report the following to CAT:
+• A New Order event
+• The execution of the order (Trade event)
+All of the New Order and Trade events occurring within the negotiation process must have the negotiatedTradeFlag and negotiatedTradeSide present and marked properly.
+
+ 
+ 
+ 
pubdate: N/A effdate: N/A
- 3. Other Required Provisions of the NMS Plan
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Discussion, Elements of the NMS Plan, Other Required Provisions of the NMS Plan
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2.2.5. Trade as the Result of a Quote
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Trade Scenarios, Trade as the Result of a Quote
+ Compliance User: Industry Member
Keywords:
- Exchanges,
- Associations,
- Penalities,
- Members,
- Operation,
- Administration,
- NMS Plan,
+ Market Maker,
+ Industry Member Market Maker,
+ Industry Member OTCM,
- a. Compliance with the NMS plan
-1. Exchanges and Associations
-As proposed, Rule 613(h) would have provided that each plan sponsor shall comply with the provisions of an NMS plan submitted pursuant to the proposed Rule and approved by the Commission.694 In addition, the proposed Rule would have provided that any failure by a plan sponsor to comply with the provisions of the NMS plan could be considered a violation of the proposed Rule.695 The proposed Rule also would have required that the NMS plan include a mechanism to ensure compliance by the sponsors with the requirements of the plan.696
-One commenter expressed concern that there would be competitive implications if the NMS plan were to include provisions that would permit SROs to assess penalties against one another for non-compliance.697 This commenter recommended, instead, that the NMS plan include a "fee recoupment" provision so the plan administrator could recoup costs incurred as a result of an error by a particular SRO.698 The commenter maintained that a "fee recoupment" provision, coupled with the risk of Commission disciplinary action for a "pattern or practice" of non-compliance, would be a sufficient penalty.699
-After considering the comment received on the issue of compliance with the NMS plan by exchanges and associations,700 the Commission is adopting Rule 613(h) substantially as proposed, with a modification to Rule 613(h)(3) to specify that a mechanism to ensure compliance by the sponsors of the NMS plan with the requirements of the plan "may include penalties where appropriate" and a technical modification to proposed Rule 613(h)(1) and (2).701 The Commission believes that specifying that the mechanism to ensure compliance by the sponsors of the NMS plan may include a penalty provision where appropriate provides the plan sponsors with an appropriate tool – including potential disciplinary action – to help ensure compliance by SROs with the terms and provisions of the NMS plan.702 The Commission notes that a penalty provision could provide an incentive for each SRO to comply with all the provisions of the NMS plan because each SRO will seek to avoid incurring any penalty under the Rule. The incentive to avoid a penalty could also reduce the risk of non-compliance with the Rule. The Commission notes, however, that the adopted Rule does not mandate that the NMS plan's enforcement mechanism include penalties, as there might be other mechanisms to enforce or encourage compliance with the Rule, and the Commission believes that the SROs, in the first instance, should design such mechanisms in their role as plan sponsors. However, the Commission expects that if the SROs design compliance mechanisms that do not incorporate penalties, they would explain in the NMS plan how such mechanisms are expected to help ensure compliance by SROs with the terms and provisions of the NMS plan.703
-With respect to the comment concerning the potential competitive implications of allowing the plan sponsors to impose penalties against each other for non-compliance, the Commission notes that it will carefully review the NMS plan submitted for its consideration, including any proposed mechanisms to help ensure compliance with the NMS plan and the adopted Rule, to help ensure that penalty provisions, if any, are designed to be applied fairly and in a manner consistent with the Exchange Act.704 As the central repository will be a facility705 of the SROs, the rules governing it must be consistent with the Exchange Act. In addition, any future amendment to the penalty provisions applicable to the SROs would either be reviewed as an amendment to the NMS plan (effected through public notice and comment and taking into account the relevant considerations contemplated by Rule 613(a)(1)) or, because the central repository is a facility of the SROs, as a proposed rule change of the central repository under Section 19 of the Exchange Act.
-The Commission notes that the Commission's examination authority under Section 17 of the Exchange Act706 extends to the central repository because it is a facility of the SROs and, thus, the Commission will have the opportunity to inspect the central repository and its books and records for compliance with any penalty provisions set out in the NMS plan. Additionally, the Commission has the authority to review any actions taken under the NMS plan, pursuant to Rule 608(d)(1) of Regulation NMS,707 for burdens on competition, among other matters.708
-In response to the comment suggesting a "fee recoupment" provision in the NMS plan, the Commission notes that Rule 613(b)(4), as adopted, provides that "[t]he national market system plan submitted pursuant to this section shall include a provision addressing the manner in which the costs of operating the central repository will be allocated among the national securities exchanges and national securities associations that are sponsors of the plan, including a provision addressing the manner in which costs will be allocated to new sponsors to the plan." In this regard, to the extent a "fee recoupment" is a method for recouping costs incurred by the central repository as a result of an error in reporting to the consolidated audit trail, as stated by a commenter,709 the Commission notes that, pursuant to Rule 613(b)(4), the plan sponsors may, if they deem it appropriate, include a fee recoupment provision in the NMS plan submitted to the Commission for its consideration.710
-2. Members
-Proposed Rule 613(g) would have included provisions to subject members of each SRO to the requirements of Rule 613. Specifically, as proposed, the Rule would have required each SRO to file with the Commission, pursuant to Section 19(b)(2) of the Exchange Act711 and Rule 19b-4 thereunder,712 a proposed rule change to require its members to comply with the requirements of the proposed Rule and the NMS plan.713 Further, the proposed Rule directly would have required each member to (1) collect and submit to the central repository the information required by the Rule, and (2) comply with the clock synchronization requirements of the proposed Rule.714 The proposed Rule also would have required that the NMS plan include a provision that each SRO, by subscribing to and submitting the plan to the Commission, agrees to enforce compliance by its members with the provisions of the plan.715 Finally, the proposed Rule would have required the NMS plan to include a mechanism to ensure compliance with the requirements of the plan by the members of each SRO that is a sponsor of the NMS plan submitted pursuant to this Rule and approved by the Commission.716
-One commenter expressed the view that "enforcement of [the consolidated audit trail] . . . should be accomplished through a policies and procedures rule framework – similar to that of Regulation NMS. To enforce the rule from a strict liability perspective would simply be the wrong approach and would result in thousands of technical (non-material) violations, which is clearly not the intent of the rule."717
-After considering the comment regarding Rule 613's provisions on compliance with the Rule by members of the SROs, the Commission is adopting Rule 613(g) substantially as proposed, with technical modifications to proposed Rule 613(g). These technical modifications simplify the language of Rule 613(g). Adopted Rule 613(g) does not include the phrase that applied the requirements therein to each member of an SRO "that is a sponsor of the national market system plan submitted pursuant to this section and approved by the Commission." Because each SRO will be a member of the NMS plan approved by the Commission, it is not necessary to include the deleted language.
-In addition, the Commission modified Rule 613(g)(2) as proposed to provide that, "[e]ach member of a national securities exchange or national securities association shall comply with all the provisions of any approved national market system plan applicable to members." This change requires members to comply with all applicable provisions of the NMS plan as approved by the Commission instead of with the specific provisions contained in the Rule relating to recording and reporting data and clock synchronization since the requirements contained in the NMS plan may differ or be more specific than the requirements stated in the Rule.
-To be in compliance with the NMS plan, members must record and report all data elements required by the NMS plan within the time specified in the plan. To this end, the plan sponsors must develop a way to ensure that each member that takes action with respect to an order (e.g., originates, receives, routes, modifies, cancels or executes an order) records and reports all required elements associated with a reportable event, as the plan sponsors must also develop a mechanism to address any lapses in compliance with the NMS plan with a goal of ensuring the central repository is receiving a complete record of the life of an order.
-The Commission does not agree with the commenter that believed that enforcement of the consolidated audit trail will necessarily "result in thousands of technical (non-material) violations, which is clearly not the intent of the rule." 718 The Commission notes that the adopted Rule does not address the means of achieving compliance with the requirements of the consolidated audit trail. Rather, adopted Rule 613(g) simply provides that the SROs must submit proposed rule changes to require their members to comply with the requirements of an NMS plan approved by the Commission.
-The Commission acknowledges there would be costs to the SROs for filing with the Commission proposed rule changes to require their members to comply with Rule 613 and the NMS plan approved pursuant thereto. The Commission, however, believes that the Rule should include these rule filing requirements for the reasons discussed above.
-b. Operation and Administration of the NMS Plan
-Proposed Rule 613(b) sets forth requirements concerning the operation and administration of the NMS plan. As proposed, Rule 613(b)(1) would have required that the NMS plan include a governance structure to ensure fair representation of the plan sponsors and provisions governing the administration of the central repository, including the selection of a plan processor. Rule 613(b)(2), as proposed, also would have required the plan sponsors to include in the NMS plan a provision addressing the requirements for the admission of new sponsors to the plan and the withdrawal of sponsors from the plan. In addition, proposed Rule 613(b)(3) would have required the NMS plan to include a provision addressing the percentage of votes required by the plan sponsors to effectuate amendments to the plan, and proposed Rule 613(b)(4) would have required that the plan sponsors develop a process for allocating among themselves the costs associated with creating and maintaining the central repository, including a provision addressing the manner in which such costs would be allocated to sponsors who join the plan after it has been approved.
-Finally, proposed Rule 613(b)(5) would have required the NMS plan to require the appointment of a CCO to regularly review the operation of the central repository to assure its continued effectiveness in light of market and technological developments, and make any appropriate recommendations to the plan sponsors for enhancement to the nature of the information collected and the manner in which it is processed. In the Proposing Release, the Commission stated that it expected the CCO would establish the procedures necessary to ensure that the operations of the central repository keep pace with technical developments and to make any necessary upgrades or changes to the central repository to maintain its efficacy.719
-The Commission received comments addressing the proposed requirements for operation and administration of the NMS plan.720 One commenter suggested that the NMS plan should contain a voting mechanism that requires less than unanimity, and with an effective tie breaking mechanism.721 This commenter also recommended that the governance structure "limit the ability of individual SROs to make modifications on a unilateral basis that could escalate costs by forcing the operator and firms to absorb costs that do not advance the interests of investors."722
-Two commenters expressed views on the selection and role of the plan processor.723 One suggested that the SROs should select the processor through a "request for proposal."724 Another commenter generally believed that the allocation of plan processor costs warranted more consideration.725 This commenter expressed concern with regard to the SROs owning the plan processor, noting in particular that unanimous consent would be required for all board actions.726 This commenter stated that the plan processor alone should handle rulemaking and compliance, subject to oversight by an "industry group."727 Another commenter stated that, "[r]egarding the governance of the national market system plan [contemplated] by the proposal, we wish to reiterate that the SEC should provide the broker-dealer industry with an official 'seat at the table' alongside the SROs, so that [the broker-dealers] can review and comment on system requirements as they are being developed and vote on plan amendments going forward."728
-After considering these comments, for the reasons discussed below, the Commission is adopting Rule 613(b) as proposed, but with the addition of two new requirements. Specifically, in addition to the provisions included in the proposed rule,729 Rule 613(b), as adopted, provides that the national market system plan submitted shall include: "a provision requiring the plan sponsors to provide to the Commission, at least every two years after effectiveness of the national market system plan, a written assessment of the operation of the consolidated audit trail . . ., [and] an Advisory Committee . . . includ[ing] representatives of the member firms of the plan sponsors."730
-The requirement that the NMS plan require the appointment of a CCO to regularly review the operation of the central repository and make any appropriate recommendations for enhancements731 is one method to facilitate the consolidated audit trail's ability to evolve over time in terms of technology, functionality, and accuracy. Adopted Rule 613(b)(6) supplements this requirement by now requiring that the NMS plan "include a provision requiring the plan sponsors to provide to the Commission, at least every two years after effectiveness of the national market system plan, a written assessment of the operation of the consolidated audit trail. Such document shall include, at a minimum: (i) [a]n evaluation of the performance of the consolidated audit trail including, at a minimum, with respect to data accuracy (consistent with [Rule 613(e)(6)]), timeliness of reporting, comprehensiveness of data elements, efficiency of regulatory access, system speed, system downtime, system security (consistent with [Rule 613 (e)(4)]), and other performance metrics to be determined by the Chief Compliance Officer, along with a description of such metrics; (ii) [a] detailed plan, based on such evaluation, for any potential improvements to the performance of the consolidated audit trail with respect to any of the following: improving data accuracy; shortening reporting timeframes; expanding data elements; adding granularity and details regarding the scope and nature of Customer-IDs; expanding the scope of the NMS plan to include new instruments, and new types of trading and order activities; improving the efficiency of regulatory access; increasing system speed; reducing system downtime; and improving performance under other metrics to be determined by the Chief Compliance Officer; (iii) [a]n estimate of the costs associated with any such potential improvements to the performance of the consolidated audit trail, including an assessment of the potential impact on competition, efficiency, and capital formation; and (iv) [a]n estimated implementation timeline for any such potential improvements, if applicable."732 The Commission believes these provisions will help plan sponsors understand and evaluate any deficiencies in the operation of the consolidated audit trail and to propose potential enhancements to the NMS plan, as appropriate, taking cost effectiveness into consideration. These provisions also will allow the Commission to assess any such potential improvements, accounting for the considerations contemplated by Rule 613(a)(1), the specific requirements of the approved NMS plan, and any changes or additions to these requirements that the Advisory Committee, the SROs, or the Commission may wish to consider in the future. The Commission believes that such enhancements, if any, to the consolidated audit trail could improve the ability of the SROs and the Commission to conduct effective market oversight by keeping up with continually-changing technologies and markets, by, for example, allowing the SROs and the Commission to conduct their market oversight more quickly, accurately, and/or comprehensively, as well as possibly at lower costs. Similarly, the Commission believes that adding granularity and details regarding the scope and nature of Customer-IDs, adding new instruments, or including new trading or order activities could allow regulators to have a more complete picture of the markets and market participants, which could also lead to more effective market oversight. The Commission believes that performing this assessment no later than every two years is reasonable given the rapid speed at which the markets and related technologies are evolving. The Commission also believes that the written assessment, required by Rule 613(b)(6), will help inform the Commission about the likely feasibility, costs, and impact of, and the plan sponsors' approach to, the consolidated audit trail evolving over time. The Commission would expect to make the document publicly available on its website.
-In response to the comment requesting that the broker-dealer industry receive a "seat at the table" regarding governance of the NMS plan,733 the adopted Rule requires that the NMS plan submitted to the Commission for its consideration include a provision requiring the creation of an Advisory Committee, composed at least in part by representatives of the members of the plan sponsors, "to advise the plan sponsors on the implementation, operation and administration of the central repository."734 Further, the adopted Rule requires that the NMS plan submitted to the Commission for its consideration require that "[m]embers of the Advisory Committee shall have the right to attend any meetings of the plan sponsors, to receive information concerning the operation of the central repository, and to provide their views to the plan sponsors."735 Pursuant to the Rule, the NMS plan also shall set forth the term and composition of the Advisory Committee, which composition shall include representatives of the member firms of the plan sponsor.736 The Rule further provides that the plan sponsors may meet without the Advisory Committee members in executive session if, by affirmative vote of a majority of the plan sponsors, the plan sponsors determine that such an executive session is required.737 The Commission believes that, given the scope of the Rule, both in terms of the market participants that may be affected by the Rule and the breadth of the audit trail information that will be collected, it is important that the plan sponsors solicit input from their members because this could help inform the plan sponsors of any expected or unexpected operational or technical issues that may arise in the implementation of the Rule and/or the operation of the central repository, and help assure the Commission and market participants that any requirements imposed on SRO members will be accomplished in a manner that takes into account the burdens on SRO members. The Commission believes that the Advisory Committee could provide members of the SROs with a forum for informing the plan sponsors of any potential implementation or operational issues faced by them in connection with the consolidated audit trail. Plan sponsors also will be able to draw on the knowledge and experience of these members to help assure the Commission and market participants that any requirements imposed on SRO members will be accomplished in a manner that takes into account the costs to SRO members. The Commission also believes that an Advisory Committee could help foster industry consensus on how to approach and resolve possible issues that may be disputed, and approaches that may conflict, regarding operation of the consolidated audit trail. In this regard, the Commission encourages the plan sponsors to, in the NMS plan, provide for an Advisory Committee whose composition includes SRO members from a cross-section of the industry, including representatives of small-, medium- and large-sized broker-dealers.
-The Commission believes the requirement for the NMS plan to create the Advisory Committee, as well as the requirement in Rule 613(a)(1)(xi), discussed below, that requires the NMS plan to require a discussion of the process by which the plan sponsors solicited the views of their members on the creation, implementation, and maintenance of the consolidated audit trail, a summary of those views, and how the plan sponsors took those views into account when preparing the NMS plan, are responsive to commenters' views that more input by industry representatives, such as members of the SROs who are subject to the requirements of Rule 613, would be advantageous to the creation, implementation, and maintenance of the consolidated audit trail.738
-In addition, because the members of the Advisory Committee will have the right to attend all meetings of the plan sponsors (with the exception of executive sessions), to receive information concerning the operation of the central repository, and to provide their views to the plan sponsors, the governance process of the central repository will be more transparent to all market participants that will be affected by Rule 613. Further, the Commission believes the inclusion of SRO members on the Advisory Committee will increase the efficacy of the central repository. These market participants will have first-hand experience with the operation of the central repository, as they are required to report data to the facility, allowing them to provide informed input on any problems currently facing the central repository of which they are aware, and on any future actions that the central repository might or should take to address such problems. Finally, the Commission believes that an Advisory Committee structure that also permits the plan sponsors to meet in executive session without members of the Advisory Committee appropriately balances the need to provide a mechanism for industry input into the operation of the central repository, against the regulatory imperative that the operations and decisions regarding the consolidated audit trail be made by SROs who have a statutory obligation to regulate the securities markets, rather than by members of the SROs, who have no corresponding statutory obligation to oversee the securities markets.
-The Commission also considered the comment that provided other suggestions on the governance of the NMS plan and believes that the commenter's concerns regarding a unanimity requirement in the NMS plan have merit.739 Accordingly, the Commission urges the SROs to take into account the need for efficient and fair operation of the NMS plan governing the consolidated audit trail, and consider the appropriateness of a unanimity requirement and the possibility of a governance requirement other than unanimity, or even super-majority approval, for all but the most important decisions. The Commission believes that an alternate approach may be appropriate to avoid a situation where a significant majority of plan sponsors – or even all but one plan sponsor – supports an initiative but, due to a unanimous voting requirement, action cannot be undertaken.740 Therefore, the Commission believes the SROs should consider alternative governance structures that would ensure that decisions made by the SROs are both achieved and implemented efficiently, in the interest of advancing the Commission's mission. The Commission notes that the NMS plan submitted to the Commission for its consideration will be published for public comment, and industry participants will have an opportunity at that time to submit comments on the governance structures proposed by the plan sponsors. Further, the Commission believes, as discussed above, that unanimity need not be the standard for decision-making with regard to matters relating to the operation of the consolidated audit trail. Thus, the plan sponsors have flexibility under the Rule to determine the governance structures that will facilitate the effective and efficient oversight of the plan processor.
-In response to the comments regarding the selection and role of the plan processor,741 the Commission believes that the SROs, as the plan sponsors of the NMS plan governing the operation of the consolidated audit trail, should retain the authority to select and oversee the plan processor. The Commission believes that the SROs are in the best position to understand how the plan processor should operate and to address the need for changes when necessary. The SROs also have the flexibility under the Rule to consult the Advisory Committee, for example, to assist the SROs in their selection process and in their determination of whether modifications are necessary to address innovations in the industry if they believe that such participation is needed.
-The Commission acknowledges that, in addition to the many costs and burdens associated with the creation, implementation, and maintenance of a consolidated audit trail, with regards to the specific requirements discussed in this section, there would be costs to the SROs for appointing a CCO to the central repository, providing the Commission with the written assessment of the operation of the consolidated audit trail, and creating an Advisory Committee.742 For the reasons discussed above, the Commission believes these requirements are important to the efficient operation and practical evolution of the consolidated audit trail, and are responsive to many commenters' concerns about governance structure, cost allocations, and the inclusion of SRO members as part of the planning process. The Commission is therefore requiring the SROs to include these requirements in the NMS plan submitted to the Commission for its consideration. After the SROs submit the NMS plan, the Commission and the public will have more detailed information in evaluating the NMS plan.
-c. Surveillance
-As proposed, Rule 613(f) would have required each SRO subject to the Rule to develop and implement a surveillance system, or enhance existing surveillance systems, reasonably designed to make use of the consolidated audit trail data. The Rule, as proposed, also would have required each SRO to implement its new or enhanced surveillance system within fourteen months after the effectiveness of the NMS plan.743
-Commenters generally expressed support for the proposal's requirement that SROs implement surveillance systems that make use of the consolidated information.744 One commenter stated that the enhanced surveillance that could be achieved with the audit trail would likely attract additional trading volume to the U.S. markets and that the consolidated audit trail would benefit the SROs by permitting them to conduct surveillance themselves, thus "reducing their risks and their costs."745 Another commenter noted that the proposed consolidated audit trail would be a "critical first step toward consolidated market surveillance," and would lower costs for markets and their participants through economies of scale.746 A third commenter opined that a centralized database such as the consolidated audit trail is necessary to bring together data from exchanges, ECNs, and dark pools to properly regulate trading.747 However, one commenter maintained that a "Commission-mandated market regulator" would be costly for the securities industry and create the potential for a lack of surveillance innovation.748 A commenter recommended that the Commission monitor the surveillance systems and provide guidance to the SROs in establishing their surveillances.749 Finally, one commenter suggested that outsourcing surveillance to regulators could result in lower costs for markets, and recommended several specific security and analytical features for such a surveillance system.750
-After considering the comments, for the reasons discussed below, the Commission is adopting Rule 613(f) as proposed. Specifically, the Rule requires that each SRO develop and implement a surveillance system, or enhance existing surveillance systems, reasonably designed to make use of the consolidated information contained in the consolidated audit trail.751 The Commission believes that it is appropriate to require SROs to enhance their surveillance programs to make full use of the increased functionalities and the timeliness of the consolidated audit trail. Additionally, because trading and potentially manipulative activities could take place across multiple markets, the Commission supports efforts to coordinate surveillance among the SROs, such as through a plan approved pursuant to Rule 17d-2 under the Exchange Act,752 or through regulatory services agreements between SROs. In this regard, as commenters have noted, SROs could "outsource" surveillance efforts to another SRO, if there are efficiencies to be gained. With respect to the comment regarding the benefits to be gained by creating a "single market regulator," the Commission believes that mandating such an entity or structure goes beyond the scope of the Rule.753
-The Commission notes that it intends to review its own surveillance activities in light of the consolidated audit trail and intends to take steps to enhance its surveillance capabilities to take advantage of consolidated audit trail data. The Commission anticipates that such steps will be informed by – and may in turn help inform – the surveillance enhancement measures required to be taken by the SROs under adopted Rule 613(f).
-The Commission also is adopting Rule 613(a)(3)(iv) as proposed, which requires the NMS plan to require each SRO to implement its new or enhanced surveillance system within fourteen months after the effectiveness of the NMS plan. Since Rule 613(a)(3)(iii) will require the NMS plan to require SROs to begin reporting to the central repository within one year after effectiveness of the NMS plan, the Commission believes the two additional months provided by this timeframe is reasonable and sufficient to allow SROs to update their surveillance systems and allow for testing of new surveillances.
-The Commission acknowledges there would be costs to the SROs for developing and implementing surveillance systems, or enhancing existing surveillance systems, reasonably designed to make use of the consolidated audit trail. However, the Commission believes it may be possible for SROs to retire some of their existing, and perhaps less-efficient, audit trail and surveillance systems once the consolidated audit trail is operational. As discussed in Section III.C.a.iv. below, the adopted Rule requires the SROs to consider and discuss the potential for costs savings if other SRO systems, and their associated surveillances, were migrated to the consolidated audit trail.754 Once such information is submitted in the NMS plan submitted to the Commission for its consideration, the Commission and the public will be able to consider the information in evaluating the NMS plan.
+This scenario illustrates the reporting requirements to CAT when a Market Maker (and Industry Member Market Maker A) submits a displayed (bid) quote to an inter-dealer quotation system - Industry Member OTCM, another Market Maker (and Industry Member, Market Maker B) wants to trade at the displayed quote, sends a message through the inter-dealer quotation system, consummating in a trade.
+In Phase 2a, Industry Member Market Maker A is required to report the following event:
+• A Trade as a Result of a Quote event for execution against Market Maker B
+For this scenario, Industry Member Market Maker B must report the following event:
+• A New Order event
+• A Trade event for execution against Market Maker A
+For this scenario Industry Member OTCM must report the following event:
+• Quote Received event for the receipt of the quote from Market Maker A
+
+ 
+ 
+ 
pubdate: N/A effdate: N/A
- C. NMS Plan Process
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Discussion, NMS Plan Process
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Comments,
- Adopted Rule,
- Cost,
-
- As proposed, Rule 613(a)(1) would have required each SRO to jointly file on or before 90 days from approval of the Rule an NMS plan to govern the creation, implementation, and maintenance of a consolidated audit trail and a central repository. Section III.A. above discusses the use of an NMS plan to create, implement, and maintain a consolidated audit trail. This Section focuses on the process the SROs must follow when submitting to the Commission the NMS plan that satisfies the requirements discussed in Section III.B. above and the process the Commission will undergo when evaluating whether to approve the NMS plan.
-pubdate: N/A effdate: N/A
- 1. Comments on the NMS Plan Process
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Discussion, NMS Plan Process, Comments on the NMS Plan Process
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2.3. Fulfillment Scenario s
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s
+ Compliance User: Industry Member
+ Keywords:
+ pubdate: N/A effdate: N/A
+ 2.3.1. Representative Order Execution
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Representative Order Execution
+ Compliance User: Industry Member
+ Keywords:
+ This section will illustrate the Phase 2a reporting requirements for the execution of a customer/client order that is not required to be reported for public dissemination purposes and use of an Order Fulfillment, rather than a Trade Event, is required.
+In this scenario, Industry Member Broker A receives two customer orders to BUY XYZ at 10.01. Industry Member Broker A creates a representative order that will be used to fill two customer orders. The representative order is routed to an exchange where it is executed. Upon execution of the representative order, the Industry Member fills each of the customer orders on an agency basis.
+For this scenario, Broker A is required to report the following events to CAT for the customer orders:
+1) New Order events for the customer orders
+2) An Order Fulfillment for each customer order
+Broker A is required to report the following events to CAT for the representative order:
+1) New Order event for the representative order (flagged to indicate it represents customer orders, but no explicit linkage to the underlying orders)
+2) Routing the representative order to the exchange (Order Route event)
+Note that execution of the representative order is only reported by the exchange.
+Because this scenario involves an aggregation of two customer orders that are worked as a single representative order, this is a Phase 2c representative order scenario and linkage between the customer orders and the representative orders is not required. In Phase 2c, the representative order and the underlying customer orders must be linked.
+
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.3.2. Fill of a Single Order on a Riskless Principal Basis
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Fill of a Single Order on a Riskless Principal Basis
+ Compliance User: Industry Member
+ Keywords:
+ Order Route Event,
+ New Order event,
+
+ This scenario illustrates the CAT reporting requirements when an Industry Member fills an order as riskless principal.
+In this example, upon receipt of the customer order, the Industry Member sends a riskless principal or principal order to an exchange for execution, in order to satisfy the customer's order. The representative principal order is linked to the original customer order.
+
+ The Industry Member Broker 1 is required to report the following events to CAT:
+• The creation of the customer order as a New Order event
+• The creation of a riskless principal order with linkage to the original customer order (New Order event with aggregatedOrders field). As an alternative, the Industry Member may report a New Order event (for the principal order) without linkage to the customer order, and an additional New Order Supplement event
+• The route of the principal order to the exchange (Order Route event)
+• After the execution, the flip of the executed shares back to the customer order (an Order Fulfillment Event).
+The exchange will report the following:
+• The receipt of the order B routed from the Broker 1
+• The execution of order
+
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.3.3. Customer Order Internally Routed to Another Desk and Subsequently Executed Against a Firm Proprietary Account
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Customer Order Internally Routed to Another Desk and Subsequently Executed Against a Firm Proprietary Account
+ Compliance User: Industry Member
Keywords:
- Comments,
- NMS Plan,
- Analysis,
+ Order Internal Route event,
+ Trade Event,
- The Commission received several comments regarding how best to develop an NMS plan that will govern the creation and implementation of a consolidated audit trail, as well as the time needed to do so. Several commenters suggested that the Commission undergo a RFP or RFI process to create a consolidated audit trail.755 Specifically, one commenter suggested that the Commission outline a set of goals it intends to achieve through creation of a consolidated audit trail and allow an industry working group to determine the data elements that must be reported and other technical requirements.756 Another commenter opined that an RFP process would facilitate the identification of the costs and benefits of the audit trail, as well as the consideration of a wider range of technological solutions.757 Further, some commenters requested more specific information about the audit trail system to determine the best approach for implementing the consolidated audit trail.758
-Some of these commenters stressed that more time should be allotted for the planning and design of the NMS plan due to the comprehensive business analysis that would be needed in the initial stages of the consolidated audit trail.759 Commenters recommended extensive, "up-front business analysis,"760 explaining that if conducted "during the CAT plan development process, [they] are confident that issues would emerge earlier in the process, leading to more efficient and cost-effective solutions."761 The commenters believed that the business analysis would require many discussions involving the Commission, the SROs and teams comprising members of the securities industry.762 The commenters also suggested that the business analysis could include an RFI "to engage potential solution providers early in the process,"763 and stated that the time needed to perform the analysis to produce a "detailed blueprint for CAT"764 would be closer to six months,765 rather than the proposed 90 days.766 As a basis for their suggestions, one of the commenters provided a breakdown of the time and the types of work needed for FINRA's expansion of OATS to all NMS securities.767 This commenter noted that over one-third of the time required for the project was spent on conducting business analysis, and that one-third of the time was spent on project development.768
-In addition, some commenters noted that a consolidated audit trail could be implemented in a number of ways, and thus recommended that the Commission replace the specific system requirements of the proposed Rule with more general "end-user" requirements, perform an analysis of how existing audit trail systems do and do not meet the needs of regulators, and perhaps even engage in a formal RFP process.769
+This section will illustrate an example of CAT reporting when an Industry Member internally routes a customer order from the sales desk to the trading desk, and subsequently executes against a firm proprietary account. The sales desk and trading desk are separated by information barriers.
+
+ In this scenario, Industry Member Broker 1 must report the following events to CAT:
+• The receipt of the customer order in a New Order event
+• The internal route from the sales desk to the trading desk (Order Internal Route event)
+• The principal execution (Trade event)
+
+ 
pubdate: N/A effdate: N/A
- 2. Adopted Rule
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Discussion, NMS Plan Process, Adopted Rule
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2.3.4. Customer Order Internally Routed to Multiple Desks and Subsequently Executed
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Customer Order Internally Routed to Multiple Desks and Subsequently Executed
+ Compliance User: Industry Member
Keywords:
- Rule 613(a)(1),
- SRO,
- NMS Plan,
- Considerations,
- Features and Details,
- Analysis,
- Process,
- Implementation,
- Commission Review,
- Cases,
- Analyses related to Investigation,
- Analyses related to Monitoring,
- Order Tracking,
- Time Sequence,
- Database Security,
- Database Access,
- Submission,
- Extension of Time,
+ Program Trading Desk,
- After considering the comments regarding the NMS plan process, the Commission is adopting proposed Rule 613(a)(1) with modifications. First, the Rule now requires the SROs to provide much more information and analysis to the Commission as part of their NMS plan submission. These requirements have been incorporated into the adopted Rule as "considerations" that the SROs must address, and generally mandate that the NMS plan discuss: (1) the specific features and details of the NMS plan (e.g., how data will be transmitted to the central repository, and when linked data will be available to regulators); (2) the SROs' analysis of NMS plan costs and impact on efficiency, competition, and capital formation; (3) the process followed by the SROs in developing the NMS plan (e.g., solicitation of input from members of the SROs); and (4) the information about the implementation and milestones of the consolidated audit trail. Second, the Commission is furnishing further details about how it envisions regulators would use, access, and analyze consolidated audit trail data through a number of "use cases." Third, the Commission is extending the amount of time allowed for the SROs to submit the NMS plan from 90 days from the date of approval of Rule 613 to 270 days from the date of publication of the Adopting Release in the Federal Register. A discussion of these modifications and the "use cases" follows.
-a. NMS Plan Considerations
-As noted above,770 the Commission believes that the collective effect of the modifications and additions described above will be to significantly expand the solution set that could be considered by the SROs for creating, implementing, and maintaining the consolidated audit trail and provide the SROs with increased flexibility in how they choose to meet the requirements of the adopted Rule. Further, given these changes to the Rule discussed above and the wide array of commenter's views on how to best implement a consolidated audit trail,771 the Commission expects that the SROs will seriously consider various options as they develop the NMS plan to be submitted to the Commission for its consideration. The costs and benefits of the consolidated audit trail are highly dependent on the specific solutions proposed by SROs.
-Accordingly, as part of the multi-step process for developing and approving an NMS plan that will govern the creation, implementation, and maintenance of a consolidated audit trail, the Commission is deferring its economic analysis of the actual creation, implementation, and maintenance of a consolidated audit trail itself (in contrast to the costs of the actions the SROs are required to take upon approval of the adopted Rule772) until such time as it may approve the NMS plan submitted to the Commission for its consideration. In light of the expanded set of solutions that should be available as a result of the changes described above and to facilitate a more robust economic analysis, the adopted Rule now requires the SROs to provide much more information and analysis to the Commission as part of their NMS plan submission. The Commission is therefore requiring the SROs to discuss, as part of their NMS plan "considerations" that detail how the SROs propose to implement the requirements of the plan, cost estimates for the proposed solution, and a discussion of the costs and benefits of alternate solutions considered but not proposed.
-This additional information and analysis are intended to ensure that the Commission and the SROs have sufficiently detailed information to carefully consider all aspects of the NMS plan ultimately submitted by the SROs, facilitating an analysis of the extent to which the NMS plan would allow regulators to effectively and efficiently carry out their responsibilities. The NMS plan submitted by the SROs will be published for public comment and reviewed by the Commission for consistency with the Exchange Act and the rules thereunder. As a result, all interested persons, including market participants, regulatory authorities, and the general public, will have an opportunity to provide meaningful comments on the details and costs of the NMS plan submitted, which the Commission will review and consider.
-i. Features and Details of the NMS Plan
-The first six considerations the Rule requires the SROs to address in the NMS plan relate to the features and details of the NMS plan. These six considerations require the NMS plan to specify and explain the choices made by the SROs to meet the requirements specified in the Rule for the consolidated audit trail. The Commission intends to use the discussion of these considerations to evaluate the NMS plan submitted for its consideration and how well it meets the objectives described in Section II.B.2.
- -Rule 613(a)(1)(i) requires the NMS plan submitted to discuss "[t]he method(s) by which data is reported to the central repository, including, but not limited to, the sources of such data and the manner in which the central repository will receive, extract, transform, load and retain such data. . . ." The Rule also requires the NMS plan to discuss the basis for selecting such method(s).
-The Commission believes that requiring that the NMS plan discuss the method(s) by which data is reported to the central repository is important because the method for reporting data and the source of the data are significant to the effectiveness of the consolidated audit trail and could affect, and potentially enhance, the reliability and the accuracy of the data that is reported to the central repository.773 Discussing such method(s), as well as the basis for selecting such method(s), should help assure the Commission that the plan sponsors have considered the various alternatives and selected the method(s) that best achieves the objectives of the consolidated audit trail in a cost-effective manner.774 In addition, Rule 613(a)(1)(i) requires that the NMS plan describe how the central repository will receive, extract, transform, load and retain data because the Commission believes that this information is integral to a comprehensive understanding of the operation of the central repository proposed in the NMS plan.
- -Rule 613(a)(1)(ii) requires the NMS plan to address "[t]he time and method by which the data in the central repository will be made available to regulators, in accordance with [Rule 613(e)(1)] to perform surveillance or analyses, or for other purposes as part of their regulatory and oversight responsibilities."
-The time and method by which data will be made available to regulators are fundamental to the utility of the consolidated audit trail because the purpose of the consolidated audit trail is to assist regulators in fulfilling their responsibilities to oversee the securities markets and market participants.775 The NMS plan submitted should discuss these issues in detail, guided, in particular, by the issues and questions raised in the "Regulator Use Cases" described in Section III.C.2.b., below.
-The importance of this consideration was discussed in the Proposing Release.776 The Commission emphasized the necessity of the data being in a uniform electronic format so that regulators would be able, among other things, to effectively and efficiently detect and investigate illegal trading across markets, without having to spend valuable time and resources reconciling audit trail formatting differences in the data.777 In addition, the Proposing Release noted that requiring the order and trade data to be collected in one location in a single format would allow regulators ready access to the data for use in market reconstructions, market analyses, surveillance and investigations,778 as regulators could then retrieve the information that they need much faster than the current process of requesting data from multiple parties without having to reconcile disparate audit trail information. Also, in the Proposing Release, the Commission noted the importance of SRO regulatory staff having direct access to consolidated audit trail data.779 The Commission continues to believe that it is vital that regulators have ready access to the consolidated audit trail data in the central repository so that this information can be effectively and efficiently used in fulfilling their regulatory responsibilities.
- -Rule 613(a)(1)(iii) requires the NMS plan to address "[t]he reliability and accuracy of the data reported to and maintained by the central repository throughout its lifecycle, including transmission and receipt from market participants; data extraction, transformation and loading at the central repository; data maintenance and management at the central repository; and data access by regulators."
-The Commission believes the reliability and accuracy of the data is a critical aspect of the consolidated audit trail, because the usefulness of the data to regulators would be significantly impaired if it is unreliable or inaccurate. If the reliability and accuracy of reported data is not maintained by the central repository during the period it is required to be retained and throughout the various uses to which it may be put by regulators, then its value to regulators will be substantially diminished.
-Accordingly, the NMS plan submitted should discuss in detail, among other things, how the consolidated audit trail envisioned by the sponsors would be designed, tested and monitored to ensure the reliability and accuracy of the data collected and maintained by the central repository (e.g., during transmission from the SRO or member to receipt by the central repository,780 data extraction, transformation and loading at the central repository,781 data maintenance and management at the central repository,782 and data access by regulators783).
-The Commission notes that, when proposing Rule 613, it highlighted the importance of this consideration by emphasizing that the reliability and accuracy of the data are critical to the integrity and effectiveness of the consolidated audit trail.784 Indeed, Rule 613(e)(4)(ii), like the proposed Rule, specifically requires the plan sponsors to establish policies and procedures for the plan processor to ensure the timeliness, accuracy and completeness of the audit trail data reported to the central repository.
- -Rule 613(a)(1)(iv) requires the NMS plan to discuss "[t]he security and confidentiality of the information reported to the central repository."
-The Commission is including this consideration because it believes that keeping the data secure and confidential is crucial to the efficacy of the consolidated audit trail and the confidence of market participants. Exposure of highly-confidential information about the trading strategies and positions of market participants through a security breach, for example, could impact the confidence of the public in the central repository and in trading on the U.S. markets. The Commission understood the importance of security and confidentiality provisions when it proposed Rule 613(e)(4) to require the NMS plan to include policies and procedures, including standards, to be used by the plan processor to ensure the security and confidentiality of all information reported to, and maintained by, the central repository.785 Numerous commenters also noted the importance of maintaining the security and the confidentiality of the data collected pursuant to the proposed Rule.786
- -Rule 613(a)(1)(v) requires the NMS plan to address "[t]he flexibility and scalability of the systems used by the central repository to collect, consolidate and store consolidated audit trail data, including the capacity of the consolidated audit trail to efficiently incorporate, in a cost-effective manner, improvements in technology, additional capacity, additional order data, information about additional securities or transactions, changes in regulatory requirements, and other developments."
-The Commission believes that the flexibility and scalability of the systems used by the central repository are important to the effectiveness of the consolidated audit trail, and, accordingly, the Commission believes the NMS plan under Rule 613 should address potential "built-in" obsolescence that may arise as a result of the SROs' choice of systems or technology. For this reason, the NMS plan should address how, taking into consideration the costs and benefits, including the potential impact on competition, efficiency, and capital formation, the consolidated audit trail systems might be designed to accommodate: (1) potential growth in the trading volume or message traffic relating to NMS securities; (2) possible expansion to include other non-NMS securities;787(3) additional data fields that the SROs or the Commission might determine to require in the future (such as new order characteristics); and (4) potential technological developments that might allow the consolidated audit trail to be operated in a more timely, reliable, and cost-effective manner.
-As noted in the Commission's Concept Release on equity market structure,788 the market for trading securities has changed dramatically in recent years and, as technology advances, trading systems and trading strategies also change. The Commission believes that it is important for the consolidated audit trail to keep pace with market developments. It must be designed in a way that allows it to do so efficiently and in a cost-effective manner to assure regulators of its continued usefulness. Thus, the Commission has identified the flexibility and scalability of the systems used by the central repository to collect, consolidate and store audit trail data as a consideration that must be discussed in the NMS plan submitted to the Commission for its consideration. To sufficiently address this consideration, the Commission expects the NMS plan to describe in detail how the consolidated audit trail envisioned by the sponsors would be designed to accommodate additional message traffic for orders in NMS securities, how readily capacity could be expanded, and the existence of any capacity limits. The Commission also would expect the NMS plan to discuss in detail the extent to which the proposed consolidated audit trail could accommodate potential additional data elements, order characteristics, and other types of securities such as non-NMS securities, debt securities, primary market transactions in equity securities that are non-NMS securities, and primary market transactions in debt securities, how quickly this could be done, and whether any limits exist on the ability of the proposed system to accommodate these types of changes. Additionally, the Commission would expect the NMS plan to further discuss whether and how the consolidated audit trail could be upgraded to keep pace with improvements in technology, such as improvements to the speed of systems processing.
-The Commission believes these descriptions are important because, otherwise, what initially appears to be an effective and cost-effective NMS plan could become significantly less so over time as markets evolve and if, for example, order volumes increase, new order types are developed, and additional data elements or other types of securities, such as non-NMS securities, debt securities, primary market transactions in equity securities that are non-NMS securities, and primary market transactions in debt securities, are potentially incorporated into the consolidated audit trail.
-The Commission notes that issues relating to the potential flexibility and scalability of the consolidated audit trail were raised in the Proposing Release. For example, the Commission stated that, while the proposal was limited to NMS securities, the Commission ultimately intended the consolidated audit trail to cover secondary market transactions in other securities and information on primary market transactions.789 In fact, as discussed above, the Commission specifically proposed that the NMS plan contain provisions relating to the possible expansion of the consolidated audit trail to products other than NMS securities.790 In addition, in the Proposing Release, the Commission specifically noted its concerns with the lack of scalability of the existing EBS system and the fact that the volume of transaction data subject to reporting under the EBS system can be significantly greater than the system was intended to accommodate in a typical request for data.791
- -Rule 613(a)(1)(vi) requires the NMS plan to address "[t]he feasibility, benefits, and costs of broker-dealers reporting to the consolidated audit trail in a timely manner: (A) [t]he identity of all market participants (including broker-dealers and customers) that are allocated NMS securities, directly or indirectly, in a primary market transaction; (B) [t]he number of such securities each such market participant is allocated; and (C) [t]he identity of the broker-dealer making each such allocation."
-In the Proposing Release, the Commission stated that "it would be beneficial to provide for the possible expansion of the consolidated audit trail to include information on primary market transactions in NMS stocks" and required in proposed Rule 613 that the plan sponsors address such expansion in a document provided to the Commission within two months after effectiveness of the NMS plan.792 The Commission continues to believe, for the reasons set forth below, that a potential expansion of the consolidated audit trail to cover primary market transactions would be beneficial. Specifically, the Commission believes that the SROs should address – at the time of the submission of the NMS plan to the Commission, rather than as part of a later expansion plan – the feasibility, benefits, and costs of recording and reporting information about allocations of NMS securities in primary market transactions as part of the consolidated audit trail.
-As with the data sources discussed in Section II.A, the sources of information currently available to the Commission regarding allocations of NMS securities in primary market transactions are each limited in their ability to provide accurate, complete, accessible, and timely information.793 For example, while the Commission and FINRA can request information about allocations from the books and records of broker-dealers, such requests are unduly cumbersome for both regulators and market participants, potentially involving multiple time-consuming individual requests.794 Other sources of information about allocations of NMS securities in primary market transactions – including public sources795 – are also limited in certain respects.796
-In light of these limitations, data about the allocations of NMS securities in primary market transactions could also improve market analysis by the Commission and the SROs, which could in turn help better inform rulemaking and other policy decisions. Specifically, such data might aid the Commission and the SROs in better understanding the role of such allocations in the capital formation process. Combining this data with the secondary market data to be collected by the consolidated audit trail could allow regulators to calculate investor positions and when and how the investors receiving allocations sell their securities. Such data could also facilitate a better understanding of how securities are allocated in a primary market transaction, how allocations differ across broker-dealers and investors, and what types of investors are allocated securities. This analysis is virtually infeasible on a market-wide basis today because the data collection process using current sources of information is so cumbersome.
-In addition, if the consolidated audit trail included data regarding the allocations of NMS securities in primary market transactions, SROs could be better able to monitor for compliance with their rules related to such transactions.797 The data also could more broadly assist SROs in their examinations and investigations related to allocations in initial public offerings ("IPOs") and other primary market transactions by providing a richer data set for evaluating possible compliance issues. For example, the SROs could use IPO allocation information, combined with the secondary market transaction information in a consolidated audit trail, to run surveillance on whether sales in the IPO auction were marked accurately (i.e., "long" or "short") and in compliance with applicable requirements.798 Allocation data could also allow SROs to conduct surveillance for "red flags" they might develop regarding potential suitability issues related to customer allocations, as well as potentially improper allocations to customers (such as kickbacks).
-The Commission could also enhance its own examination and investigation processes if data regarding the allocations of NMS securities in primary market transactions were included in the consolidated audit trail. Without access to a single centralized database of allocations, Commission staff must rely on more limited data sources that generally enable only either broad-based sweeps or one-off investigations based on particularized suspicion of wrongdoing. Because the relevant data would be readily available for analysis, including information about allocations as part of the consolidated audit trail could facilitate the Commission's identification of particular risks and exam candidates. Other examinations undertaken by the Commission staff address whether employees of a regulated entity are in compliance with the rules applicable to their transactions related to primary market transactions. Having allocation information available before such an examination commences could allow staff to enhance their pre-examination research, better focus on the sources of potential violations, and ultimately foster more effective and efficient examinations.
-In investigations related to primary market transactions, the Commission staff generally must obtain data from underwriters post-transaction, which can take considerable time owing to the limitations on current sources of data noted above.799 Including data about the allocations of NMS securities in primary market transactions in the consolidated audit trail could enable investigations to proceed more efficiently and to more quickly assess whether alleged violations of various rules under the Exchange Act, such as Regulation M and Rule 10b-5, warrant investigation.800 In addition, the Commission believes that information about allocations could help the SROs and Commission investigate allegations of improper allocations, such as allocations subject to "spinning"801 or "laddering."802 Currently, these types of investigations would require requesting data from underwriters, and in some cases, other parties (such as investment advisors) involved in the primary market transaction.
-Given these potential benefits, the Commission believes that it is important – consistent with its view in the Proposing Release – for the SROs to address the feasibility, benefits, and costs of recording and reporting information about allocations of NMS securities in primary market transactions as part of the consolidated audit trail. However, unlike other potential additions to the consolidated audit trail – e.g., the inclusion of debt securities – that will be contemplated later in expansion plans, allocations of NMS securities in primary market transactions are uniquely tied to the central element of the NMS plan – the reporting of data regarding trading in NMS securities. For example, allocations in primary market transactions may have a significant impact on trading and other activity in the secondary market, and behavior in the primary market may influence behavior in the secondary market through initial pricing and other mechanisms. More broadly, IPOs and other primary market transactions continue to be a source of particular interest for market participants and observers because of, among other things, their role in the capital formation process. In light of these considerations, the Commission believes it is appropriate to require the SROs to address allocations of NMS securities in primary market transactions at the time that the NMS plan is submitted under adopted Rule 613(a)(1), rather than as part of an expansion plan under adopted Rule 613(i).
-At the same time, the Commission recognizes that firms may use systems and methods to handle information regarding allocations of NMS securities in primary market transactions that differ from those used to handle information regarding secondary market transactions in such securities. Such differences may affect the extent to which information regarding allocations may be readily incorporated into the consolidated audit trail described by the NMS plan mandated by Rule 613. For example, the unique features of allocations of NMS securities in primary market transactions may require different reporting timeframes, different information security controls, or additional data elements that would not be required for other information being reported to the central repository and that are not contemplated by Rule 613. Because of these potential differences, the Commission believes it is appropriate to require the SROs to address the feasibility, costs, and benefits of their members reporting information regarding allocations of NMS securities in primary market transactions, rather than require the NMS plan to require such reporting at the outset.
-The Commission acknowledges that plan sponsors nevertheless will incur costs to address the feasibility, benefits, and costs of incorporating information about allocations of NMS securities in primary market transactions into the consolidated audit trail. Among other things, the plan sponsors will need to undertake an analysis of technological and computer system acquisitions and upgrades that would be required to include information about such allocations. However, given the potential benefits described above of including such information in the consolidated audit trail, the Commission believes these costs are justified.
-ii. Analysis of the NMS Plan
-As noted above, in consideration of the views expressed, suggestions for alternatives, and other information provided by those commenting on the proposed Rule, the Commission is adopting Rule 613 with significant modifications to a number of the proposed requirements. In certain instances these modifications alter the data and collection requirements of the proposed Rule. In other instances, the adopted Rule has been altered to be less prescriptive, and hence less limiting, in the means the SROs may use to meet certain requirements. These modifications significantly expand the solution set that could be considered by the SROs for creating, implementing, and maintaining a consolidated audit trail and thus provide the SROs with increased flexibility in how they choose to meet the requirements of the adopted Rule, relative to the solution set that would have been available under the requirements of the proposed Rule.
-Because these modifications permit a wider array of solutions to be considered by the SROs, including solutions that could capitalize on existing systems and standards,803 the assumptions underlying the Commission's cost estimate in the Proposing Release that new, large-scale market systems would need to be developed from scratch may no longer be valid.804 Thus, as part of the multi-step process for developing and approving an NMS plan that will govern the creation, implementation, and maintenance of a consolidated audit trail, the Commission is deferring its economic analysis of the actual creation, implementation, and maintenance of a consolidated audit trail itself (in contrast to the costs of the actions the SROs are required to take upon approval of the adopted Rule)805 until such time as it may approve any NMS plan submitted to the Commission for its consideration – that is, after the NMS plan, together with its detailed information, including cost estimates for the creation, implementation, and maintenance of the consolidated audit trail, and analysis, has been submitted by the SROs to the Commission and there has been an opportunity for public comment. The Commission believes that the information and analyses will help inform public comment regarding the NMS plan and will help inform the Commission as it evaluates whether to approve the NMS plan. In this way, the Commission can be better informed about the costs for the development, implementation, and maintenance of the consolidated audit trail that benefit from cost data and information provided by the SROs in conjunction with – and guided by – their development of an NMS plan that complies with the requirements of the adopted Rule. In addition, as noted above,806 the Rule includes a mandate that in determining whether to approve the plan and whether the plan is in the public interest, the Commission must consider the impact of the NMS plan on efficiency, competition, and capital formation.
- -Rule 613(a)(1)(vii) requires the NMS plan to include "[t]he detailed estimated costs for creating, implementing, and maintaining the consolidated audit trail as contemplated by the national market system plan, which estimated costs should specify: (A) [a]n estimate of the costs to the plan sponsors for creating and maintaining the central repository; (B) [a]n estimate of the costs to members of the plan sponsors, initially and on an ongoing basis, for reporting the data required by the national market system plan; (C) [a]n estimate of the costs to the plan sponsors, initially and on an ongoing basis, for reporting the data required by the national market system plan; and (D) [h]ow the plan sponsors propose to fund the creation, implementation, and maintenance of the consolidated audit trail, including the proposed allocation of such estimated costs among the plan sponsors, and between the plan sponsors and members of the plan sponsors."807
-Commenters opined on the costs of funding the consolidated audit trail in general.808 One commenter stated that the Commission should give "important consideration to alternative means to help fund the creation of what is essentially a public utility in [the consolidated audit trail]," suggesting the Commission "should itself pay user fees to help build and run the [consolidated audit trail]," or that the government should underwrite low-cost loans for market participants aimed to pay the costs of the consolidated audit trail.809 Another commenter suggested that the cost of creating and maintaining the central repository should be shared among all market participants, including broker-dealers, ATSs, and exchanges.810 Another commenter stated that, if the Commission requires the SROs to fund the creation of the consolidated audit trail (i.e., the central repository), SROs may be forced to raise transaction fees, which would "resurrect the distortions caused by high transaction fees, potentially increase the use of flash orders, if allowed, and discourage trading activity."811
-The Commission also received comments regarding the allocation of the costs of the consolidated audit trail.812 One commenter emphasized that the NMS plan must provide for an equitable allocation of costs, including the sharing of expansion costs by the parties that benefit from any new products added to the consolidated audit trail.813 One commenter suggested that the Commission should require trading venues to allocate system costs for the consolidated audit trail "at least partially based on message traffic . . . ."814 Similarly, another commenter, opining that exchanges currently bear a disproportionate amount of the costs for market surveillance and noting that exchanges would also be forced to shoulder the costs of the consolidated audit trail, suggested that other venues, such as ATSs and internal broker-dealer platforms, should bear a proportionate share of the costs of creating, implementing, and maintaining the consolidated audit trail.815 This commenter also suggested that the Commission fund the audit trail using fees assessed on high frequency traders who cancel a "disproportionately high" percentage of their orders,816 arguing that this "would have the added benefit of deterring a practice that, at best, adds little value in the price discovery process and, at worst, is potentially manipulative or even fraudulent."817
-The Commission believes that the issues surrounding how the consolidated audit trail should be funded, and how costs in creating, implementing, and maintaining the consolidated audit trail should be allocated, are important, and the Rule requires information about those issues to be provided by the SROs in the NMS plan submitted to the Commission for its consideration. In response to comments and in recognition that an initiative of the size and scope of the consolidated audit trail necessarily will require substantial expenditures by the SROs and their members, the Commission is requiring, pursuant to Rule 613(a)(1)(vii), the SROs to include in the NMS plan, a discussion of costs and how such costs will be allocated. As discussed above, the Commission believes that the SROs will incur costs to create and maintain the central repository.818 Also, as discussed above, SROs and their members may need to make systems changes or to purchase new systems to record and report the data required by the NMS plan to the central repository.819 SROs and their members will incur upfront costs, as well as ongoing costs to record and report such information. Because, as noted above, these costs can only be analyzed once the SROs narrow the array of choices they have and develop a detailed NMS plan,820 the Commission believes that the most robust approach for estimating these costs is for the SROs to provide such cost estimates in conjunction with, and guided by, their development of the NMS plan. The Commission believes that a fulsome discussion in the NMS plan of the estimated costs to SROs and their members will aid commenters in providing useful comments that will further the Commission's understanding of the cost implications of the consolidated audit trail. In addition, a fulsome discussion will aid the Commission in its evaluation of whether to approve the NMS plan and in conducting its own analysis of the costs and benefits of the NMS plan.
-There also would be costs associated with establishing and operating the central repository that will be jointly owned by the plan sponsors. The Commission believes it is important to understand how the plan sponsors plan to allocate such costs among themselves to help inform the Commission's decision regarding the possible economic or competitive impact of the NMS plan amongst the SROs. In addition, although the plan sponsors likely would initially incur the costs to establish and fund the central repository directly, they may seek to recover some or all of these costs from their members. If the plan sponsors seek to recover costs from their members, the Commission believes that it is important to understand the plan sponsors' plans to allocate costs between themselves and their members, to help inform the Commission's decision regarding the possible economic or competitive impact of the NMS plan.
- -Rule 613(a)(1)(viii) requires the NMS plan to include "[a]n analysis of the impact on competition, efficiency, and capital formation of creating, implementing, and maintaining the national market system plan."
-Rule 608(a)(4)(ii)(C) under Regulation NMS already requires every NMS plan submitted to the Commission to be accompanied by an analysis of the impact on competition of implementation of the plan.821 This requirement is designed to help inform the Commission's evaluation of whether the NMS plan will impose a burden on competition that is not necessary or appropriate in furtherance of the purposes of the Exchange Act. The Rule re-states the application of the Rule 608(a)(4)(ii)(C) requirement to provide an analysis of the NMS plan's impact on competition and imposes a requirement that the NMS plan also include an analysis of the impact on efficiency and capital formation.822
-These requirements are designed to help inform the Commission's understanding of whether the NMS plan may promote efficiency and capital formation. As an initial matter, the SROs will be providing an analysis of the economic consequences of the NMS plan they develop and propose. As noted above, because the specific requirements of the NMS plan will not be known until the NMS plan is submitted, and the SROs will be providing that analysis, the Commission will consider the impact of the proposed consolidated audit trail on efficiency, competition, and capital formation in deciding whether to approve the NMS plan. The Commission, however, will consider such analysis in determining whether to approve the NMS plan and whether the plan is in the public interest under Rule 608(b)(2). 823
-iii. Process Followed to Develop the NMS Plan
-The following two considerations require the NMS plan to address how the SROs solicited the input of their members and other appropriate parties in their design of the NMS plan, and to detail the alternative consolidated audit trail designs considered and rejected by the SROs. These considerations will inform the Commission's evaluation of the NMS plan submitted for its consideration.
- -Rule 613(a)(1)(xi) requires the NMS plan to discuss "[t]he process by which the plan sponsors solicited views of their members and other appropriate parties regarding the creation, implementation, and maintenance of the consolidated audit trail, a summary of the views of such members and other parties, and how the plan sponsors took such views into account in preparing the national market system plan."
-The Commission believes that the SROs' consideration of the views of their members is important because, given the scope of the Rule, it will affect many market participants and will require them to report a broad range of audit trail information. Ensuring that market participants with varied perspectives have a role in developing the NMS plan submitted to the Commission for its consideration could help inform the plan sponsors of operational or technical issues that may arise in the implementation of the NMS plan, and help assure the Commission and market participants that the requirements imposed on members are done so in an efficient and cost-effective manner.824 Similarly, the Commission believes it is important that the SROs consider the views of other parties – such as back office service providers, market operations specialists, and technology and data firms – as may be appropriate in light of the Rule's goal of creating, implementing, and maintaining a complex system that may entail changes to multiple other systems and functionalities involved across the lifecycle of an order. Such parties could offer operational and technical expertise to the SROs, including, among other things, by identifying issues that may arise in the interface between legacy and new systems. In addition, the inclusion of such parties in the deliberative process could also result in the introduction of additional alternative approaches.
-The Commission also believes that it is appropriate to require the SROs to set out in the NMS plan a summary of the views expressed by such members and other parties and how the SROs took those views into account in developing the NMS plan. This requirement is designed to inform the Commission about the extent to which the SROs considered the views of their members and other appropriate parties as they undertook the complex task of developing the NMS plan for a consolidated audit trail, to facilitate a cost estimate by the SROs that takes into account the costs members will incur in creating, implementing, and maintaining the consolidated audit trail, as well as to encourage the consideration of reasonable alternative approaches contemplated by Rule 613(a)(1)(xii) in the plan formulation process.
-The Commission received several comments advocating inclusion of the broker-dealer community and other appropriate parties in the planning of the consolidated audit trail.825 One commenter, with respect to NMS plan governance, urged the inclusion of "an official 'seat at the table' alongside the SROs" for members of the broker-dealer industry.826 Another commenter recommended that the Commission seek greater SRO and broker-dealer involvement in the front-end planning before adopting a final rule to make all parties aware of potential design tradeoffs, and establish appropriate timelines for implementation and compliance.827 A further commenter advocated allowing working groups to engage in dialogue with the Commission, broker-dealers and the SROs to effectively conduct the business analysis needed to build the consolidated audit trail.828 Additionally, one commenter suggested that the Commission staff should form and engage working groups comprised of representatives from the "affected constituents," specifically brokers and "key technology vendors,"829 and that such working groups could work with the Commission to develop a request for proposal."830 Similarly, another commenter urged the Commission to require an industry working group of SROs and a representative group of broker-dealers to address the "complexities involved in developing such a system."831 One commenter suggested encouraging the participation of issuers and other market participants in the creation of the consolidated audit trail,832 and another commenter advocated the inclusion of "broad industry participation from the SEC, FINRA, exchange, broker dealer and vendor communities."833
-The Commission considered the comments recommending wider industry involvement in the creation of the consolidated audit trail and believes that, since the consolidated audit trail will be a regulatory tool used by the SROs and the Commission, it is appropriate for the SROs, when developing the NMS plan, to request input from the securities industry as well as technological advice. The Commission believes that this input should be sought during the preparation of the NMS plan submitted to the Commission for its consideration,834 during the comment process,835 and subsequent to the approval of an NMS plan.836
- -Rule 613(a)(1)(xii) requires the NMS plan to discuss "[a]ny reasonable alternative approaches to creating a consolidated audit trail that the plan sponsors considered in developing the national market system plan, including, but not limited to, a description of any such alternative approach; the relative advantages and disadvantages of each such alternative, including an assessment of the alternative's costs and benefits; and the basis upon which the plan sponsors selected the approach reflected in the national market system plan."837 The Commission believes this consideration is appropriate because it reflects the view, supported by commenters, that there are alternative approaches to creating, implementing, and maintaining the consolidated audit trail. The Commission believes that requiring the SROs to discuss alternatives considered helps ensure that the plan sponsors have appropriately weighed the merits of the various approaches that might be considered to create, implement, and maintain the consolidated audit trail, by requiring the NMS plan to describe the alternatives that the plan sponsors considered before making any significant decision with respect to the consolidated audit trail, and the relative advantages and disadvantages, including costs and benefits, of such alternatives. The Commission also believes that requiring transparency with respect to alternative approaches and the decision-making process of the SROs will facilitate public comment on the NMS plan and the wisdom of the approach selected by the plan sponsors. Similarly, such transparency should provide the Commission with useful insights into the rationale for the approach chosen by the plan sponsors as it considers whether to approve the NMS plan submitted to the Commission. The Commission also notes that this consideration complements Rule 613(a)(1)(vii), discussed above, which requires that the NMS plan discuss the detailed estimated costs to the plan sponsors for creating, implementing, and maintaining the consolidated audit trail, because this consideration requires the NMS plan to provide the costs of the alternatives that were not adopted by the plan sponsors in the NMS plan submitted to the Commission.
-iv. Implementation and Milestones of the Consolidated Audit Trail
-The following two considerations are designed to elicit additional information from the plan sponsors about the implementation and milestones of the consolidated audit trail. These will inform the Commission's evaluation of the NMS plan submitted to the Commission for its consideration, particularly in the degree to which the consolidated audit trail can replace existing data sources and in how effectively the proposed plan will meet the objectives discussed in Section II.B.2.
- -Rule 613(a)(1)(ix) requires the NMS plan to discuss "[a] plan to eliminate existing rules and systems (or components thereof) that will be rendered duplicative by the consolidated audit trail, including identification of such rules and systems (or components thereof); to the extent that any existing rules or systems related to monitoring quotes, orders, and executions provide information that is not rendered duplicative by the consolidated audit trail, an analysis of: (A) [w]hether collection of such information remains appropriate; (B) [i]f still appropriate, whether such information should continue to be separately collected or should instead be incorporated into the consolidated audit trail; and (C) [i]f no longer appropriate, how the collection of such information could be efficiently terminated; the steps the plan sponsors propose to take to seek Commission approval for the elimination of such rules and systems (or components thereof); and a timetable for such elimination, including a description of the phasing-in of the consolidated audit trail and phasing-out of such existing rules and systems (or components thereof)."838
-As noted in the Proposing Release and above, many exchanges and FINRA each have their own disparate audit trail rules.839 Thus, a member of the various exchanges and FINRA could be subject to the audit trail rules of, and be required to submit different information to, more than one exchange and FINRA. In addition, several commenters discussed the potential reduction in costs for the creation, implementation, and maintenance of a consolidated audit trail if existing SRO audit trail requirements were eliminated. In particular, one commenter stated that, "over the long-term, the costs of developing a carefully designed and appropriately scaled consolidated audit trail could be offset in part by eliminating the individual SRO reporting requirements imposed under existing audit trail systems."840 This commenter also urged the SROs and the Commission "to rely to the fullest extent possible on the consolidated audit trail data for market reconstructions, investigations, and analysis, rather than requesting data from broker-dealers. This would be more efficient for both firms and regulators and would help maximize the utility of the consolidated audit trail."841
-Another commenter similarly stated that "a consolidated trail and consolidated market surveillance should achieve economies of scale that ultimately lower costs for both the markets themselves and the market participants."842 This commenter further reasoned that, "[r]ather than each SRO separately maintaining its own surveillance staff and surveillance programs that are searching for the same behavior, and thus creating redundancies, certain technology and staff resources can be consolidated into a single enterprise with costs equitably allocated across all SROs."843 However, the commenter also pointed out that "[s]uch consolidation, of course, would not preclude individual SROs from conducting surveillance for unique attributes and rules of its marketplace, ensuring that specialized market expertise continues to inform surveillance and oversight of trading on that market."844
-Many other commenters shared similar opinions with regards to the efficiency effects that a consolidated audit trail would have on market participants and their requirements to provide data to regulators. One commenter, for example, listed as one of seven benefits of a consolidated audit trail that "it would reduce the time and resources required by market participants to respond to case-by-case requests from regulators."845 Another commenter stated that it "agrees with the Commission that the implementation of the proposed consolidated audit trail would likely render unnecessary existing audit trails and data obtained through the equity blue sheets system."846 Similarly, another commenter also "agree[d] with the Commission that in calculating the total cost to the industry of the audit trail it is important to consider offsetting savings from the retirement of redundant data feeds such as OATS, OTS, COATS, ISG Equity Audit Trail, and EBS. In addition, the industry may be able to avoid the cost of compliance with the Commission's proposed Large Trader Reporting System if the consolidated audit trail contains sufficient information to meet those requirements."847
-The Commission recognizes that the creation of a consolidated audit trail could result in efficiency gains for market participants with respect to their regulatory data reporting requirements and for regulators with respect to their surveillance activities. The Commission also recognizes that the consolidated audit trail could render existing rules and systems that contain the same requirements as the consolidated audit trail redundant. While the Commission is not at this time requiring that existing rules and systems be eliminated, the Rule requires that the NMS plan provide a plan to eliminate existing rules and systems (or components thereof), including identification of such rules and systems (or components thereof). Further, to the extent that any existing rules or systems related to monitoring quotes, orders, and executions provide information that is not rendered duplicative by the consolidated audit trail, such plan must also include an analysis of (1) whether the collection of such information remains appropriate, (2) if still appropriate, whether such information should continue to be separately collected or should instead be incorporated into the consolidated audit trail, and (3) if no longer appropriate, how the collection of such information could be efficiently terminated. Finally, such plan must also provide the steps the plan sponsors propose to take to seek Commission approval for the elimination of such rules and systems (or components thereof); and a timetable for such elimination, including a description of how the plan sponsors propose to phase in the consolidated audit trail and phase out such existing rules and systems (or components thereof).
-The Commission believes that the implementation of a plan to eliminate duplicative existing rules, systems, and/or components of such rules and systems, will result in increased efficiency to market participants who need to comply with the disparate reporting requirements for orders and with repeated requests for data by regulators who cannot obtain the data they need from existing sources of information.
- -Rule 613(a)(1)(x) requires the NMS plan to include "[o]bjective milestones to assess progress toward the implementation of the national market system plan."
-The creation of a consolidated audit trail is crucial to the effective oversight of the U.S. securities markets, but at the same time is an initiative of substantial scope and complexity. Accordingly, to ensure that the consolidated audit trail is established in a timely and logical manner, and that the SROs can be held accountable for maintaining a workable implementation schedule, the NMS plan submitted is required to set forth a series of detailed objective milestones, with projected completion dates, toward implementation of the consolidated audit trail. In addition to being useful for the Commission in its evaluation of the NMS plan, the milestones will be used by the Commission in its supervision of the implementation of the consolidated audit trail. Such milestones could include, but are not limited to: publication and implementation of the methods for obtaining a CAT-Reporter-ID and the Customer-ID database, testing of the collection of order and execution data from a representative subset of broker-dealers, initial access to the central repository for regulators, demonstration of linking the full lifecycle of events for select test orders, cancels, modifications, and executions, and integration of trade and quote data as currently reported by trading venues into the central repository.
-v. Commission Review
-The Commission believes these considerations represent fundamental characteristics of a meaningful plan to establish an effective and efficient consolidated audit trail. The Commission will assess the NMS plan's discussion of the considerations described as part of its evaluation of the NMS plan.848 The Commission notes that, if the NMS plan submitted does not comply with the requirements of the Rule, or if the Commission determines changes are necessary or appropriate, the Commission may amend the NMS plan pursuant to Rule 608(b)(2 of Regulation NMS with such changes or subject to such conditions as the Commission may deem necessary or appropriate, taking into account the considerations contemplated in Rule 613(a)(1).849 In addition, should the NMS plan and the consolidated audit trail not keep pace with market or technological developments, such that its efficiency or effectiveness becomes impaired,850 the Commission itself may, pursuant to Rule 608(b), propose an amendment to the NMS plan.851
-b. Regulator Use Cases
-In light of the comments recommending that the Commission undertake an RFP process and provide more "business requirements"852 the Commission believes that it is useful to provide further details about how it envisions regulators would use, access, and analyze consolidated audit trail data through a number of "use cases," as might typically be found in an RFP. These "use cases" and accompanying questions set forth below are derived directly from the considerations described in adopted Rule 613(a)(1), which, as discussed in Section III.C.2.a., originated from key principles of the consolidated audit trail that had been highlighted by the Commission in the Proposing Release. Specifically, these "use cases" describe the various ways in which, and purposes for which, regulators would likely use, access, and analyze consolidated audit trail data. By describing how regulators would use the consolidated audit trail data, the "use cases" and the related questions are meant to elicit a level of detail about the considerations that should help the SROs prepare an NMS plan that better addresses the requirements of the adopted Rule. They should also aid the Commission and the public in gauging how well the NMS plan will address the need for a consolidated audit trail. In particular, the "use cases" will assist in gauging how well the NMS plan will specifically address the needs outlined in this Rule, by describing the features, functions, costs, benefits, and implementation times of the plan.
-The Commission notes that it is not including these "use cases" and accompanying questions to endorse a particular technology or approach to the consolidated audit trail; rather, these "use cases" and accompanying questions are designed to aid the SROs' understanding of the types of useful specific information that the NMS plan could contain that would assist the Commission in its evaluation of the NMS plan. The Commission also notes that its description of "use cases" includes a non-exclusive list of factors that SROs could consider when developing the NMS plan. The SROs also may include in the NMS plan submitted to the Commission for its consideration any other information regarding how data would be stored or accessed that the SROs believe the Commission or the public may find useful in evaluating the NMS plan submitted.
-1. Analyses Related to Investigations and Examinations
-The Commission expects that the consolidated audit trail will provide regulators the ability to more efficiently conduct targeted investigations and examinations. These generally require being able to conduct several types of queries on large amounts of data and extract targeted segments of such data. These targeted segments are likely to be much smaller than the bulk extractions discussed in Section III.C.2.b.2., below.
-Off-Line Analysis. Regulators are likely to frequently require the extraction of relatively small amounts of select data from the consolidated audit trail database at the central repository for their own "off-line" analyses.853 For example, a regulator may need to extract data on all orders in a particular stock, by a particular customer, on a particular day, or based on any other combination of fixed search criteria.854 Though the total data extracted may be small, the number of records that need to be searched to find such data may be enormous.
-i. What technical or procedural mechanisms will regulators be required to use to request data extractions? Does the NMS plan provide for a front-end user interface to perform search and extractions? If not, what types of tools or technologies would regulators need to implement to send search and extract requests to the database? Would regulators be permitted to write and submit their own queries (e.g., Structure Query Language or "SQL") to the database directly? Would the central repository write and submit queries on behalf of a regulator at the regulator's request?
-ii. What response times should regulators expect from search and extract requests? Would a search for all trades in a given security by a given customer over a specified period of time return a response with all requested data in one minute? One hour? Overnight? How would this response time scale with the amount of data requested? With the amount of data being searched?
-iii. How would the database effectively process simultaneous requests by multiple users at one or more regulators? Will each request be queued serially? Can they be processed in parallel? What is the effect of simultaneous requests on response times? Would there be limits to the number of search queries that can be performed at the same time? Would there be limitations on the size of the extractions from such queries?
-iv. A wide range of users at regulators may need to search and extract data for analysis. How are users to be administered? If the NMS plan contemplates a front-end user interface, what validation and security mechanisms will ensure that only permitted users will have access to such data? If the plan contemplates direct access through a means other than a front-end user interface, what security and validation mechanisms would regulators need to deploy to interact with the database?
-Dynamic Search and Extraction. At times, regulators may need to identify and extract small amounts of data from the database based on dynamic search criteria that might require the database to perform calculations on stored data to meet the specified criteria. A few examples of dynamic criteria are: searching for trades with trade sizes above a certain threshold, searching for trades in securities with execution prices that change more than a certain percentage in a given period of time, and searching for orders that are canceled within a certain period of time.
-i. Does the NMS plan contemplate allowing for dynamic search criteria to operate directly on the database? If so, how would the dynamic search criteria be specified and run? What, if any, limitations would there be on the types of search criteria that can be requested? What are the implications for response times? If the plan contemplates a front-end user interface, will dynamic search criteria be included? If the plan allows for dynamic search criteria through a means other than a front-end user interface, what types of tools or technologies would regulators need to implement to request dynamic searches? Have the plan sponsors considered whether such tools or technologies and the personnel to use them are currently available to the regulators?
-ii. If the NMS plan does not contemplate dynamic search criteria, please explain how regulators would be able to use the consolidated audit trail data to perform such searches. Would data need to be downloaded in bulk by the regulators to accomplish these types of searches off-line (see below for related questions)?
-2. Analyses Related to Monitoring, Surveillance, and Reconstruction
-In addition to targeted analysis of select data from the consolidated audit trail database, regulators will also require the analysis of data in bulk form. For example, the Commission is likely to use consolidated audit trail data to calculate detailed statistics on order flow, order sizes, market depth and rates of cancellation, to monitor trends and inform SRO and Commission rulemaking. To satisfy the surveillance requirements of Rule 613(f), regulators may want the ability to feed consolidated audit trail data into analytical "alert" programs designed to screen for potential illegal activities such as insider trading or spoofing. Surveillances might also benefit if regulators are able to link consolidated audit trail data with databases on certain types of material news events or market participants. This would allow regulators to isolate and aggregate data on trading in advance of those news events or by those participants. If preliminary analyses showed problems, the regulators could then request significant amounts of data for a more thorough and detailed follow-up analysis. In the event of a large scale market event like the May 6, 2010 "flash crash," regulators are likely to use consolidated audit trail data to reconstruct market events on the day of the event, including but not limited to reconstructing entire order books and trading sequences.
-i. What, if any, SRO surveillance data could be replaced by the consolidated audit trail while still improving SROs' ability to surveil?
-ii. How will the NMS plan allow regulators to address these types of large-scale, on-going data analyses?
-iii. In addition to providing regulators with the ability to search and extract data, will the NMS plan provide regulators with access to any plan-hosted applications or interfaces (i.e., those that operate on plan-based systems and resources) that would enable users to perform data analyses on, or create reports or graphs from, data stored in the database (such application or interfaces collectively known as "hosted analytical tools")? If so, how would regulators use and access such tools? What are the limitations of such tools? Would the tools allow regulators to perform the analyses discussed in the examples presented above?
-iv. If the NMS plan does not provide regulators with hosted analytical tools, how would regulators be expected to use their own resources, software, and hardware to perform such analyses? Would the plan provide regulators with an application programming interface ("API") that allows regulators to develop their own tools that interact directly with the consolidated audit trail database? If so, what will the form of such API be? Are there limitations to the number of systems that could connect to the database? How will the plan negotiate priorities for connectivity, searches and queries done via the API? Will there be limitations to the types of queries that could be performed through the API? What types of in-house technologies and systems would be required for regulators to connect to the consolidated audit trail in this fashion?
-v. If the NMS plan does not provide regulators with analytical tools and services and does not provide an API for regulators to connect their own analytics systems to the database, what mechanism would the plan provide to regulators for accessing bulk data in a way that allows for large-scale analyses? Would the plan allow for end-of-day downloads of an entire day's activity so that regulators could load this information into their own systems for such analysis? If so, how is access to such a download to be controlled and implemented? How long would it take to transmit an entire day's worth of consolidated audit trail data to each of the regulators that requires such access? 10 minutes? One hour? Multiple hours? Longer than overnight? Do these time estimates reflect that multiple regulators are likely to simultaneously download consolidated audit trail data each night? What types of technologies or systems would be required for regulators to download this data? What are the expected sizes of such a data download? What type of systems would each regulator need to deploy to store and analyze this data? Have the plan sponsors considered whether such systems and the personnel to operate them are currently available to the regulators?
-vi. Does the plan contemplate data streaming as a method of transmitting bulk data to each regulator? If so, what is the form and mechanism of such data streaming? Would the streaming occur intraday as data is reported to, and processed by, the database, or would the streaming occur after all (or a majority of, or such other criteria) data was reported to, and processed by the database (e.g. overnight streaming)? How would intraday streaming impact the accuracy or completeness of the data received by regulators? Would data be transmitted through different methods or with varying delays by different SROs?
-vii. If the plan does not contemplate any bulk data analyses or means of transmitting data to regulators on a bulk overnight basis or in an intraday or overnight streaming fashion, describe what alternative mechanisms, if any, could be used to enable regulators to perform the types of analyses described at the beginning of the section (b), as well as the various examples described throughout this document of how regulators would make use of consolidated audit trail data.
-3. Order Tracking and Time Sequencing
-As discussed in detail throughout this Release, one of the key requirements of the consolidated audit trail is to provide regulators with a complete record of all of the events that stem from a particular order, from routing to modification, cancellation, or execution. In addition, these events must be stored by the central repository in a linked manner – using either a unique order identifier or a series of unique order identifiers, as discussed in Section III.B.1.d.iv. – so that regulators can quickly and accurately extract a time-sequenced history of each event related to an order.
-i. What methods will the plan use to create the linkages for order events as described above? How will regulators access and search on data in a linked fashion?
-ii. What is the technical form of the order identifier(s) that broker-dealers will be required to send to the consolidated audit trail database so that these linkages can be created? To what extent will broker-dealers be able to generate such identifier(s) using their current systems? To what extent will broker-dealers need to collect or track new data, or modify their systems, to generate such identifier(s)?
-iii. Will the transmission of economic data (such as a price) be sent separately, or via a different technical mechanism, from noneconomic data (such as the identity of a customer)?
-iv. What other changes, if any, will be required of systems typically in use by broker-dealers to provide such data? To what extent can existing broker-dealer systems be employed? What modifications will be necessary? What are the costs and technological ramifications of such changes?
-v. What changes, if any, will be required of the systems currently in use by regulators to receive such data? To what extent can existing regulatory systems be employed? What modifications will be necessary? What are the costs and technological ramifications of such changes?
-vi. If data reformatting is required, how much must be done by each broker-dealer using its own systems and resources prior to sending data to the central repository, versus being done on the receiving end by the central repository using plan-based systems and resources?
-vii. If multiple methods for collecting and aggregating are contemplated by the NMS plan, what are the pros and cons of each method?
-viii. How will the plan ensure orders and subsequent events are properly time-sequenced? At what level of granularity will time stamps be stored for each event? Milliseconds? Microseconds? Picoseconds? Describe any differences in the accuracy at which events originating in the same broker-dealer system can be sequenced versus events across different systems at the same broker-dealer, or systems at different broker-dealers. What type of synchronization of clocks will be employed to minimize inter-system timing inaccuracies?
-ix. If time stamps are not stored at a sufficient level of granularity to properly sequence events, what other data or mechanisms will the NMS plan provide to meet the requirement that regulators be able to time-sequence events?
-x. Even if time stamps are sufficiently granular to meet the time-sequencing requirements of today, how would the plan contemplate increasing that granularity as the speed of trading increases?
-4. Database Security, Contingency Planning, and Prospects for Growth
-The data stored in the consolidated audit trail database will contain confidential detailed records of trade and order flow by customer.
-i. How will the plan ensure the security of the database in a way that provides for flexible access by permitted users at multiple regulators (i.e., the Commission and the SROs), but denies access to all other non-permitted users?
-ii. What are the plan's policies and procedures with regards to security? Will the plan make use of any specific national or international security standards? If so, which ones? Will the plan make use of third-party reviews of its security procedures?
-iii. What types of contingency and backup plans will be employed by the plan to safeguard against the loss of data due to technical failures? Will the plan make use of live failover mechanisms so that data being sent to the database is not inadvertently lost in the event of a failure? Will contingency plans provide regulators with uninterrupted access to the database? If not, what are the expectations for recovery times under different failure scenarios?
-iv. As order and trade volumes increase, how does the plan contemplate handling the need for increased capacity and throughput? Would the plan be able to accommodate a doubling in daily volume without materially altering the basic technologies and architecture? A ten-time increase? A 100-times increase?
-5. Database Access
-As part of an investigation or examination, regulators may need to analyze historical trades and orders in the database maintained by the central repository (though not trade and order events occurring prior to the implementation of the consolidated audit trail).
-i. How much historical data will be stored "on-line" in the database and be available for immediate search and extraction?
-ii. How will data be archived if it is no longer stored on-line? How will regulators access and search data that has been archived?
-iii. Will third parties have access to historical data? How will this access differ from the regulatory access?
-c. Extension of time for submission of NMS plan
-Proposed Rule 613 required the SROs to jointly file the NMS plan within 90 days from approval of Rule 613. The Commission received a comment letter specifically suggesting that a six-month period, rather than the 90-day period originally proposed, would be more appropriate for the submission of the NMS plan to ensure that the NMS plan is drafted with an informed understanding of how order and trade processing works so that the consolidated audit trail systems are capable of achieving the Commission's objectives.855 To this end the commenter recommended that the Rule mandate the formation of cross‐market participant working groups; outline the objectives of consolidated audit trail rather than identify technical requirements; and allow six months for the cross‐participant working groups to perform a requirements analysis as part of the development of the NMS plan.856
-In response to this commenter and other commenters that suggested that the Commission rely on an industry working group to create the consolidated audit trail857 and to provide sufficient time for the SROs to draft the additional provisions required by the Rule858 and to prepare responses to the considerations and the use cases for inclusion in the NMS plan,859 the Commission is extending the timeframe for the submission of the NMS plan from 90 days from approval of Rule 613 to 270 days from the date of publication of the Adopting Release in the Federal Register.860
+This scenario illustrates the CAT reporting requirements when an Industry Member internally routes a customer order from the sales desk to multiple desks within the Industry Member. Each destination desk subsequently internally fills the order. Each internal route and execution must be reported separately.
+
+ For this scenario, Industry Member Broker 1 is required to report the following events for CAT:
+• At the Sales Desk
+• New Order event for the customer order
+• At the Trading Desk
+• Order Internal Route event from the sales desk to the trading desk
+• The principal execution as a Trade event
+• At the Arbitrage Desk
+• Order Internal Route event from trading desk to the arbitrage desk
+• The principal execution as a Trade event
+• At the Program Trading Desk
+• Order Internal Route event from the trading desk to the program trading desk
+• The principal execution as a Trade event
+
+ 
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.3.5. Internal Route and Execution, Leaves Quantity Routed Externally
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Internal Route and Execution, Leaves Quantity Routed Externally
+ Compliance User: Industry Member
+ Keywords:
+ This scenario illustrates the reporting requirements to CAT when an Industry Member internally routes an order to another desk where it is partially executed and the remainder is routed to another Industry Member to execute.
+
+ Industry Member Broker 1 is required to report the following events:
+• New Order event for the customer order
+• Order Internal Route from the Sales Desk to the Trading Desk
+• Trade event for the partial execution of the customer order
+• Order Route of the remaining shares to Broker 2
+Industry Member Broker 2 is required to report the following events:
+• Order Accepted event for the order from Broker 1
+• Trade event for the execution of Broker 1's order
+
+ 
+ 
pubdate: N/A effdate: N/A
- 3. NMS Plan Costs
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Discussion, NMS Plan Process, NMS Plan Costs
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2.3.6. Fill of a Customer Order from a Pre-Existing Principal Order
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Fill of a Customer Order from a Pre-Existing Principal Order
+ Compliance User: Industry Member
Keywords:
- Cost Estimate,
- Preliminary,
- Revised,
- Programmer Analyst,
- Business Analyst,
- Attorney,
- Compliance Manager,
+ Order Fulfillment event,
- a. NMS Plan Cost Estimates
-This section sets forth the Commission's estimates of the costs to prepare and file the NMS plan. As noted above, as part of the multi-step process for developing and approving an NMS plan that will govern the creation, implementation, and maintenance of a consolidated audit trail, the Commission is deferring its economic analysis of the consolidated audit trail (other than with respect to the NMS plan) until after the NMS plan, together with its detailed information and analysis, has been submitted by the SROs to the Commission for its consideration and there has been an opportunity for public comment.861 The Commission believes that an economic analysis of the consolidated audit trail is more appropriately performed once the SROs narrow the expanded array of choices they have and developed a detailed NMS plan.862 At that time, the Commission will have available to it detailed information provided by the SROs, and any additional information provided by commenters once the NMS plan is published for comment. The cost estimates set forth below, therefore, only reflect the Commission's estimates as to the costs to the SROs for developing an NMS plan to be submitted to the Commission. These cost estimates do not reflect the much more significant initial and ongoing costs that would be incurred if such NMS plan were approved by the Commission and the implementation of the consolidated audit trail begins.
-The Commission notes that the requirement to develop and submit the NMS plan also is a collection of information within the meaning of the Paperwork Reduction Act of 1995 ("PRA").863 Section IV. below describes in detail the burdens associated with the requirement that the SROs develop and submit an NMS plan.
-i. Preliminary Cost Estimates from Proposing Release
-In the Proposing Release, the Commission estimated that each SRO, on average, would incur an aggregate one-time cost of approximately $234,000864 to prepare and file the NMS plan, for an estimated aggregate cost of about $3.5 million.865
-In making these estimates, the Commission assumed that the cost of developing and filing the NMS plan pursuant to the proposed Rule would be comparable to the cost to create other existing NMS plans.866 Underlying the Commission's estimates were estimates of the amount of time the Commission believed would likely be spent by Programmer Analysts, Business Analysts, Attorneys, and Compliance Managers. The Commission did not receive any comments on these specific cost estimates.
-ii. Revised Cost Estimates
-As noted above, the Commission based its original estimates of the cost to prepare and file the NMS plan on the costs incurred with existing NMS plans. The adopted Rule, however, has been modified from the proposed Rule in several significant ways that differentiate the costs to prepare the NMS plan from all other existing NMS plans. These modifications require the SROs to: (1) provide additional information and analysis while addressing the considerations that are set forth in Rule 613(a)(1);867 (2) include additional provisions that were not required by the proposed Rule relating to enforcement mechanisms,868 security and confidentiality,869 and the preparation of a document every two years that contains a retrospective assessment of the performance of the consolidated audit trail, as well as a plan to improve its performance;870 (3) address error rates;871 and (4) provide for the creation of an Advisory Committee.872
-(A) Revised Initial Costs to Create and File the NMS Plan
-In light of these modifications to the proposed Rule, the Commission no longer believes that the cost of developing and filing the NMS plan pursuant to the proposed Rule would be sufficiently comparable to the cost to create other existing NMS plans to use those costs as a basis for developing a cost estimate for the NMS plan required by Rule 613. Instead, as discussed in more detail below, the Commission is increasing its estimated costs for the development and filing of the NMS plan due to the increases in the hours that likely would be spent to create the NMS plan by the SROs.873 The Commission also is adjusting its preliminary cost estimate for the creation and filing of an NMS plan to reflect updated 2011 wage figures, as well as the registration of two additional SROs, since the preliminary estimates were developed.874 Specifically, the Commission now estimates that the aggregate one-time cost for creating and filing an NMS plan would be approximately $718,000 per SRO,875 or approximately $12.2 million in the aggregate,876 compared to an initial estimate of $234,000 per SRO, or approximately $3.5 million in the aggregate, to prepare and file an NMS plan.877
-The Commission believes that these revised estimates, which include internal SRO personnel time and external legal costs, are appropriate based on the impact of the modifications to the proposed Rule on each of the job categories underlying the estimates. The Commission believes that the modifications to the proposed Rule will require SRO Programmer Analysts, Business Analysts, Attorneys, and Compliance Managers to expend additional time to address the requirements of the Rule. As discussed in more detail below, the Commission anticipates that the SROs will spend additional time on many activities, including: (1) research; (2) discussions with members, committees and with industry associations; (3) vendor negotiations; (4) making decisions regarding the various options and increased flexibility provided by the adopted Rule;878 (5) reviewing alternative NMS plans; (6) choosing between alternative plans and negotiating to reach a consensus on a single NMS plan; (7) providing a detailed estimate of the costs associated with that NMS plan; and (8) drafting the NMS plan. The Commission also believes that these increased estimates are appropriate in light of the comments, including the comment that the Commission underestimated the time the SROs would spend on business analyses to be performed in designing the NMS plan based on the experience of broker-dealers, vendors and SROs when OATS was expanded to all NMS stocks.879 In response, as discussed below, the Commission is increasing its estimated Programmer Analyst, Business Analyst, Attorney, and Compliance Manager hours.
-The Commission notes that the average hourly and cost estimates per SRO for creating and filing the NMS plan likely overestimated the costs for some of SROs and underestimated the costs for other SROs. The Commission also believes that certain SROs, particularly those SROs under the same holding company, may decide to collaborate and realize some cost savings on a per SRO basis. On balance, however, the Commission believes that, these hours and cost estimates are reasonable on average even if they may not be precise for any specific SRO.
-(i) Programmer Analyst
-The Commission is increasing its Programmer Analyst hour estimates from 220 hours to 880 hours per SRO. As discussed in more detail below in Section IV.D.2.a.i., the Commission anticipates that a Programmer Analyst would need to spend substantially more time to address the considerations included in the Rule and the "use cases." Programmer Analysts may be involved in the NMS plan research, any industry discussions, negotiations with vendors and SROs, and in developing cost estimates for the consolidated audit trail. Thus, for these reasons, the Commission believes it appropriate to increase substantially its estimate of the number of hours expended by Programmer Analysts in the creation and filing of the NMS plan.
-(ii) Business Analyst
-The Commission is increasing its Business Analyst hour estimates from 360 hours to 880 hours per SRO. As discussed in more detail below in Section IV.D.2.a.ii., the Commission anticipates that a Business Analyst would spend substantially more time to address the considerations and the "use cases," and overall, an amount of time that is comparable to the time that would likely be spent by Programmer Analysts because Business Analysts will likely be involved in many of the same tasks as Programmer Analysts, but have separate responsibilities as well.
-(iii) Attorney
-The Commission is increasing its estimates for the hours an Attorney would likely spend to prepare and file an NMS plan from 400 hours to 700 hours per SRO. As discussed in more detail in Section IV.D.2.a.iii. below, the Commission anticipates that an Attorney would spend substantially more time than previously estimated to draft the NMS plan.
-(iv) Compliance Manager
-The Commission is increasing its Compliance Manager hour estimate from 100 hours to 300 hours per SRO. As discussed in more detail below in Section IV.D.2.a.iv., the Commission anticipates that a Compliance Manager would spend substantially more time than previously estimated to draft the NMS plan.
+This scenario illustrates the reporting requirements to CAT for an Industry Member that creates a new principal order and routes it to an exchange. Before execution of the principal order, the Industry Member receives a customer order. Upon execution of the principal order, the Industry Member fills the customer order on a riskless principal basis.
+For this scenario, Industry Member Broker 1 is required to report the following events:
+• The creation of a new principal order (New Order event)
+• Route the principal order to an exchange via an Order Route event
+• The receipt of a customer order (New Order event)
+• Fill of the customer order with the executed principal order via an Order Fulfillment event
+
+ 
+ 
+ 
pubdate: N/A effdate: N/A
- 4. Consideration of Burden on Competition and Promotion of Efficiency, Competition, and Capital Formation
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Discussion, NMS Plan Process, Consideration of Burden on Competition and Promotion of Efficiency, Competition, and Capital Formation
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2.3.7. Fill of a Customer Order from a Pre-Existing Principal Order with Better Price than the Representative Order
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Fill of a Customer Order from a Pre-Existing Principal Order with Better Price than the Representative Order
+ Compliance User: Industry Member
+ Keywords:
+ This scenario illustrates the reporting requirements to CAT for an Industry Member that creates and routes a representative order to work a customer order, but ultimately fills the customer order with an existing principal order that executed at a better price.
+For this scenario, Industry Member Broker 1 is required to report the following events:
+• A New Order event for the creation of the principal order
+• The route of the principal order to the exchange (Order Route event)
+• The receipt of the customer order as a New Order event
+• The creation of the representative order as a New Order event
+• The route of the representative order to the exchange as an Order Route event
+• An Order Fulfillment event for the fill of the customer order against the principal order
+
+ 
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.3.8. Route to Foreign Broker
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Route to Foreign Broker
+ Compliance User: Industry Member
Keywords:
- Effective Analysis,
- Competition,
- Promotion,
- NMS Plan,
+ CAT Reporter,
- Section 3(f) of the Exchange Act requires the Commission, whenever it engages in rulemaking and is required to consider or determine whether an action is necessary or appropriate in the public interest, to also consider, in addition to the protection of investors, whether the action would promote efficiency, competition, and capital formation. Further, Section 23(a)(2) of the Exchange Act requires the Commission, when making rules under the Exchange Act, to consider the impact such rules would have on competition. Section 23(a)(2) prohibits the Commission from adopting any rule that would impose a burden on competition not necessary or appropriate in furtherance of the purposes of the Exchange Act.
-The Commission has focused its economic analysis in this Release on the requirement that the SROs develop an NMS plan, rather than on the actual creation, implementation, and maintenance of a consolidated audit trail itself, and is deferring its economic analysis of the actual creation, implementation, and maintenance of a consolidated audit trail itself until such time as it may approve the NMS plan submitted to the Commission for its consideration. The Commission's consideration of the Rule's impact on efficiency, competition, and capital formation is consistent with this approach. Because the Rule focuses only on the process and the requirement of the development of an NMS plan, the Commission believes that the adopted Rule will have minimal, if any, impact on efficiency, competition, and capital formation.
-The Commission regards the adopted Rule as only a step in the multi-step process of developing and approving an NMS plan that will govern the creation, implementation, and maintenance of a consolidated audit trail and the Commission recognizes that the creation, implementation, and maintenance of a consolidated audit trail itself could potentially have effects on efficiency, competition, and capital formation. Therefore, Rule 613(a)(5) specifically provides that the Commission will consider the impact of the NMS plan submitted to the Commission for its consideration on efficiency, competition, and capital formation in determining whether to approve the plan or any amendment thereto. A complete consideration of the impact of the NMS plan, or any amendment thereto, on efficiency, competition, and capital formation, however, requires information that will not be known until the SROs submit their NMS plan or any amendment thereto. Accordingly, the Commission is deferring this analysis until such time as it may approve the NMS plan, or any amendment thereto, submitted by the SROs. To facilitate the consideration of such possible impacts, the Rule requires SROs to provide their own analysis of the plan's potential impact on efficiency, competition, and capital formation.
+This scenario illustrates the reporting requirements to CAT for an Industry Member (Broker 1) that routes an order to a foreign broker-dealer. Because the foreign broker dealer is not a CAT reporter, Broker 1 must report an Order Fulfillment event to represent the outcome of the customer order.
+For this scenario, Industry Member Broker 1 is required to report the following events:
+• A New Order event for the receipt of customer order
+• An Order Route event for the routing of the order to the foreign broker
+• An Order Fulfillment event to show the executed shares given back to the customer
+
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.3.9. Order Fulfillment Amendment
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Order Fulfillment Amendment
+ Compliance User: Industry Member
+ Keywords:
+ In the following scenario, the Industry Member amends the price of a customer fill that was reported to CAT on a previous day.
+For this scenario, Industry Member Broker 1 is only required to report an Order Fulfillment Amendment event for T+1.
+
+ Note that the amendment reporting is only applicable to Order Fulfillment events, not the events reported to the TRF for media dissemination (which would have originally been reported as Trade events).
+
pubdate: N/A effdate: N/A
- D. Implementation of Rule 613 after Approval of the NMS Plan
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Discussion, Implementation of Rule 613 after Approval of the NMS Plan
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Rule 613,
- Implementation,
-
- Proposed Rule 613(a)(3) sets forth a timetable for the implementation of the consolidated audit trail once the Commission has approved an NMS plan. The Commission proposed that the data collection and submission requirements would have applied first to the national securities exchanges and FINRA, and then to their individual members.880 Specifically, proposed Rule 613(a)(3)(iii) would have required the plan sponsors to provide to the central repository the data to be required by the Rule within one year after effectiveness of the NMS plan. Members of the exchanges and FINRA would have been required to begin providing to the central repository the data required by the proposed Rule two years after the effectiveness of the NMS plan.881 This phased approach was intended to allow members additional time to implement the systems changes necessary to begin providing the information to the central repository, including developing procedures to capture any new information required, such as the unique customer and order identifiers.
-Additionally, proposed Rule 613(g)(1) would have required each SRO to file a proposed rule change with the Commission on or before 120 days from approval of Rule 613 to require its members to comply with Rule 613. Further, proposed Rule 613(i) would have required the plan sponsors to jointly provide to the Commission, within two months after effectiveness of the NMS plan, a document outlining how the plan sponsors would propose to incorporate into the consolidated audit trail information with respect to equity securities that are not NMS securities, debt securities, primary market transactions in NMS stocks, primary market transactions in equity securities that are not NMS securities, and primary market transactions in debt securities, including details for each order and reportable event that would be required to be provided, which market participants would be required to provide the data, an implementation timeline, and a cost estimate.
-Although one commenter agreed that the consolidated audit trail could be implemented according to the timeline originally proposed,882 and another urged the Commission to expedite implementation of Rule 613,883 several commenters stated that more time would be necessary to develop and implement the NMS plan.884 Many commenters suggested extended timelines for various aspects of the consolidated audit trail.885 Two commenters, however, argued that the timetable for implementation should be shortened,886 and one of the commenters suggested that the Commission use existing infrastructure, naming OATS as an example, as the basis of the audit trail to save implementation time.887 Another commenter requested that the Commission move the deadline for submission of the joint document from the SROs outlining a proposal of how an expansion could occur from two months, as proposed, to one year after approval of the NMS plan, to allow time to choose a technology provider and build the infrastructure of the system, stating that "[i]t would be far better to develop the design for the initial products and leverage this knowledge to later phases."888
-The Commission also received two comment letters recommending that the Rule contain an exemption to accommodate the business model of small broker-dealers.889
-After considering the comments regarding the proposed timeline for implementation of the Rule, the Commission is adopting Rule 613 with changes to the proposed Rule. First, the Commission is adopting a deadline of 60 days from effectiveness of the NMS plan (rather than 120 days from approval of the Rule, as originally proposed) by when each SRO must file with the Commission proposed rule changes to require its members to comply with the requirements of the Rule and the adopted NMS plan,890 so that SROs can sequence their efforts by acting first on developing the NMS plan to be submitted to the Commission for its consideration, and then on proposed rules requiring compliance by their members. Second, in response to the commenter that advocated extending the deadline for the plan sponsors for submission of the joint document outlining how an expansion could occur from two months, as proposed, to one year after effectiveness of the approved NMS plan, the Commission is modifying the proposed Rule so that the document will be due to the Commission within six months (rather than two months as proposed) after the approval of the NMS plan. The Commission believes that this additional four months will provide the time necessary after the submission of the NMS plan to the Commission for the SROs to plan how to expand the consolidated audit trail to capture orders and trading in these additional securities.891
-The Commission has considered the comment letters that requested an exemption from the proposed Rule for small broker-dealers,892 but, as discussed above,893 does not believe that it is appropriate to completely exempt smaller broker-dealers from the requirements of the consolidated audit trail. While the Commission does not believe that it is appropriate to completely exempt smaller broker-dealers from the Rule, the Commission, in response to commenters' concerns regarding the potential difficulties for small broker-dealers, is modifying the time by when the NMS plan may require small broker-dealers to comply with Rule 613. The Commission is permitting the SROs in the NMS plan to allow small broker-dealers up to three years after effectiveness, rather than two years as proposed, to begin reporting data to the central repository in recognition that some of these firms may still be handling orders manually and thus will need additional time to upgrade to an electronic method.894 Additionally, because many of these broker-dealers may have limited resources, the Commission encourages plan sponsors to propose in the NMS plan a requirement that small broker-dealers report data to the central repository within three years after effectiveness of the NMS plan, as the Commission believes that providing small broker-dealers a longer implementation time should assist such broker-dealers in identifying the most cost-effective and the most efficient manner in which to procure third-party software or make any systems modifications or other changes to comply with Rule 613.
-Rule 613(a)(3)(vi) uses the definition of "small broker-dealer" contained in Exchange Act Rule 0-10: "Small entities under the Securities Exchange Act for purposes of the Regulatory Flexibility Act."895 Rule 0-10(c) defines a "small broker-dealer" as a broker or 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.17a5(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.896 The Commission believes that applying this definition is appropriate because it is an existing regulatory standard that is an indication of small entities for which regulators should be sensitive when imposing regulatory burdens.
-The Commission notes that not all of the timeframes for implementation are being revised.897 As discussed in Section III.B.1.f., above, the Commission has learned through the comment process that technology exists today to "normalize" information collected for the consolidated audit trail into a uniform electronic format, which will allow the required data to be captured and reported to the central repository more readily than the Commission originally anticipated. Accordingly, the Commission believes the remaining proposed implementation timeframes are reasonable and is adopting them as proposed.
+pubdate: N/A effdate: N/A
+ 2.4. Order Modification Scenarios
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios
+ Compliance User: Industry Member
+ Keywords:
+ pubdate: N/A effdate: N/A
+ 2.4.1. Customer Order and Modification
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Customer Order and Modification
+ Compliance User: Industry Member
+ Keywords:
+ Order Modified event,
+
+ This scenario illustrates the reporting requirements to CAT for an Industry Member for a customer initiated modification on an order.
+
+ For this scenario, Industry Member Broker 1 is required to report the following events:
+• New Order event for the customer order
+• Order Modified event upon receipt of customer request
+
+ 
+ pubdate: N/A effdate: N/A
+ 2.4.2. Customer Initiated Modification of Order Previously Routed to Exchange
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Customer Initiated Modification of Order Previously Routed to Exchange
+ Compliance User: Industry Member
+ Keywords:
+ Order Modification event,
+ EXCH1,
+
+ This scenario illustrates a customer-initiated modification of an order which the Industry Member had previously routed to an exchange.
+In this scenario, Industry Member Broker 1 is required to report the following events to CAT:
+• A New Order event for the receipt of customer order
+• Order Route event for the route to the exchange
+• An Order Modification event
+• A second Order Route event for the route of the modified order to the exchange
+
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.4.3. Customer Initiated Modification of Order Previously Routed to Another Industry Member
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Customer Initiated Modification of Order Previously Routed to Another Industry Member
+ Compliance User: Industry Member
+ Keywords:
+ EXCH1,
+
+ This scenario illustrates the reporting requirements to CAT for two Industry Members when a customer of the first Industry Member initiates a modify on an order. The example shown does not illustrate events that would occur following the second Order Route event to account for the New Order and Order Accepted events, such as cancellations, trades, or fulfillments.
+
+ For this scenario, Industry Member Broker 1 is required to report the following events:
+• New Order event for the customer order
+• Order Route event for the routing of the order to Broker 2
+• Order Modified event for customer initiated modification
+• Order Route event for the routing of the modified order to Broker 2
+For this scenario, Industry Member Broker 2 is required to report the following events:
+• Order Accepted event for the received client order from Broker 1
+• Order Modified event upon receiving the modify notice from Broker 1
+
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.4.4. System Driven Modification of Previously Routed Order
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, System Driven Modification of Previously Routed Order
+ Compliance User: Industry Member
+ Keywords:
+ This scenario illustrates the reporting requirements to CAT for two Industry Members when the Industry Member sending an order uses a programmed algorithmic system, which modifies the order routes. Since the order modification is determined by the algorithm and not by the sending Industry Member, the sending Industry Member does not need to report subsequent Order Route events. The modifications driven by the algorithm are captured by the receiving Industry Member in an Order Modified event.
+For this scenario, sending Industry Member Broker 1 is required to report the following events:
+• New Order event for the accept of the customer order
+• Order Route event for the routing of the order to Broker 2
+For this scenario, receiving Industry Member Broker 2 is required to report the following events:
+• Order Accepted event for the received order from Broker 1
+• Order Modified event upon receiving the modify from Broker 1
+
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.4.5. Order Modification of a PEG Order by a Display ATS
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Order Modification of a PEG Order by a Display ATS
+ Compliance User: Industry Member
+ Keywords:
+ Section 6.4(d)(i) of the CAT NMS Plan,
+ Order Adjusted Event,
+ CAT NMS plan,
+ Per CAT FAQ #H1,
+ Broker 1,
+
+ This section will show how an Order Adjusted Event is reported when a display ATS reprices a peg order. Per CAT FAQ #H1, each time an Industry Member reprices a peg order based on a market move (i.e., 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.
+In this scenario, Industry Member Broker 1 routes a customer midpoint PEG order to ATS A. ATS A gives the order a working price upon receipt. Then the NBBO changes while the order stays open on the book. The ATS reprices the order which is required to be reported to CAT.
+Industry Member Broker 1 in this case is required to report:
+• The receipt of customer order (New Order event)
+• The route of the order to the ATS in an Order Route event
+ATS A must report:
+• An Order Accepted event for the receipt of the PEG order from Broker 1
+• The modification of the price due to NBBO changes - this should be reported using an Order Adjusted Event with only the price fields restated
+
+ 
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.4.6. Display Modifications of a Display ATS
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Display Modifications of a Display ATS
+ Compliance User: Industry Member
+ Keywords:
+ Order Adjusted Event,
+
+ Display modifications can be reported to CAT using the Order Adjusted event. This scenario illustrates the reporting requirements when an order is partially executed on an ATS, and as a result the display size of the order changes.
+
+ In this scenario, an order is routed to an ATS for execution. The sending Industry Member Broker 1 is required to report:
+• Receipt of the order from the customer in a New Order event
+• An Order Route event of the order route to ATS A
+ATS A is required to report:
+• An Order Accepted event for the receipt of the order routed from Broker 1
+• Partial execution of the order as a Trade Event
+• Update to the display size post execution as an Order Adjusted event
+Note that ATS A and Broker 1 may have subsequent order handlings on the order. This example is to illustrate the display modification reporting only, so not all possible steps are shown here.
+
+ 
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.4.7. Manual Route, Followed by an Electronic Modification
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Manual Route, Followed by an Electronic Modification
+ Compliance User: Industry Member
+ Keywords:
+ Industry Member Broker 2,
+ Order Route Event,
+ Order Modified event,
+
+ This scenario illustrates the Phase 2a reporting requirement to CAT when an order is initially routed manually between two Industry Members, and then an electronic message is sent to modify the material terms of the order.
+
+ In this scenario, Industry Member Broker 1 must report:
+• Receipt of the customer order in a New Order event
+• Manual route of the order to Broker 2 (Order Route event)
+• Order Modified event for reducing the quantity of the order
+• Route of the modified order to Broker 2 (Order Route event)
+The following must be reported by Industry Member Broker 2:
+• Receipt of the manual route from Broker 1 (Order Accepted event)
+• An Order Modified event for reducing quantity of the order (Order Modified event)
+
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
- IV. Paperwork Reduction Act
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Paperwork Reduction Act
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Information,
- NMS Plan,
-
- Certain provisions of the Rule contain "collection of information requirements" within the meaning of the PRA. The Commission published notice requesting comment on the collection of information requirements in the Proposing Release and submitted the proposed collection to the Office of Management and Budget ("OMB") for review in accordance with 44 U.S.C. 3507 and 5 CFR 1320.11. An agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid OMB control number. The control number for Rule 613 is OMB Control No. 3235-0671 and the title of the new collection of information is "Creation of a Consolidated Audit Trail Pursuant to Section 11A of the Securities Exchange Act of 1934 and Rules thereunder."
-This Release includes the Commission's estimates of the costs to create and file the NMS plan.898 As noted above, the Commission is deferring its economic analysis of the consolidated audit trail (other than with respect to the NMS plan) until after the NMS plan, including the detailed information and analysis, has been submitted by the SROs and there has been an opportunity for public comment.899 Similarly, the Commission is discussing below its estimates of the burden hours associated with the development and filing of the NMS plan but is deferring its discussion of the much more significant burden hours associated with the other paperwork requirements of the consolidated audit trail. The Commission also is deferring its discussion of the ongoing burden hours associated with the NMS plan because such ongoing burdens would only be incurred if the Commission approves the NMS plan. Instead, the Commission will defer these discussions until after the NMS plan, including the detailed information and analysis, has been submitted by the SROs and there has been an opportunity for public comment.
-pubdate: N/A effdate: N/A
- A. Summary of Collection of Information under Rule 613
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Paperwork Reduction Act, Summary of Collection of Information under Rule 613
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Filing of NMS Plan,
- SRO,
- Paperwork,
-
- Rule 613 requires the SROs to develop and file an NMS plan to govern the creation, implementation, and maintenance of a consolidated audit trail and central repository for the collection of information for NMS securities.900 The NMS plan must require each SRO and its respective members to provide certain data to the central repository in compliance with Rule 613.901 The NMS plan also must include a discussion of specified considerations,902 and certain provisions related to administration and operation of the plan903 and the operation of the central repository.904 Further, the NMS plan is required to include certain provisions related to compliance by the SROs and their members with the requirements of the Rule and the NMS plan.905
-The Commission believes that requiring an NMS plan imposes a paperwork burden on the SROs associated with preparing and filing the joint NMS plan.
+pubdate: N/A effdate: N/A
+ 2.5. Cancellation Scenarios
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Cancellation Scenarios
+ Compliance User: Industry Member
+ Keywords:
+ pubdate: N/A effdate: N/A
+ 2.5.1. Order Canceled
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Cancellation Scenarios, Order Canceled
+ Compliance User: Industry Member
+ Keywords:
+ This scenario illustrates the reporting requirements to CAT for an Industry Member when a customer order is canceled on the same day as the order was created.
+For this scenario, Industry Member Broker 1 is required to report the following events:
+• New Order event for the customer order
+• Order Canceled event upon receipt of notice by the customer
+
+ Note that for illustration purposes, actions taken by the Broker between the receipt of the original order and the customer cancellation are not included.
+
+ 
+ pubdate: N/A effdate: N/A
+ 2.5.2. Partial Cancellation of an Order
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Cancellation Scenarios, Partial Cancellation of an Order
+ Compliance User: Industry Member
+ Keywords:
+ The following scenario illustrates the reporting requirements to CAT if the customer partially cancels an order placed with an Industry Member.
+In this scenario, Industry Member Broker 1 must report:
+• The receipt of the customer order as a New Order event
+• Either a Order Canceled event or an Order Modified event for the partial cancellation
+
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.5.3. Cancellation of a Routed Order
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Cancellation Scenarios, Cancellation of a Routed Order
+ Compliance User: Industry Member
+ Keywords:
+ Order Canceled Event,
+
+ This scenario illustrates the CAT reporting requirements for an Industry Member when an order that was previously routed to another Industry Member is canceled.
+
+ Industry Member Broker 1 must report:
+• The receipt of the customer's order as a New Order event
+• The initial route of the order to Broker 2 (an Order Route event)
+• The cancellation of the order (an Order Canceled event)
+Industry Member Broker 2 must report:
+• The receipt of the route from Broker 1 as an Order Accepted event
+• The cancellation of the order as an Order Canceled event
+
+ 
+ 
+ pubdate: N/A effdate: N/A
- B. Use of Information
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Paperwork Reduction Act, Use of Information
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 2.6. Additional Reporting Scenarios
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios
+ Compliance User: Industry Member
Keywords:
- Consolidated Audit trail,
- Commission,
- NMS Plan,
+ Order Accepted Event,
- The information contained in the NMS plan submitted to the Commission for its consideration will provide the Commission and the public with detailed information regarding how the consolidated audit trail will be created, implemented, and maintained in order for the Commission and the public to be able to carefully consider all aspects of the NMS plan. Further, the information contained in the NMS plan should facilitate an analysis of how well the NMS plan will allow regulators to effectively and efficiently carry out their responsibilities.
+pubdate: N/A effdate: N/A
+ 2.6.1. Industry Member Utilizes Multiple Systems at One Desk
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Industry Member Utilizes Multiple Systems at One Desk
+ Compliance User: Industry Member
+ Keywords:
+ In the following scenario, the Industry Member has multiple trading systems utilized at a single desk. For CAT reporting, the Industry Member is not required to report information regarding an order's movement between two systems within the same desk or department as an internal route.
+In this scenario, the desk which received the customer's order transfers the order into another internal application in order to route the order to an exchange. Since the desk handling the order does not change, the Industry Member Broker 1 is required to report:
+• New Order event for the receipt of the customer order
+• Order Route event for route to the exchange
+
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.6.2. Industry Member Creates Child Orders and Routes
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Industry Member Creates Child Orders and Routes
+ Compliance User: Industry Member
+ Keywords:
+ This scenario illustrates the reporting requirements should an Industry Member chose to slice an order into multiple child orders before further handling.
+For this scenario, Industry Member Broker 1 is required to report:
+• Receipt of the customer order as New Order Event
+• A Child Order event for each slice of the order created
+• An Order Route event for each child order
+Receipt Industry Members Broker 2 and 3 are required to report:
+• Order Accepted events for receipts of the order from Broker 1 (and any subsequent order handling)
+
+ 
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.6.3. Industry Member Creates Multiple Branches of Child Orders
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Industry Member Creates Multiple Branches of Child Orders
+ Compliance User: Industry Member
+ Keywords:
+ Order Internal Route event,
+ Participant Order Accepted,
+ Order Route,
+ Child Order,
+
+ This scenario illustrates the reporting requirements for an Industry Member where each internal desk has chosen to work an order by splitting the original order into smaller components. The Industry Member has the flexibility to report different events for each desk, should it better reflect the firm's internal systems.
+
+ For this scenario, Industry Member Broker 1 must report:
+• The receipt of the customer order at the Sales Desk as a New Order event
+• A Child Order event for each slice created at the Sales Desk prior to routing to another desk
+• An Order Internal Route event for each child order
+• For the Child Order sent to the Arbitrage Desk, a Child Order event for each new slice created
+• An Order Route event for each Child Order routed from the Arbitrage Desk
+• For the Child Order sent to the Trading Desk, an Order Internal Route event for each slice of the order (and any subsequent events not shown)
+
+ 
+ 
+ 
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.6.4. Order Received and Routed Manually, Electronically Captured at Subsequent Desk
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Order Received and Routed Manually, Electronically Captured at Subsequent Desk
+ Compliance User: Industry Member
+ Keywords:
+ This scenario illustrates the reporting requirements for an Industry Member when an order is received and then manually internally routed to another department where it is immediately entered into an electronic order management system upon receipt (e.g. the branch receives an order and calls the Trading Desk).
+
+ For this scenario, Industry Member Broker 1 must report:
+• The receipt of the order from the customer (a New Order event with manualFlag = true)
+• An Order Internal Route event for route of the order to the trading desk which will enter the trade into the Industry Member's electronic system
+• The route of the order to the exchange (Order Route event)
+
+ 
+ pubdate: N/A effdate: N/A
+ 2.6.5. Order Routed and Executed via a Clearing Firm
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Order Routed and Executed via a Clearing Firm
+ Compliance User: Industry Member
+ Keywords:
+ This example illustrates the reporting requirements when an introducing firm enters the customer order into the clearing firm's system. The clearing firm then executes the order from a proprietary account. Both the introducing firm and clearing firm are Industry Members.
+
+ For this scenario, the introducing firm (Broker 1) must report:
+• The receipt of the order from the customer in a New Order event
+• The route of the order to the clearing firm in an Order Route event
+The clearing firm would report the following:
+• The receipt of the order by the clearing firm in an Order Accepted event
+• The execution of the order in a Trade event
+Only the executing entity is required to report executions to CAT. In this scenario only the clearing firm is responsible to report a Trade event.
+
+ 
+ pubdate: N/A effdate: N/A
+ 2.6.6. Direct Order Routing via a Clearing Firm's System
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Direct Order Routing via a Clearing Firm's System
+ Compliance User: Industry Member
+ Keywords:
+ This scenario illustrates the reporting requirement when an introducing firm receives a customer order and, using its clearing firm's system, directs the order to an exchange for execution. The clearing firm does not participate in any order routing or handling instructions but only provides the technology to the introducing firm to route the order.
+The introducing firm, Industry Member Broker 1, must report the following to CAT:
+• The receipt of the order from the customer in a New Order event
+• The route of the order to the Exchange 1 in an Order Route event
+The clearing firm does not have CAT reporting obligations.
+The exchange follows Participant reporting requirements for subsequent handling.
+
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.6.7. Order Routing via an Algorithm Provided by the Clearing Firm
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Order Routing via an Algorithm Provided by the Clearing Firm
+ Compliance User: Industry Member
+ Keywords:
+ This scenario illustrates the reporting requirements to CAT when an introducing firm receives a customer order and enters it into its clearing firm's system. The clearing firm's system automatically determines the routing destination based on pre-defined criteria developed by the clearing firm. The clearing firm makes the determination as to where the order is routed. The introducing firm does not direct the order. Both the introducing firm and the clearing firm are Industry Members. In this case, the following CAT events must be reported:
+The introducing firm, Broker 1, must report:
+• The receipt of the customer order in a New Order event
+• The route of the order to the clearing firm in an Order Route event
+The clearing firm must report:
+• The receipt fo the order from the introducing firm in an Order Accepted event
+• The route of the order to the routing destination as an Order Route event
+The routing destination (exchange) must report:
+• The receipt of order routed from the clearing firm
+• The subsequent order handling actives that are CAT reportable
+
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.6.8. Order Routing via Smart Router Provided by another Industry Member
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Order Routing via Smart Router Provided by another Industry Member
+ Compliance User: Industry Member
+ Keywords:
+ Destination Market Center,
+ SEC Rule 11Ac1-6,
+ SEC Rule 606,
+ Handling Instructions,
+ Trade Event,
+
+ In this scenario, the introducing firm receives a customer order and enters it directly to a Smart Router provided by another Industry Member to route the order. The Smart Router provided by another industry member does not need to separately report to CAT when all the following conditions apply:
+1. The Industry Member providing the order routing system has no discretion over the order once it is entered into the Industry Member's order-routing system. The order routing destination ("Destination Market Center") must either be directed by the originating Industry Member or be subject to the pre-determined algorithm of the routing system agreed to by the originating Industry Member. The Industry Member providing the order routing system would have no involvement relating to the routing of the order, other than providing the routing mechanism.
+2. The originating Industry Member must have established a relationship with the Destination Market Center, including meeting any and all applicable requirements to route orders to that destination. The originating Industry Member understands that the Industry Member providing the order routing system has no involvement with respect to the order in any way, except for providing a routing mechanism. No pre-established relationship between the Industry Member providing the order routing system and the Destination Market Center would be necessary for the originating Industry Member to access the routing destination.
+3. The Destination Market Center views the order as coming directly from the originating Industry Member, not the Industry Member providing the order routing system, for all purposes, but not limited to, CAT reporting, trade reporting, applicable fees, etc.
+4. The originating Industry Member, rather than the member providing the order routing system, identifies itself as the routing firm for purposes for the SEC Rule 606 (formerly SEC Rule 11Ac1-6).
+
+ The introducing firm, Industry Member Broker 1, is required to report:
+• The receipt of the customer order in a New Order event
+• The route of the order through a smart router (Order Route event with handlingInstructions = SMT)
+The destination, Industry Member Broker 2, is required to report:
+• The receipt of the order from Broker 1 as an Order Accepted event
+• Execution of the order (Trade event)
+The Industry Member providing the order routing system is not required to report to CAT.
+
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.6.9. GTC Order Routed to Exchange, Modified by Customer
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, GTC Order Routed to Exchange, Modified by Customer
+ Compliance User: Industry Member
+ Keywords:
+ Industry Member Broker 1,
+
+ The following scenario illustrates the reporting requirements for handling order types that can live across days (e.g. GTC, GTD). Industry Member Broker 1 receives a "GTC" order from a customer. From Broker 1's perspective, the order is reported as GTC as maintained on their book. When Broker 1 routes the order to the exchange for execution, the order is a "DAY" order from the exchange's perspective and should be reported as timeInForce = DAY on the Order Route event as well as relevant Participant events. The Industry Member must submit an Order Route event every day the order is sent to the exchange until the order is executed or canceled.
+On T+1, the customer modifies the GTC order. Broker 1 must report an Order Modified event with the original order date and an Order Route event for the modification on the exchange.
+
+ For this scenario, Industry Member Broker 1 is responsible for reporting:
+• The receipt of the customer GTC order on T (New Order event)
+• An Order Route event for the route to the exchange (as a "DAY" order)
+• Another Order Route event for the route to exchange on T+1 (start of day) as the order was not executed or canceled on T
+• The modification of the customer order on T+1 (during market hours) in an Order Modified
+• The route of the modified order to the exchange on T+1 (Order Route event)
+
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.6.10. Dividend Reinvestment
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Dividend Reinvestment
+ Compliance User: Industry Member
+ Keywords:
+ dividend reinvestment investment program (DRIP),
+ Post Trade Allocation events,
+ New Order event,
+ Order Route Event,
+ handlingInstructions = DIV,
+
+ The following scenario illustrates the reporting requirements for an Industry Member whose customers participate in a dividend reinvestment program. Industry Member Broker 1 aggregates dividend reinvestment investment program (DRIP) orders for participating customers, rounds up to the the next whole share, and creates a new order to purchase shares that need to allocate to customers. This order is routed to the street, executed, and allocated to the participating customers. The remaining fractional share is allocated to the proprietary account of Broker 1. It is not required for Broker 1 to report Post Trade Allocation events for allocations to sub-accounts for dividend repurchase orders until Phase 2c.
+
+ For this scenario, Industry Member Broker 1 is responsible for reporting:
+• A New Order event for a single order to acquire shares for all customers participating in the dividend reinvestment program
+• An Order Route event for routing the principal purchase to Broker 2
+Industry Member Broker 2 is responsible for reporting:
+• An Order Accepted event to confirm receipt of the order from Broker 1
+• A Trade event confirming execution of the order
+Once the fractional inventory reaches a whole share threshold, Broker 1 would follow standard procedures for sales from proprietary accounts if actions were taken to flatten fractional share inventory.
+
+ Industry Member Broker 1 is responsible for reporting:
+• A New Order event for the whole share order
+• An Order Route event for routing the sale order to Broker 3
+Industry Member Broker 3 is responsible for reporting:
+• An Order Accepted event for the receipt of the order from Broker 1
+• A Trade event for the execution of the order
+
+ 
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 2.6.11. Routing of the Equity Leg of a Complex Option to another Industry Member
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Routing of the Equity Leg of a Complex Option to another Industry Member
+ Compliance User: Industry Member
+ Keywords:
+ New Order event,
+ Order route events,
+ equity leg order (Sell),
+ equity leg order (Buy),
+
+ This scenario illustrates the reporting requirements when an Industry Member splits the equity leg of complex options from customers. Upon determining the price at which the equity legs must be executed, the Industry Member routes the equity legs to another Industry Member for execution.
+Note that the reporting requirement descriptions and flow chart below only show the equity leg handlings. It does not include the complex option orders or option legs.
+In this scenario, the Industry Member (Broker 1) must report:
+• The receipt of an equity order from the customer (New Order events)
+• The route of the equity order to Broker 2 (Order Route events)
+Industry Member Broker 2 receives the equity leg orders from Broker 1. The orders may come along with an offsetting order to be crossed, or Broker 2 may receive the offsetting order from another Industry Member. Broker 2 then executes as agency cross.
+In this scenario, Broker 2 must report the following events to CAT:
+• The receipt of the equity leg order (Sell) from Broker 1 in an Order Accepted event
+• The receipt of the equity leg order (Buy) from Broker 1 (Or receipt of a Buy order from another Industry Member) in an Order Accepted event
+• The execution of the orders in a Trade Event
+
+ 
+ 
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
- C. Respondents
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Paperwork Reduction Act, Respondents
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Securities association,
-
- Rule 613 applies to the 16 national securities exchanges and to one national securities association (FINRA) currently registered with the Commission.906
+pubdate: N/A effdate: N/A
+ 2.7. JSON and CSV Examples
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, JSON and CSV Examples
+ Compliance User: Industry Member
+ Keywords:
+ This provides an illustration of the different reporting formats of JSON and CSV.
+pubdate: N/A effdate: N/A
+ 2.7.1. JSON Representation
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, JSON and CSV Examples, JSON Representation
+ Compliance User: Industry Member
+ Keywords:
+ JSON representation,
+ Internalized Trade,
+
+ Below is a JSON representation using the example in section 2.2.2 Internalized Trade Against Proprietary Account.
+
+ 
+ pubdate: N/A effdate: N/A
+ 2.7.2. CSV Representation
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, JSON and CSV Examples, CSV Representation
+ Compliance User: Industry Member
+ Keywords:
+ CSV representation,
+
+ Below is the corresponding CSV representation of the same sample events.
+Step 2: New Order Event MENO,20180416T153035.234456,E,false,,,XYZ,O12345,N,T,A,,Buy,10.00,,,50 0,,,LMT,,DAY,REG,,,false,INS001,A,,,N,,false,,,,,,,
+Step 3: New Order Event MENO,20180416T153035.234457,E,false,,,XYZ,P12345,F,T,PR,,Sell,10.00,,, 500,,,LMT,,DAY,REG,,,false,PROP123,P,,,N,,false,,,,,,,
+Step 4: Trade Event MEOT,20180416T153035.253456,false,,,XYZ,TXYZ555,500,10.00,DN,NA,TERM123,O1234 5, FRMA,Buy,0,Agency,TRF123,P12345,FRMA,Sell,0,Principal,TRF123,,,,,,,
+pubdate: N/A effdate: N/A
- D. Total Annual Reporting and Recordkeeping Burden for the Creation and Filing of the NMS Plan
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Paperwork Reduction Act, Total Annual Reporting and Recordkeeping Burden for the Creation and Filing of the NMS Plan
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Estimated Hours,
-
- pubdate: N/A effdate: N/A
- 1. Preliminary Burden Hour Estimates from Proposing Release
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Paperwork Reduction Act, Total Annual Reporting and Recordkeeping Burden for the Creation and Filing of the NMS Plan, Preliminary Burden Hour Estimates from Proposing Release
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 3. Option Scenarios and Examples
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples
+ Compliance User: Industry Member
+ Keywords:
+ This section illustrates reporting scenarios for single leg electronic option events in scope for Phase 2b. Each example includes a process flow table and sample reporting values.
+pubdate: N/A effdate: N/A
+ 3.1. Option Order Origination and Route Scenarios
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Origination and Route Scenarios
+ Compliance User: Industry Member
+ Keywords:
+ This section lays out the fundamental and common reporting scenarios. In addition to the scenarios provided below, please also refer to Equity Event Scenarios 2.1.5 (assume split route is two non-ATS Industry Members) and 2.1.6. The guidance also applies to single leg electronic option order reporting.
+pubdate: N/A effdate: N/A
+ 3.1.1. New Principal Option Order Routed to Exchange and Executed
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Origination and Route Scenarios, New Principal Option Order Routed to Exchange and Executed
+ Compliance User: Industry Member
+ Keywords:
+ New Option Order (Principal),
+ Option Order Route event,
+
+ This scenario illustrates the reporting requirements to CAT for an Industry Member that creates a new principal option order electronically, and electronically routes it to an exchange where it is executed.
+For this scenario, Industry Member Broker 1 is required to report the following events:
+• The creation of a New Option Order (Principal)
+• The route to an exchange as an Option Order Route event
+
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 3.1.2. Customer Option Order Routed to the Exchange
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Origination and Route Scenarios, Customer Option Order Routed to the Exchange
+ Compliance User: Industry Member
+ Keywords:
+ New Option Order event,
+ Option Order Route event,
+
+ This scenario illustrates the reporting requirements to CAT for an Industry Member that routes a customer order to an exchange.
+For this scenario, Industry Member Broker 1 is required to report the following events:
+• New Option Order event for the customer order which was received electronically
+• Option Order Route event for routing the customer order to the exchange
+In this scenario, the execution is passed back directly to the customer, therefore no Option Order Fulfillment is required to be reported.
+
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 3.1.3. Option Order Electronically Routed between Two Industry Members and Subsequently Executed
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Origination and Route Scenarios, Option Order Electronically Routed between Two Industry Members and Subsequently Executed
+ Compliance User: Industry Member
+ Keywords:
+ FLEX Percent option,
+ New Option Order event,
+ Option Order Route event,
+ Option Order Accepted event,
+ Option Order Route event,
+
+ This scenario illustrates the reporting requirements when an option order is electronically routed from one Industry Member to another.
+
+ For this scenario, Industry Member Broker 1 is required to report the following events:
+• New Option Order event for the customer order which was received electronically
+• Option Order Route event for routing the customer option order to Broker 2
+For this scenario, Industry Member Broker 2 is required to report the following events:
+• Option Order Accepted event for receiving the client order from Broker 1
+• Option Order Route event for routing the order to the Exchange
+
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 3.1.4. Customer Option Order Manually Received, Routed Electronically
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Origination and Route Scenarios, Customer Option Order Manually Received, Routed Electronically
+ Compliance User: Industry Member
Keywords:
- Estimated Hours,
+ CAT Reporting,
+ priorUnlinked = M,
- In the Proposing Release, the Commission estimated that each SRO, on average, would spend approximately 840 hours of legal, compliance, information technology, and business operations time to prepare and file the NMS plan. All together the SROs would spend an estimated 12,600 hours.907 The Commission's 840 hour estimate included internal personnel time and external legal costs - 400 Attorney hours, 100 Compliance Manager hours, 220 Programmer Analyst hours, and 120 Business Analyst hours. Commission staff also estimated that each SRO would outsource, on average, 50 hours of legal time to develop and draft the NMS plan, at an average hourly rate of $400, for a total external cost of $20,000 per SRO.908 All together, the SROs would spend an estimated $300,000 in external costs.909
-In making these estimates, the Commission assumed that the burden hours necessary for preparing and filing the NMS plan pursuant to the proposed Rule would be comparable to the burden hours needed to create other existing NMS plans.910 The Commission's estimates included anticipated work hours for Programmer Analysts, Business Analysts, Attorneys and Compliance Managers. The Commission did not receive comments on any of these burden estimates.
+This scenario illustrates the reporting requirements for Phase 2b for a customer order received manually by an Industry Member that is systematized and electronically routed.
+For this scenario, Industry Member Broker 1 is required to report the following events: • Option Order Route event for the route of the option order to the exchange
+In Phase 2b, the Option Order Route event must include the priorUnlinked= M, indicating the prior step is a manual handling not reported in Phase 2b.
+
+ 
+ 
pubdate: N/A effdate: N/A
- 2. Revised Burden Hour Estimates
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Paperwork Reduction Act, Total Annual Reporting and Recordkeeping Burden for the Creation and Filing of the NMS Plan, Revised Burden Hour Estimates
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: N/A effdate: N/A
+ 3.1.5. Customer Option Order Received Electronically, Manually Routed
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Origination and Route Scenarios, Customer Option Order Received Electronically, Manually Routed
+ Compliance User: Industry Member
Keywords:
- Estimated Hours,
- Revised Initial,
- Filing NMS Plan,
- Programmer Analyst,
- Business Analyst,
- Attorney,
- Compliance Manager,
+ Participant Simple Option Order Accepted event,
+ Exchange reports a Participant Simple Option Trade event,
+ nextUnlinked flag,
+ priorUnlinked flag,
- As noted above, the Commission based its original estimates of SRO burden hours to prepare and file the NMS plan on the burden hours spent for existing NMS plans. The Commission, however, has modified the proposed Rule in several significant ways that differentiate the burden hours to prepare the NMS plan from all other existing NMS plans. These modifications require the SROs to expand the NMS plan in the following four ways: (1) provide additional information and analysis to address the considerations that are set forth in Rule 613(a)(1);911 (2) include additional provisions that were not required by the proposed Rule relating to enforcement mechanisms,912 security and confidentiality,913 and the preparation of a document every two years that contains a retrospective assessment of the performance of the consolidated audit trail, as well as a plan to improve its performance;914 (3) address error rates;915 and (4) provide for the creation of an Advisory Committee.916
-a. Revised Initial Burden Hours Needed to Prepare and File the NMS Plan
-In light of these modifications to the proposed Rule, the Commission is increasing substantially its estimated burden hours needed for the development and filing of the NMS plan. The Commission also is adjusting its preliminary burden hour estimates for the preparation and filing of an NMS plan to reflect the registration of two additional SROs after it issued the preliminary estimates.917 The Commission now estimates that the aggregate one-time burden hour amount for preparing and filing an NMS plan would be approximately 2,760 burden hours with $20,000 in external costs per SRO,918 or approximately 46,920 burden hours and $340,000 in external costs in the aggregate,919 compared to an initial estimate of 840 burden hours per SRO with $20,000 in external costs, or approximately 12,600 burden hours in the aggregate and $300,000 in external costs, to prepare and file an NMS plan.920
-The Commission believes that these revised estimates, which include internal SRO personnel time and external legal costs, are appropriate based on the Commission's analysis, set forth below, of the impact of the modifications to the proposed Rule on each of the job categories underlying the estimates. The Commission believes that the modifications to the proposed Rule will require SRO Programmer Analysts, Business Analysts, Attorneys, and Compliance Managers to expend additional time to address the requirements of the Rule. As discussed in more detail below, the Commission anticipates that the SROs will spend additional time on many activities, including: (1) research; (2) discussions with members, committees and with industry associations; (3) vendor negotiations; (4) making decisions regarding the various options and increased flexibility provided by the adopted Rule;921 (5) reviewing alternative NMS plans; (6) choosing between alternative plans and negotiating to reach a consensus on a single NMS plan; (7) providing a detailed estimate of the costs associated with that NMS plan; and (8) drafting the NMS plan. The Commission also believes that these increased estimates are appropriate in light of the comments, including the comment that asserted that the Commission underestimated the time the SROs would spend on the business analyses to be performed in designing the NMS plan, based on the experience of broker-dealers, vendors and SROs when OATS was expanded to all NMS stocks.922 In response, as discussed in more detail below, the Commission is increasing its estimated Programmer Analyst, Business Analyst, Attorney and Compliance Manager hours.
-The Commission notes that these revised average hourly and cost estimates per SRO for creating and filing the NMS plan likely overestimated the costs for some of SROs and underestimated the costs for other SROs. The Commission also believes that certain SROs, particularly those SROs under the same holding company, may decide to collaborate and realize some cost savings on a per SRO basis. On balance, however, the Commission believes that, these revised hours and cost estimates are reasonable on average even if they may not be precise for any specific SRO.
-(i) Programmer Analyst
-The Commission is increasing its estimates for the hours a Programmer Analyst would likely spend with respect to the preparation and filing of the NMS plan from 220 hours, as originally estimated, to 880 hours per SRO. The Commission anticipates that a Programmer Analyst would need to spend substantially more time to address the considerations included in the Rule and the "use cases." Specifically, the SROs will need to rely on Programmer Analysts to help address many of the considerations, as many of those are of a technical nature. For example, several of the considerations relate to the specific features and details of the NMS plan. Programmer Analysts likely will be consulted when the SROs are considering the specific features and details of the NMS plan. The Programmer Analysts likely will provide guidance and information regarding whether a particular feature or detail is technologically possible. The SROs also likely will consult Programmer Analysts when drafting the additional provisions required by the Rule. For example, in drafting the security and confidentiality provisions, Programmer Analysts, who may have knowledge about the information security practices and issues, may be consulted to provide input on a draft provisions in light of technologies with respect to security and confidentiality. Programmer Analysts also may be consulted with respect to addressing errors rates because such analysts may have a technical understanding of trading and reporting systems and be able to provide recommendations on how errors that are introduced can be addressed. In each of these instances, Programmer Analysts may be involved in the NMS plan research, any industry discussions, negotiations with vendors and SROs, and in developing cost estimates for the consolidated audit trail. Thus, for these reasons, the Commission believes it appropriate to increase its estimate of the number of hours expended by Programmer Analysts in the creation and filing of the NMS plan.
-(ii) Business Analyst
-The Commission is increasing its estimates for the hours a Business Analyst would likely spend with respect to the preparation and filing of an NMS plan from 360 hours per SRO, as originally estimated, to 880 hours per SRO. The Commission anticipates that a Business Analyst would spend substantially more time to address the considerations and the "use cases." Overall, the Commission anticipates that this amount of additional time will be comparable to the additional time that would likely be spent by Programmer Analysts for the same reasons because Business Analysts will likely be involved in many of the same tasks as Programmer Analysts, albeit with separate responsibilities. The SROs will need to rely on Business Analysts to help address many technical considerations that have relevance to the business and operations of SROs. The Commission also believes that the SROs will need to rely on Business Analysts to work with the Programmer Analysts and the Compliance Managers to analyze the business impact of particular features and details of the NMS plan. Because Rule 613 is less prescriptive than the proposed Rule, Business Analysts may have a larger role in helping to determine which option the NMS plan will propose. Business Analysts also will likely be involved in determining the cost estimates and in analyzing the NMS plan's impact on efficiency, competition, and capital formation. The SROs also likely will consult with Business Analysts when drafting the responses to the considerations and the "use cases," as well as the additional provisions required by the Rule. For example, the SROs likely will consult with Business Analysts on the feasibility, benefits, and costs of any technological upgrades that may be required in order to provide the allocation information described in Rule 613(a)(1)(vi). Further, in drafting the security and confidentiality provisions, Business Analysts may have knowledge about the costs and the business risks of certain security and confidentiality decisions. Business Analysts also may be consulted with respect to addressing error rates because any decisions made may impact business operations and the cost estimates. Further, Business Analysts may likely be consulted by Attorneys with respect to the performance assessment and improvement plan. In each of these instances, Business Analysts may be involved in the NMS plan research, any industry discussions (particularly with members and other SROs), negotiations with vendors and SROs, and in developing cost estimates for the consolidated audit trail. Thus, for these reasons, the Commission believes it is appropriate to increase its estimate of the number of hours expended by Business Analysts in the creation and filing of the NMS plan.
-(iii) Attorney
-The Commission is increasing its Attorney hour estimates from 400 hours to 700 hours per SRO. The Commission now anticipates that an Attorney would spend substantially more time than the Commission had previously estimated to draft the NMS plan. The NMS plan that Attorneys would draft must now include a discussion of the considerations and the additional provisions required by the Rule, and must reflect additional consultations with Programmer Analysts, Business Analysts and Compliance Managers. Further, the NMS plan drafted also would likely reflect additional consultation on the "use cases." The NMS plan proposal would also likely require Attorney work on the Advisory Committee requirement and on the NMS plan policies and procedures to be used by the plan processor923 to ensure the security and confidentiality and accuracy of the information submitted to the central repository.924 Attorney work would also be required on the mechanism to enforce compliance by plan sponsors with the NMS plan, as required by Rule 613(h)(3), including penalty provisions, if the plan sponsors deem appropriate. The Commission believes that an Attorney would also be involved in the NMS plan research, any industry discussions, negotiations with vendors, negotiations with SROs (in particular, to reach consensus on an NMS plan), and in developing cost estimates for the consolidated audit trail. Thus, for these reasons, the Commission believes it appropriate to increase its estimate of the number of hours expended by Attorneys in the creation and filing of the NMS plan.
-(iv) Compliance Manager
-The Commission is increasing its Compliance Manager hour estimates from 100 hours to 300 hours per SRO. The Commission now anticipates that a Compliance Manager would spend substantially more time than the Commission had previously estimated to draft the NMS plan. Compliance Managers likely will help shape provisions of the NMS plan that deal with monitoring member and SRO compliance with the NMS plan's requirements. Compliance Managers likely will also be involved in the Advisory Committee requirement. They likely will also work on NMS plan policies and procedures to be used by the plan processor to ensure the security and confidentiality and accuracy of the information submitted to the central repository, and to ensure that these policies and procedures are feasible for SRO compliance and for member compliance.925 They will likely also work on the mechanism to enforce compliance by plan sponsors with the NMS plan, as required by Rule 613(h)(3), including penalty provisions, if the plan sponsors deem appropriate. Further, Compliance Managers will also work on NMS plan provisions that address error rates and performance assessment and improvement. The Commission believes that Compliance Managers may also be involved in the NMS plan research and industry discussions (particularly with regard to SRO and member compliance issues). Thus, for these reasons, the Commission believes it is appropriate to increase its estimate of the number of hours expended by Compliance Managers in the creation and filing of the NMS plan.
+This scenario illustrates the reporting requirement for Phase 2b for a customer order received electronically by an Industry Member that is manually routed to another Industry Member. The order is then subsequently routed to the exchange.
+
+ For this scenario, Industry Member Broker 1 is required to report the following events:
+• New Option Order event for the customer order which was received electronically (The nextUnlinked flag must be marked as "M" indicating next step is a manual handling so no linkage is available)
+For this scenario, Industry Member Broker 2 is required to report the following events:
+• Option Order Route event for the route of the option order to the exchange (The priorUnlinked flag must be marked as "M" indicating prior step is a manual handling so no linkage is available)
+
+ 
pubdate: N/A effdate: N/A
- E Collection of Information is Mandatory
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Paperwork Reduction Act, Collection of Information is Mandatory
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Collection,
-
- The collection of information discussed above is a mandatory collection of information.
+pubdate: N/A effdate: N/A
+ 3.2. Fulfillment Scenario s
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Fulfillment Scenario s
+ Compliance User: Industry Member
+ Keywords:
+ pubdate: N/A effdate: N/A
+ 3.2.1. Broker Receives Single-Leg Electronic Orders, Creates Complex Order and Routes to Exchange
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Fulfillment Scenario s, Broker Receives Single-Leg Electronic Orders, Creates Complex Order and Routes to Exchange
+ Compliance User: Industry Member
+ Keywords:
+ nextUnlinked = C,
+ fulfillmentLinkType = YF,
+ priorUnlinked = C,
+ New Option Order events,
+ Option Order Fulfillment events,
+
+ This scenario illustrates the Phase 2b reporting requirements for Industry Members when a complex option order is created from multiple single leg option orders. For Phase 2b, there is no linkage required between the single leg option orders and the complex order.
+
+ For this scenario, Industry Member Broker 1 is required to report the following events:
+• New Option Order events for each single leg customer order electronically received
+• Option Order Fulfillment events for each single leg customer order post execution of the complex order
+In Phase 2b, the two New Option Order events must be flagged as nextUnlinked = C, indicating that the orders are represented by a complex order so no linkage to the complex order in Phase 2b.
+
+ 
+ 
+ pubdate: N/A effdate: N/A
- F. Confidentiality
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Paperwork Reduction Act, Confidentiality
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Policies,
- Reporting,
- Central Repository,
-
- The Rule requires that the data to be recorded and reported to the central repository will only be available to the SROs and the Commission for the purpose of performing their respective regulatory and oversight responsibilities pursuant to the federal securities laws, rules, and regulations.926 Further, the NMS plan submitted to the Commission for its consideration pursuant to the adopted Rule is required to include policies and procedures to ensure the security and confidentiality of all information submitted to the central repository, and to ensure that all plan sponsors and their employees, as well as all employees of the central repository, use appropriate safeguards to ensure the confidentiality of such data and shall agree not to use such data for any purpose other than surveillance and regulatory purposes.927
+pubdate: N/A effdate: N/A
+ 3.3. Option Order Modification Scenarios
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Modification Scenarios
+ Compliance User: Industry Member
+ Keywords:
+ This section illustrates the common scenarios of single-leg option modifications and the CAT reporting requirements for Phase 2b. In addition to the scenarios provided below, please refer to Equity Event Scenarios 2.4.1,2.4.3, and 2.4.4. The guidance also applies to single leg electronic option order reporting.
+pubdate: N/A effdate: N/A
+ 3.3.1. Customer Initiates Modification of Option Order Previously Routed to the Exchange
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Modification Scenarios, Customer Initiates Modification of Option Order Previously Routed to the Exchange
+ Compliance User: Industry Member
+ Keywords:
+ New Option Order event,
+ Option Order Route event,
+ Option Order Modification event,
+ second Option Order Route event,
+
+ This scenario illustrates a customer-initiated modification (electronically) of an option order which the Industry Member had previously routed to an exchange.
+In this scenario, Industry Member Broker 1 is required to report the following events:
+• A New Option Order event for the electronic receipt of the customer order
+• Option Order Route event for the route to the exchange
+• An Option Order Modification event for the electronic receipt of the order modification
+• A second Option Order Route event for the route of the modified option order to the exchange
+
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
- G. Retention Period of Recordkeeping Requirements
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Paperwork Reduction Act, Retention Period of Recordkeeping Requirements
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Rule 17a-1,
- Retention,
-
- The SROs are required to retain records and information pursuant to Rule 17a-1 under the Exchange Act.928 Members are required to retain records and information in accordance with Rule 17a-4 under the Exchange Act.929
+pubdate: N/A effdate: N/A
+ 3.4. Cancellation Scenarios
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Cancellation Scenarios
+ Compliance User: Industry Member
+ Keywords:
+ Reporting option order cancellations follow the same guidance as equities. Please refer to Section 2.5 for examples.
+pubdate: N/A effdate: N/A
+ 3.5. Additional Reporting Scenarios
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios
+ Compliance User: Industry Member
+ Keywords:
+ In addition to the scenarios provided below, please refer to Equity Event Scenarios 2.6.1, 2.6.3, 2.6.6, 2.6.7, 2.6.8, and 2.6.9. The guidance also applies to single leg electronic option order reporting.
+pubdate: N/A effdate: N/A
+ 3.5.1. Customer Option Order Internally Routed Electronically
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Customer Option Order Internally Routed Electronically
+ Compliance User: Industry Member
+ Keywords:
+ eventTimestamp,
+ openCloseIndicator,
+
+ This scenario illustrates the reporting requirements for CAT when an Industry Member internally routes a customer option order from the sales desk to the trading desk within the same Industry Member firm.
+For this scenario, Industry Member Broker 1 is required to report the following events:
+• New Option Order event for the customer order which was received electronically
+• Option Order Internal Route event from the sales desk to the trading desk
+• Option Order Route event for the route of the option order to the exchange
+
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 3.5.2. Customer Option Order Internally Routed Electronically, Trading Desk Creates Child Orders Prior to Route
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Customer Option Order Internally Routed Electronically, Trading Desk Creates Child Orders Prior to Route
+ Compliance User: Industry Member
+ Keywords:
+ Child Order events,
+ Option Order Internal Route event,
+ orderIDs,
+ Option Order Route events,
+
+ This scenario illustrates the reporting requirements for an Industry Member that creates child orders prior to routing the order slices. Child Order events are always electronically created.
+For this scenario, Industry Member Broker 1 is required to report the following events:
+• New Option Order event for the customer order which was received electronically
+• Option Order Internal Route event from the sales desk to the trading desk
+• Child Order events for slicing the original order into smaller quantities and assigning new orderIDs prior to routing from the Trading Desk
+• Option Order Route events for the route of each child option order to an exchange
+
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 3.5.3. Industry Member Receives Complex Option Order, Splits into Individual Single Order Legs to be Worked in the Customer's Account
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Industry Member Receives Complex Option Order, Splits into Individual Single Order Legs to be Worked in the Customer's Account
+ Compliance User: Industry Member
+ Keywords:
+ priorUnlinked = C,
+
+ This scenario illustrates the reporting requirements for an Industry Member in Phase 2b that receives a complex option order but routes single leg option orders directly from the customer's account to the exchange without creating new single leg option orders. Linkage between the original complex option order and the single leg option order routes is not required in Phase 2b, but reporters must indicate on the Option Order Route event there is no prior step reported since it was a complex order by populating field priorUnlinked = C. Since the single leg orders were routed to the exchange as single legs, linkage to the related single leg exchange order is required.
+In this scenario, Industry Member Broker 1 is required to report the following events:
+• Option Order Route events for each single leg option order routed to the exchange
+
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 3.5.4. Industry Member Receives Complex Option Order, but Client Sends Multiple Single Leg Option Orders Electronically
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Industry Member Receives Complex Option Order, but Client Sends Multiple Single Leg Option Orders Electronically
+ Compliance User: Industry Member
+ Keywords:
+ handlingInstruction 'CMPX,
+ nextUnlinked = 'C,
+
+ This scenario illustrates the reporting requirements for an Industry Member that receives a complex order that is routed by the Industry Member to an exchange as a complex order but where the client sends single leg electronic messages due to limitations in the client's system.
+For Phase 2b, reporting this order is out of scope as it was intended to be handled as a complex order. In Phase 2b, the preferred approach is that the Industry Member not report the electronic single leg orders as complex orders are not in scope. However, if Industry Member's elects to report the single legs, they must populate handlingInstruction 'CMPX' and include the nextUnlinked = 'C', to indicate there is no linkage to additional order events as subsequent handling was at the complex order level.
+
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 3.5.5. Industry Member Routes Multiple Single Leg Option Orders to another Industry Member, Calls with Complex Order Instructions
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Industry Member Routes Multiple Single Leg Option Orders to another Industry Member, Calls with Complex Order Instructions
+ Compliance User: Industry Member
+ Keywords:
+ Option Order Route,
+
+ This scenario illustrates the reporting requirements for Phase 2b when a complex order is routed manually between two Industry Members, but the related electronic order messages are sent and received as single leg option orders. In Phase 2b, the preferred approach is that the Industry Member not report the electronic single leg orders as complex orders are not in scope. However, if Industry Member's elects to report the single legs, they must include handlingInstruction = 'CMPX'. The sending Industry Member must populate nextUnlinked = C on the Option Order Routes events, as no linkage will be available to the complex order at the receiving broker. Similarly, the receiving Industry Member should populate priorUnlinked = C on the Option Order Accepted events.
+In this scenario, if suppression of the electronic message is not possible, Industry Member Broker 1 would report the following events:
+• Four (4) New Option Order events for the electronic single leg orders
+• Four (4) Option Order Route events for the route of the single leg orders to Broker 2
+Industry Member Broker 2 would report the following events:
+• Four (4) Option Order Accepted events for the electronic routes received from Broker 1
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 3.5.6. Industry Member Solicits Order, Creates Paired Option for Partial Quantity
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Industry Member Solicits Order, Creates Paired Option for Partial Quantity
+ Compliance User: Industry Member
+ Keywords:
+ Industry Member Broker,
+
+ This scenario illustrates the reporting requirements for an Industry Member that electronically received a single leg order from a customer, solicits another Industry Member to pair the order, but is left with a partial quantity of the single leg order still to work. Only the single leg components of the lifecycle are required for CAT reporting in Phase 2b, as paired option orders are not required until Phase 2d.
+In this scenario, Industry Member Broker 1 is required to report the following events:
+• New Option Order event for the receipt of the customer order
+• Option Order Route for the un-paired quantity of the single leg order
+
+ 
+ 
+ 
+ pubdate: N/A effdate: N/A
+ 3.5.7. Response to an Exchange Auction
+Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Response to an Exchange Auction
+ Compliance User: Industry Member
+ Keywords:
+ Exchange Auction,
+
+ This scenario illustrates the reporting requirements for a proprietary option order created in response to an Exchange Auction of a simple option or paired order of simple options. Responses to the complex auctions are deferred until 2D. The Industry Member must include the auction details on the handlingInstructions when reporting to CAT.
+In this scenario, Industry Member Market Maker 1 is required to report the following events:
+• New Option Order event for the creation of the proprietary order
+• Option Order Route event for the response to the exchange auction
+
+ 
+ 
+ pubdate: N/A effdate: N/A
- V. Regulatory Flexibility Act Certification
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Regulatory Flexibility Act Certification
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Administrative Procedure Act,
- RFA,
- Rule 605(b),
- FINRA,
- NMS Plan,
-
- The Regulatory Flexibility Act ("RFA")930 requires Federal agencies, in promulgating rules, to consider the impact of those rules on small entities. Section 603(a) of the Administrative Procedure Act, as amended by RFA, generally requires the Commission to undertake a regulatory flexibility analysis of all proposed rules, or proposed rule amendments, to determine the impact of such rulemaking on "small entities."931 Rule 605(b) of the RFA states that this requirement shall not apply to any proposed rule or proposed rule amendment, which if adopted, would not "have a significant economic impact on a substantial number of small entities."932
-In the Proposing Release, the Commission requested comment on whether proposed Rule 613 would have a significant economic impact on a substantial number of small entities, and, if so, what would be the nature of any impact on small entities.933 The Commission also requested that commenters provide empirical data to support the extent of such impact.934 The Commission received two comments on the general anticipated effect of the proposed Rule on small-broker dealers; FINRA and a small broker-dealer that solely handles orders manually requested that an exemption from the proposed Rule be adopted to accommodate the business model of small broker-dealers.935 In response to the commenters, the Commission amended the Rule as proposed to provide additional time for small broker-dealers to comply with the reporting requirements of Rule 613.936 The Commission notes that none of the comment letters received specifically responded to the Commission's initial regulatory flexibility analysis.
-As proposed and as adopted, Rule 613 requires the SROs to file an NMS plan to create, implement, and maintain the consolidated audit trail. In response to commenters and as discussed in this release, the Commission has modified the proposed Rule to provide the SROs with a range of options and greater flexibility for how they choose to meet the requirements of the Rule. As a result, the Commission will not know the specific requirements of the NMS plan until it is filed with the Commission, and cannot analyze how the NMS plan will impact small entities until then. At this time, there are no small entities "subject to the requirements" of Rule 613.937
-However, because Rule 613 requires that the national securities exchanges and national securities associations (i.e., FINRA) file an NMS plan with the Commission, for purposes of the RFA, the Commission is undertaking an analysis of how the NMS plan filing requirement will impact the exchanges and FINRA to ascertain whether the exchanges and FINRA are "small businesses." Paragraph (e) of Rule 0-10 provides that for the purposes of the RFA, an exchange is considered a "small business" if it has been exempted from the reporting requirements of Rule 601 of Regulation NMS,938 and is not affiliated with any person (other than a natural person) that is not a small business or small organization as defined in Rule 0-10. Under this standard, none of the national securities exchanges subject to Rule 613 is a "small business" for purposes of the RFA. In addition, FINRA is not a small entity as defined in Rule 0-10.939 Therefore, the Commission believes that Rule 613, which requires that the SROs file an NMS plan with the Commission to create, implement, and maintain the consolidated audit trail, will not have a significant economic impact on a substantial number of small entities because this requirement will only apply to the existing national securities exchanges and national securities associations, which do not qualify as small entities pursuant to the RFA.
-For the foregoing reasons, the Commission hereby certifies that, pursuant to 5 U.S.C. 605(b), Rule 613 will not have a significant economic impact on a substantial number of small entities.
-pubdate: N/A effdate: N/A
- VI. Statutory Authority
-Topic: SEC Final Rule, Release No. 34-67457, Supplementary Information, Statutory Authority
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- 17 CFR Part 242,
- § 242.613,
- Data Recording,
- Data Reporting,
- CAT-Order,
-
- Pursuant to the Exchange Act and particularly, Sections 2, 3(b), 5, 6, 11A, 15, 15A, 17(a) and (b), 19, and 23(a) thereof, 15 U.S.C. 78b, 78c(b), 78e, 78f, 78k-1, 78o, 78o-3, 78q(a) and (b), 78s and 78w(a), the Commission is adopting Rule 613 of Regulation NMS, as set forth below.
-Text of Rule
-List of Subjects in 17 CFR Part 242
-Brokers, Reporting and recordkeeping requirements, Securities.
-In accordance with the foregoing, Title 17, Chapter II, of the Code of Federal Regulations is amended as follows.
-PART 242 — REGULATIONS M, SHO, ATS, AC, AND NMS AND CUSTOMER MARGIN REQUIREMENTS FOR SECURITY FUTURES
-1. The authority citation for part 242 continues to read as follows:
-Authority: 15 U.S.C. 77g, 77q(a), 77s(a), 78b, 78c, 78g(c)(2), 78i(a), 78j, 78k-1(c), 78l, 78m, 78n, 78o(b), 78o(c), 78o(g), 78q(a), 78q(b), 78q(h), 78w(a), 78dd-1, 78mm, 80a-23, 80a-29, and 80a-37.
-2. Add § 242.613 to read as follows:
-§ 242.613 Consolidated Audit Trail.
-(a) Creation of a National Market System Plan Governing a Consolidated Audit Trail.
-(1) Each national securities exchange and national securities association shall jointly file on or before 270 days from the date of publication of the Adopting Release in the Federal Register a national market system plan to govern the creation, implementation, and maintenance of a consolidated audit trail and central repository as required by this section. The national market system plan shall discuss the following considerations:
-(i) The method(s) by which data will be reported to the central repository including, but not limited to, the sources of such data and the manner in which the central repository will receive, extract, transform, load, and retain such data; and the basis for selecting such method(s);
-(ii) The time and method by which the data in the central repository will be made available to regulators, in accordance with paragraph (e)(1) of this section, to perform surveillance or analyses, or for other purposes as part of their regulatory and oversight responsibilities;
-(iii) The reliability and accuracy of the data reported to and maintained by the central repository throughout its lifecycle, including transmission and receipt from market participants; data extraction, transformation and loading at the central repository; data maintenance and management at the central repository; and data access by regulators;
-(iv) The security and confidentiality of the information reported to the central repository;
-(v) The flexibility and scalability of the systems used by the central repository to collect, consolidate and store consolidated audit trail data, including the capacity of the consolidated audit trail to efficiently incorporate, in a cost-effective manner, improvements in technology, additional capacity, additional order data, information about additional securities or transactions, changes in regulatory requirements, and other developments;
-(vi) The feasibility, benefits, and costs of broker-dealers reporting to the consolidated audit trail in a timely manner:
-(A) The identity of all market participants (including broker-dealers and customers) that are allocated NMS securities, directly or indirectly, in a primary market transaction;
-(B) The number of such securities each such market participant is allocated; and
-(C) The identity of the broker-dealer making each such allocation;
-(vii) The detailed estimated costs for creating, implementing, and maintaining the consolidated audit trail as contemplated by the national market system plan, which estimated costs should specify:
-(A) An estimate of the costs to the plan sponsors for establishing and maintaining the central repository;
-(B) An estimate of the costs to members of the plan sponsors, initially and on an ongoing basis, for reporting the data required by the national market system plan;
-(C) An estimate of the costs to the plan sponsors, initially and on an ongoing basis, for reporting the data required by the national market system plan; and
-(D) How the plan sponsors propose to fund the creation, implementation, and maintenance of the consolidated audit trail, including the proposed allocation of such estimated costs among the plan sponsors, and between the plan sponsors and members of the plan sponsors;
-(viii) An analysis of the impact on competition, efficiency and capital formation of creating, implementing, and maintaining of the national market system plan;
-(ix) A plan to eliminate existing rules and systems (or components thereof) that will be rendered duplicative by the consolidated audit trail, including identification of such rules and systems (or components thereof); to the extent that any existing rules or systems related to monitoring quotes, orders, and executions provide information that is not rendered duplicative by the consolidated audit trail, an analysis of:
-(A) Whether the collection of such information remains appropriate;
-(B) If still appropriate, whether such information should continue to be separately collected or should instead be incorporated into the consolidated audit trail; and
-(C) If no longer appropriate, how the collection of such information could be efficiently terminated; the steps the plan sponsors propose to take to seek Commission approval for the elimination of such rules and systems (or components thereof); and a timetable for such elimination, including a description of how the plan sponsors propose to phase in the consolidated audit trail and phase out such existing rules and systems (or components thereof);
-(x) Objective milestones to assess progress toward the implementation of the national market system plan;
-(xi) The process by which the plan sponsors solicited views of their members and other appropriate parties regarding the creation, implementation, and maintenance of the consolidated audit trail, a summary of the views of such members and other parties, and how the plan sponsors took such views into account in preparing the national market system plan; and
-(xii) Any reasonable alternative approaches to creating, implementing, and maintaining a consolidated audit trail that the plan sponsors considered in developing the national market system plan including, but not limited to, a description of any such alternative approach; the relative advantages and disadvantages of each such alternative, including an assessment of the alternative's costs and benefits; and the basis upon which the plan sponsors selected the approach reflected in the national market system plan.
-(2) The national market system plan, or any amendment thereto, filed pursuant to this section shall comply with the requirements in § 242.608(a), if applicable, and be filed with the Commission pursuant to § 242.608.
-(3) The national market system plan submitted pursuant to this section shall require each national securities exchange and national securities association to:
-(i) Within two months after effectiveness of the national market system plan jointly (or under the governance structure described in the plan) select a person to be the plan processor;
-(ii) Within four months after effectiveness of the national market system plan synchronize their business clocks and require members of each such exchange and association to synchronize their business clocks in accordance with paragraph (d) of this section;
-(iii) Within one year after effectiveness of the national market system plan provide to the central repository the data specified in paragraph (c) of this section;
-(iv) Within fourteen months after effectiveness of the national market system plan implement a new or enhanced surveillance system(s) as required by paragraph (f) of this section;
-(v) Within two years after effectiveness of the national market system plan require members of each such exchange and association, except those members that qualify as small broker-dealers as defined in § 240.0-10(c) of this chapter, to provide to the central repository the data specified in paragraph (c) of this section; and
-(vi) Within three years after effectiveness of the national market system plan require members of each such exchange and association that qualify as small broker-dealers as defined in § 240.0-10(c) of this chapter to provide to the central repository the data specified in paragraph (c) of this section.
-(4) Each national securities exchange and national securities association shall be a sponsor of the national market system plan submitted pursuant to this section and approved by the Commission.
-(5) No national market system plan filed pursuant to this section, or any amendment thereto, shall become effective unless approved by the Commission or otherwise permitted in accordance with the procedures set forth in § 242.608. In determining whether to approve the national market system plan, or any amendment thereto, and whether the national market system plan or any amendment thereto is in the public interest under § 242.608(b)(2), the Commission shall consider the impact of the national market system plan or amendment, as applicable, on efficiency, competition, and capital formation.
-(b) Operation and Administration of the National Market System Plan.
-(1) The national market system plan submitted pursuant to this section shall include a governance structure to ensure fair representation of the plan sponsors, and administration of the central repository, including the selection of the plan processor.
-(2) The national market system plan submitted pursuant to this section shall include a provision addressing the requirements for the admission of new sponsors of the plan and the withdrawal of existing sponsors from the plan.
-(3) The national market system plan submitted pursuant to this section shall include a provision addressing the percentage of votes required by the plan sponsors to effectuate amendments to the plan.
-(4) The national market system plan submitted pursuant to this section shall include a provision addressing the manner in which the costs of operating the central repository will be allocated among the national securities exchanges and national securities associations that are sponsors of the plan, including a provision addressing the manner in which costs will be allocated to new sponsors to the plan.
-(5) The national market system plan submitted pursuant to this section shall require the appointment of a Chief Compliance Officer to regularly review the operation of the central repository to assure its continued effectiveness in light of market and technological developments, and make any appropriate recommendations for enhancements to the nature of the information collected and the manner in which it is processed.
-(6) The national market system plan submitted pursuant to this section shall include a provision requiring the plan sponsors to provide to the Commission, at least every two years after effectiveness of the national market system plan, a written assessment of the operation of the consolidated audit trail. Such document shall include, at a minimum:
-(i) An evaluation of the performance of the consolidated audit trail including, at a minimum, with respect to data accuracy (consistent with paragraph (e)(6) of this section), timeliness of reporting, comprehensiveness of data elements, efficiency of regulatory access, system speed, system downtime, system security (consistent with paragraph (e)(4) of this section), and other performance metrics to be determined by the Chief Compliance Officer, along with a description of such metrics;
-(ii) A detailed plan, based on such evaluation, for any potential improvements to the performance of the consolidated audit trail with respect to any of the following: improving data accuracy; shortening reporting timeframes; expanding data elements; adding granularity and details regarding the scope and nature of Customer-IDs; expanding the scope of the national market system plan to include new instruments and new types of trading and order activities; improving the efficiency of regulatory access; increasing system speed; reducing system downtime; and improving performance under other metrics to be determined by the Chief Compliance Officer;
-(iii) An estimate of the costs associated with any such potential improvements to the performance of the consolidated audit trail, including an assessment of the potential impact on competition, efficiency, and capital formation; and
-(iv) An estimated implementation timeline for any such potential improvements, if applicable.
-(7) The national market system plan submitted pursuant to this section shall include an Advisory Committee which shall function in accordance with the provisions set forth in this paragraph (b)(7). The purpose of the Advisory Committee shall be to advise the plan sponsors on the implementation, operation, and administration of the central repository.
-(i) The national market system plan submitted pursuant to this section shall set forth the term and composition of the Advisory Committee, which composition shall include representatives of the member firms of the plan sponsors.
-(ii) Members of the Advisory Committee shall have the right to attend any meetings of the plan sponsors, to receive information concerning the operation of the central repository, and to provide their views to the plan sponsors; provided, however, that the plan sponsors may meet without the Advisory Committee members in executive session if, by affirmative vote of a majority of the plan sponsors, the plan sponsors determine that such an executive session is required.
-(c) Data Recording and Reporting.
-(1) The national market system plan submitted pursuant to this section shall provide for an accurate, time-sequenced record of orders beginning with the receipt or origination of an order by a member of a national securities exchange or national securities association, and further documenting the life of the order through the process of routing, modification, cancellation, and execution (in whole or in part) of the order.
-(2) The national market system plan submitted pursuant to this section shall require each national securities exchange, national securities association, and member to report to the central repository the information required by paragraph (c)(7) of this section in a uniform electronic format, or in a manner that would allow the central repository to convert the data to a uniform electronic format, for consolidation and storage.
-(3) The national market system plan submitted pursuant to this section shall require each national securities exchange, national securities association, and member to record the information required by paragraphs (c)(7)(i) through (v) of this section contemporaneously with the reportable event. The national market system plan shall require that information recorded pursuant to paragraphs (c)(7)(i) through (v) of this section must be reported to the central repository by 8: 00 a.m. Eastern Time on the trading day following the day such information has been recorded by the national securities exchange, national securities association, or member. The national market system plan may accommodate voluntary reporting prior to 8: 00 a.m. Eastern Time, but shall not impose an earlier reporting deadline on the reporting parties.
-(4) The national market system plan submitted pursuant to this section shall require each member of a national securities exchange or national securities association to record and report to the central repository the information required by paragraphs (c)(7)(vi) through (viii) of this section by 8: 00 a.m. Eastern Time on the trading day following the day the member receives such information. The national market system plan may accommodate voluntary reporting prior to 8: 00 a.m. Eastern Time, but shall not impose an earlier reporting deadline on the reporting parties.
-(5) The national market system plan submitted pursuant to this section shall require each national securities exchange and its members to record and report to the central repository the information required by paragraph (c)(7) of this section for each NMS security registered or listed for trading on such exchange or admitted to unlisted trading privileges on such exchange.
-(6) The national market system plan submitted pursuant to this section shall require each national securities association and its members to record and report to the central repository the information required by paragraph (c)(7) of this section for each NMS security for which transaction reports are required to be submitted to the association.
-(7) The national market system plan submitted pursuant to this section shall require each national securities exchange, national securities association, and any member of such exchange or association to record and electronically report to the central repository details for each order and each reportable event, including, but not limited to, the following information:
-(i) For original receipt or origination of an order:
-(A) Customer-ID(s) for each customer;
-(B) The CAT-Order-ID;
-(C) The CAT-Reporter-ID of the broker-dealer receiving or originating the order;
-(D) Date of order receipt or origination;
-(E) Time of order receipt or origination (using time stamps pursuant to paragraph (d)(3) of this section); and
-(F) Material terms of the order.
-(ii) For the routing of an order, the following information:
-(A) The CAT-Order-ID;
-(B) Date on which the order is routed;
-(C) Time at which the order is routed (using time stamps pursuant to paragraph (d)(3) of this section);
-(D) The CAT-Reporter-ID of the broker-dealer or national securities exchange routing the order;
-(E) The CAT-Reporter-ID of the broker-dealer, national securities exchange, or national securities association to which the order is being routed;
-(F) If routed internally at the broker-dealer, the identity and nature of the department or desk to which an order is routed; and
-(G) Material terms of the order.
-(iii) For the receipt of an order that has been routed, the following information:
-(A) The CAT-Order-ID;
-(B) Date on which the order is received;
-(C) Time at which the order is received (using time stamps pursuant to paragraph (d)(3) of this section);
-(D) The CAT-Reporter-ID of the broker-dealer, national securities exchange, or national securities association receiving the order;
-(E) The CAT-Reporter-ID of the broker-dealer or national securities exchange routing the order; and
-(F) Material terms of the order.
-(iv) If the order is modified or cancelled, the following information:
-(A) The CAT-Order-ID;
-(B) Date the modification or cancellation is received or originated;
-(C) Time the modification or cancellation is received or originated (using time stamps pursuant to paragraph (d)(3) of this section);
-(D) Price and remaining size of the order, if modified;
-(E) Other changes in material terms of the order, if modified; and
-(F) The CAT-Reporter-ID of the broker-dealer or Customer-ID of the person giving the modification or cancellation instruction.
-(v) If the order is executed, in whole or part, the following information:
-(A) The CAT-Order-ID;
-(B) Date of execution;
-(C) Time of execution (using time stamps pursuant to paragraph (d)(3) of this section);
-(D) Execution capacity (principal, agency, riskless principal);
-(E) Execution price and size;
-(F) The CAT-Reporter-ID of the national securities exchange or broker-dealer executing the order; and
-(G) Whether the execution was reported pursuant to an effective transaction reporting plan or the Plan for Reporting of Consolidated Options Last Sale Reports and Quotation Information.
-(vi) If the order is executed, in whole or part, the following information:
-(A) The account number for any subaccounts to which the execution is allocated (in whole or part);
-(B) The CAT-Reporter-ID of the clearing broker or prime broker, if applicable; and
-(C) The CAT-Order-ID of any contra-side order(s).
-(vii) If the trade is cancelled, a cancelled trade indicator.
-(viii) For original receipt or origination of an order, the following information:
-(A) Information of sufficient detail to identify the customer; and
-(B) Customer account information.
-(8) All plan sponsors and their members shall use the same Customer-ID and CAT-Reporter-ID for each customer and broker-dealer.
-(d) Clock Synchronization and Time Stamps. The national market system plan submitted pursuant to this section shall require:
-(1) Each national securities exchange, national securities association, and member of such exchange or association to synchronize its business clocks that are used for the purposes of recording the date and time of any reportable event that must be reported pursuant to this section to the time maintained by the National Institute of Standards and Technology, consistent with industry standards;
-(2) Each national securities exchange and national securities association to evaluate annually the clock synchronization standard to determine whether it should be shortened, consistent with changes in industry standards; and
-(3) Each national securities exchange, national securities association, and member of such exchange or association to utilize the time stamps required by paragraph (c)(7) of this section, with at minimum the granularity set forth in the national market system plan submitted pursuant to this section, which shall reflect current industry standards and be at least to the millisecond. To the extent that the relevant order handling and execution systems of any national securities exchange, national securities association, or member of such exchange or association utilize time stamps in increments finer than the minimum required by the national market system plan, the plan shall require such national securities exchange, national securities association, or member to utilize time stamps in such finer increments when providing data to the central repository, so that all reportable events reported to the central repository by any national securities exchange, national securities association, or member can be accurately sequenced. The national market system plan shall require the sponsors of the national market system plan to annually evaluate whether industry standards have evolved such that the required time stamp standard should be in finer increments.
-(e) Central Repository.
-(1) The national market system plan submitted pursuant to this section shall provide for the creation and maintenance of a central repository. Such central repository shall be responsible for the receipt, consolidation, and retention of all information reported pursuant to paragraph (c)(7) of this section. The central repository shall store and make available to regulators data in a uniform electronic format, and in a form in which all events pertaining to the same originating order are linked together in a manner that ensures timely and accurate retrieval of the information required by paragraph (c)(7) of this section for all reportable events for that order.
-(2) Each national securities exchange, national securities association, and the Commission shall have access to the central repository, including all systems operated by the central repository, and access to and use of the data reported to and consolidated by the central repository under paragraph (c) of this section, for the purpose of performing its respective regulatory and oversight responsibilities pursuant to the federal securities laws, rules, and regulations. The national market system plan submitted pursuant to this section shall provide that such access to and use of such data by each national securities exchange, national securities association, and the Commission for the purpose of performing its regulatory and oversight responsibilities pursuant to the federal securities laws, rules, and regulations shall not be limited.
-(3) The national market system plan submitted pursuant to this section shall include a provision requiring the creation and maintenance by the plan processor of a method of access to the consolidated data stored in the central repository that includes the ability to run searches and generate reports.
-(4) The national market system plan submitted pursuant to this section shall include policies and procedures, including standards, to be used by the plan processor to:
-(i) Ensure the security and confidentiality of all information reported to the central repository by requiring that:
-(A) All plan sponsors and their employees, as well as all employees of the central repository, agree to use appropriate safeguards to ensure the confidentiality of such data and agree not to use such data for any purpose other than surveillance and regulatory purposes, provided that nothing in this paragraph (A) shall be construed to prevent a plan sponsor from using the data that it reports to the central repository for regulatory, surveillance, commercial, or other purposes as otherwise permitted by applicable law, rule, or regulation;
-(B) Each plan sponsor adopt and enforce rules that:
-(1) Require information barriers between regulatory staff and non-regulatory staff with regard to access and use of data in the central repository; and
-(2) Permit only persons designated by plan sponsors to have access to the data in the central repository;
-(C) The plan processor:
-(1) Develop and maintain a comprehensive information security program for the central repository, with dedicated staff, that is subject to regular reviews by the Chief Compliance Officer;
-(2) Have a mechanism to confirm the identity of all persons permitted to access the data; and
-(3) Maintain a record of all instances where such persons access the data; and
-(D) The plan sponsors adopt penalties for non-compliance with any policies and procedures of the plan sponsors or central repository with respect to information security.
-(ii) Ensure the timeliness, accuracy, integrity, and completeness of the data provided to the central repository pursuant to paragraph (c) of this section; and
-(iii) Ensure the accuracy of the consolidation by the plan processor of the data provided to the central repository pursuant to paragraph (c) of this section.
-(5) The national market system plan submitted pursuant to this section shall address whether there will be an annual independent evaluation of the security of the central repository and:
-(i) If so, provide a description of the scope of such planned evaluation; and
-(ii) If not, provide a detailed explanation of the alternative measures for evaluating the security of the central repository that are planned instead.
-(6) The national market system plan submitted pursuant to this section shall:
-(i) Specify a maximum error rate to be tolerated by the central repository for any data reported pursuant to paragraphs (c)(3) and (c)(4) of this section; describe the basis for selecting such maximum error rate; explain how the plan sponsors will seek to reduce such maximum error rate over time; describe how the plan will seek to ensure compliance with such maximum error rate and, in the event of noncompliance, will promptly remedy the causes thereof;
-(ii) Require the central repository to measure the error rate each business day and promptly take appropriate remedial action, at a minimum, if the error rate exceeds the maximum error rate specified in the plan;
-(iii) Specify a process for identifying and correcting errors in the data reported to the central repository pursuant to paragraphs (c)(3) and (c)(4) of this section, including the process for notifying the national securities exchanges, national securities association, and members who reported erroneous data to the central repository of such errors, to help ensure that such errors are promptly corrected by the reporting entity, and for disciplining those who repeatedly report erroneous data; and
-(iv) Specify the time by which data that has been corrected will be made available to regulators.
-(7) The national market system plan submitted pursuant to this section shall require the central repository to collect and retain on a current and continuing basis and in a format compatible with the information consolidated and stored pursuant to paragraph (c)(7) of this section:
-(i) Information, including the size and quote condition, on the national best bid and national best offer for each NMS security;
-(ii) Transaction reports reported pursuant to an effective transaction reporting plan filed with the Commission pursuant to, and meeting the requirements of, § 242.601; and
-(iii) Last sale reports reported pursuant to the Plan for Reporting of Consolidated Options Last Sale Reports and Quotation Information filed with the Commission pursuant to, and meeting the requirements of, § 242.608.
-(8) The national market system plan submitted pursuant to this section shall require the central repository to retain the information collected pursuant to paragraphs (c)(7) and (e)(7) of this section in a convenient and usable standard electronic data format that is directly available and searchable electronically without any manual intervention for a period of not less than five years.
-(f) Surveillance. Every national securities exchange and national securities association subject to this section shall develop and implement a surveillance system, or enhance existing surveillance systems, reasonably designed to make use of the consolidated information contained in the consolidated audit trail.
-(g) Compliance by Members.
-(1) Each national securities exchange and national securities association shall file with the Commission pursuant to section 19(b)(2) of the Act> (15 U.S.C. 78s(b)(2)) and § 240.19b-4 of this chapter on or before 60 days from approval of the national market system plan a proposed rule change to require its members to comply with the requirements of this section and the national market system plan approved by the Commission.
-(2) Each member of a national securities exchange or national securities association shall comply with all the provisions of any approved national market system plan applicable to members.
-(3) The national market system plan submitted pursuant to this section shall include a provision requiring each national securities exchange and national securities association to agree to enforce compliance by its members with the provisions of any approved plan.
-(4) The national market system plan submitted pursuant to this section shall include a mechanism to ensure compliance with the requirements of any approved plan by the members of a national securities exchange or national securities association.
-(h) Compliance by National Securities Exchanges and National Securities Associations.
-(1) Each national securities exchange and national securities association shall comply with the provisions of the national market system plan approved by the Commission.
-(2) Any failure by a national securities exchange or national securities association to comply with the provisions of the national market system plan approved by the Commission shall be considered a violation of this section.
-(3) The national market system plan submitted pursuant to this section shall include a mechanism to ensure compliance by the sponsors of the plan with the requirements of any approved plan. Such enforcement mechanism may include penalties where appropriate.
-(i) Other Securities and Other Types of Transactions. The national market system plan submitted pursuant to this section shall include a provision requiring each national securities exchange and national securities association to jointly provide to the Commission within six months after effectiveness of the national market system plan a document outlining how such exchanges and associations could incorporate into the consolidated audit trail information with respect to equity securities that are not NMS securities, debt securities, primary market transactions in equity securities that are not NMS securities, and primary market transactions in debt securities, including details for each order and reportable event that may be required to be provided, which market participants may be required to provide the data, an implementation timeline, and a cost estimate.
-(j) Definitions.
-(1) The term CAT-Order-ID shall mean a unique order identifier or series of unique order identifiers that allows the central repository to efficiently and accurately link all reportable events for an order, and all orders that result from the aggregation or disaggregation of such order.
-(2) The term CAT-Reporter-ID shall mean, with respect to each national securities exchange, national securities association, and member of a national securities exchange or national securities association, a code that uniquely and consistently identifies such person for purposes of providing data to the central repository.
-(3) The term customer shall mean:
-(i) The account holder(s) of the account at a registered broker-dealer originating the order; and
-(ii) Any person from whom the broker-dealer is authorized to accept trading instructions for such account, if different from the account holder(s).
-(4) The term customer account information shall include, but not be limited to, account number, account type, customer type, date account opened, and large trader identifier (if applicable).
-(5) The term Customer-ID shall mean, with respect to a customer, a code that uniquely and consistently identifies such customer for purposes of providing data to the central repository.
-(6) The term error rate shall mean the percentage of reportable events collected by the central repository in which the data reported does not fully and accurately reflect the order event that occurred in the market.
-(7) The term material terms of the order shall include, but not be 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.
-(8) The term order shall include:
-(i) Any order received by a member of a national securities exchange or national securities association from any person;
-(ii) Any order originated by a member of a national securities exchange or national securities association; or
-(iii) Any bid or offer.
-(9) The term reportable event shall 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.
-By the Commission.
-Elizabeth M. Murphy
-Secretary
-Dated: July 18, 2012
-Exhibit A
-Key to Comment Letters Cited in Adopting Release Proposal to Implement Consolidated Audit Trail (File No. S7-11-10)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| fn |
- 1 EBSs are trading records requested by the Commission and SROs from broker-dealers that are used in regulatory investigations to identify buyers and sellers of specific securities. See Securities Exchange Act Release No. 44494 (June 29, 2001), 66 FR 35836 (July 9, 2001) (File No. S7-12-00) (adopting Rule 17a-25). See also Securities Exchange Act Release Nos. 26235 (November 1, 1988), 53 FR 44688 (November 4, 1988) (approving the Chicago Board Options Exchange's ("CBOE") rule for the electronic submission of transaction information); 26539 (February 13, 1989), 54 FR 7318 (February 17, 1989) (approving the National Association of Securities Dealers' (n/k/a FINRA) rule for the electronic submission of transaction information); and 27170 (August 23, 1989), 54 FR 37066 (September 6, 1989) (approving the Philadelphia Stock Exchange's (n/k/a NASDAQ OMX PHLX LLC) ("Phlx") rule for the electronic submission of transaction information). To partially address some of the current limitations of the EBS system, and to provide the Commission, in the short term, with more detailed and timely trade information for large traders, the Commission recently adopted new Rule 13h-1 concerning large trader reporting. See Securities Exchange Act Release No. 61908 (July 27, 2011), 76 FR 46960 (August 3, 2011) ("Large Trader Release"). Rule 13h-1 requires "large traders" to identify themselves to the Commission and make certain disclosures to the Commission on Form 13H. As adopted, Rule 13h-1 requires certain broker-dealers to capture and report through EBS the time of execution for any trade involving a large trader and a Commission-issued large trader identifier that identifies the large trader. See also Section II.A.3., infra. On April 20, 2012, the Commission, among other things, extended the time by which registered broker-dealers were required to comply with Rule 13h-1 to allow broker-dealers additional time to develop, test, and implement enhancements to their recordkeeping and reporting systems as required under Rule 13h-1. See Securities Exchange Act Release No. 66839, 77 FR 25007 (April 26, 2012) (Order Temporarily Exempting Broker-Dealers From the Recordkeeping, Reporting, and Monitoring Requirements of Rule 13h-1 Under the Securities Exchange Act of 1934 and Granting an Exemption for Certain Securities Transactions) ("Large Trader Extension"). - |
| fn |
- 2 The Commission uses the National Securities Clearing Corporation's ("NSCC") equity cleared report for initial regulatory inquiries. This report is generated on a daily basis by the SROs and is provided to the NSCC in a database accessible by the Commission, and shows the number of trades and daily volume of all equity securities in which transactions took place, sorted by clearing member. The information provided is end-of-day data and is searchable by security name and CUSIP number. - |
| fn |
- 3 See Large Trader Extension, supra note 1. - |
| fn |
- 4 See Securities Exchange Act Release No. 62174 (May 26, 2010), 75 FR 32556 (June 8, 2010) ("Proposing Release"). The comment file is on the Commission's website at: http://www.sec.gov/comments/s7-11-10/s71110.shtml. - |
| fn |
- 5 In this release, "consolidated audit trail" means both a system capable of capturing a complete record of all transactions relating to an order, from origination to execution or cancellation, and the complete record for an order generated by such a system, as the context may require. - |
| fn |
- 6 NMS plan is defined in Rule 600(b)(43) to mean "any joint self-regulatory organization plan in connection with: (i) [t]he planning, development, operation or regulation of a national market system (or a subsystem thereof) or one or more facilities thereof; or (ii) [t]he development and implementation of procedures and/or facilities designed to achieve compliance by self-regulatory organizations and their members with any section of [Regulation NMS] . . . ." 17 CFR 240.600(b)(43). Such NMS plan may be subject to modification prior to approval by the Commission pursuant to Rule 608 of Regulation NMS, as discussed in Section III.C.2.a.v., infra. - |
| fn |
- 7 "NMS security" is defined in Rule 600(a)(46) of Regulation NMS to mean "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." 17 CFR 242.600(a)(46). NMS stock is defined in Rule 600(47) to mean "any NMS security other than an option." 17 CFR 242.600(a)(46). A listed option is defined in Rule 600(a)(35) of Regulation NMS to mean "any option traded on a registered national securities exchange or automated facility of a national securities association." 17 CFR 242.600(a)(35). - |
| fn |
- 8 See Exhibit A for a citation key to the comment letters received by the Commission on the proposed rule. The Commission also received four comment letters that do not address the substance of the consolidated audit trail proposal. See Ericson Letter; Kondracki Letter; Grady Letter; Deep Liquidity Letter. - |
| fn |
- 9 The Commission notes that, in some cases, commenters fell into more than one such category. - |
| fn |
- 12 See Belanger Letters; SIFMA Drop Copy Letter; Wachtel Letter; High Speed Letter (recommending next steps in the development of the consolidated audit trail). - |
| fn |
- 13 See BondMart Letter; Leuchtkafter Letter. - |
| fn |
- 14 See Broadridge Letter; FIX Letter; Know More Letter; Aditat Letter; iSys Letter; Kaufman Letter; Berkeley Letter. - |
| fn |
- 19 As used herein, the term "order event data" is used to refer to the information reported pursuant to Rule 613(c)(3) and identified in Rule 613(c)(7)(i) through (v), generally including: (1) the Customer-ID(s) for each customer, including the person giving a modification or cancellation instruction; (2) the CAT-Order-ID; (3) the CAT-Reporter-ID of the broker-dealer, national securities exchange, or national securities association receiving, originating, routing, modifying, cancelling or executing an order, and to which an order is being routed; (4) the identity and nature of the department or desk to which an order is routed, if routed internally at the broker-dealer; (5) the date an order was received, originated, routed, modified, cancelled, or executed; (6) the time an order was received, originated, routed, modified, cancelled, or executed; (7) material terms of an order and any changes of such terms, if modified; (8) the price and remaining size of an order, if modified; (9) execution capacity (principal, agency, riskless principal); (10) execution price and size; and (11) whether the execution was reported pursuant to an effective transaction reporting plan or the Plan for Reporting of Consolidated Options Last Sale Reports and Quotation Information ("OPRA"). See Section III.B.1.d., infra. Information reported pursuant to Rule 613(c)(4) and identified in Rule 613(c)(7)(vi) through (viii) is referred to as "supplemental data." - |
| fn |
- 20 See Rule 613(c)(3); Sections II.A., III.B.1.e., infra. - |
| fn |
- 21 See Rule 613(c)(2); Sections III.B.1.f., III.B.2., infra. - |
| fn |
- 22 See Rule 613(j)(1); Section III.B.1.d.iv., infra. - |
| fn |
- 23 See Rule 613(a)(3)(vi); Section III.B.1.c., infra. - |
| fn |
- 24 See Rule 613(a)(1)(xii); Section III.C.2.a., infra. - |
| fn |
- 25 See Rule 613(a)(1)(ix); Section III.C.2.a., infra. - |
| fn |
- 26 See Rule 613(a)(1)(xi). - |
| fn |
- 27 See Rule 613(b)(7). For a further discussion of the composition of the Advisory Committee, see Section III.B.3.b., infra. - |
| fn |
- 28 See Section III.B.2., infra. - |
| fn |
- 29 See Rule 613(e)(4). - |
| fn |
- 30 See Rule 613(e)(6); Section III.B.2., infra. - |
| fn |
- 31 See Section II.A., infra, for a discussion of the objectives of the consolidated audit trail. - |
| fn |
- 32 See, e.g., FINRA Letter, p. 14 (advocating that SROs build off existing audit trails to develop a consolidated audit trail) and Nasdaq Letter I, p. 11-12 (arguing against building off existing audit trail systems and supporting the development of new system to establish a consolidated audit trail). - |
| fn |
- 33 See Nasdaq Letter I, p. 12; FIF Letter II, p. 2-3; STA Letter, p. 1-3; Direct Edge Letter, p. 2-3, 5. - |
| fn |
- 34 See Section III.C.2.b., infra. - |
| fn |
- 35 The methodology in the Proposing Release assumed that the scope of the required systems changes would be comparable to those made in connection with Regulation NMS. See Proposing Release, supra note 4, at 32597, n. 352. - |
| fn |
- 36 See, e.g, FINRA Letter, p. 14; SIFMA Letter, p. 16-18. - |
| fn |
- 37 See Rule 613(a)(1). - |
| fn |
- 38 See Rule 613(a)(5). - |
| fn |
- 39 The proposed Rule would have required SROs to submit such proposed rule changes on or before from 120 days from approval of the Rule. Because the adopted Rule permits the SROs up to 270 days from the date of publication of the Adopting Release in the Federal Register to submit NMS plans, the Commission believes that the more appropriate deadline for SROs to submit rule changes is 60 days from the date the Commission approves an NMS plan. - |
| fn |
- 40 Specifically, the adopted Rule provides SROs six months, instead of two months, after effectiveness of the NMS plan to submit this document to the Commission. - |
| fn |
- 41 See Proposing Release, supra note 4, at 32558-61. - |
| fn |
- 42 See FINRA/NYSE Euronext Letter, p. 1-3; Nasdaq Letter I, p. 1-5. - |
| fn |
- 43 See note 1, supra; Proposing Release, supra note 4, at 32557-58. - |
| fn |
- 44 See note 2, supra. - |
| fn |
- 45 The term "market reconstruction" is used to refer to the efforts by SRO and Commission staff to collect and process detailed trade and order data, often from multiple and varied data sources (e.g., market participants, trading venues, and other SROs) to recreate the sequence of events and market conditions that existed over a given period of time. A recent example of this occurred following the "Flash Crash" of May 6, 2010, with the market reconstruction analysis undertaken by Commission and the Commodity Futures Trading Commission ("CFTC") staff, which can be found in the "Findings Regarding the Market Events of May 6, 2010: Report of the Staffs of the CFTC and the SEC to the Joint Advisory Commission Emerging Regulatory Issues." See http://www.sec.gov/news/studies/2010/marketevents-report.pdf. - |
| fn |
- 46 The Commission recognizes that the accuracy of the data available may also be subject to occasional errors, including errors caused by rare and unexpected events. - |
| fn |
- 47 The effectiveness of such efforts with respect to cross-market activities within the Commission's jurisdiction depends on the qualities of data from multiple sources, such as separate SRO audit trails used for equities and equity options. See Section II.A.1.c., infra. This dependency also exists with respect to market activities that involve other products outside the Commission's jurisdiction, such as futures and certain swaps. See note 239, infra. - |
| fn |
- 48 17 CFR 240.17a-25. Rule 17a-25 codified the requirement that broker-dealers submit to the Commission, upon request, information on their customer and proprietary securities transactions in an electronic format. The rule requires submission of the same standard customer and proprietary transaction information that SROs request through the EBS system in connection with their market surveillance and enforcement inquiries. - |
| fn |
- 49 See Rule 17a-25; supra note 1, and accompanying text. - |
| fn |
- 50 See FIF Letter I, p. 3; SIFMA Letter, p. 18-19. - |
| fn |
- 51 As adopted, Rule 13h-1 requires certain broker-dealers to capture and report through EBS the time of execution for any trade involving a large trader and a Commission-issued large trader identifier that identifies the large trader. See Large Trader Release and Large Trader Extension, supra note 1. - |
| fn |
- 52 A 1990 Senate Report acknowledged the immense value of the EBS system, but noted that "it is designed for use in more narrowly focused enforcement investigations that generally relate to trading in individual securities. It is not designed for use for multiple inquiries that are essential for trading reconstruction purposes." See S. Rep. No. 300, 101st Cong., 2d Sess. 2-5 (1990), at 48. - |
| fn |
- 53 See, generally, Sections II.A.1. and II.A.2., infra. - |
| fn |
- 54 See note 2, supra, and accompanying text. - |
| fn |
- 55 The Commission also uses the Options Cleared Report, with data supplied by the Options Clearing Corporation ("OCC"), for analysis of trading in listed options. The OCC is an equity derivatives clearing organization that is registered as a clearing agency under Section 17A, 15 U.S.C. 78q-1, of the Exchange Act, and operates under the jurisdiction of both the Commission and the CFTC. - |
| fn |
- 56 A CUSIP number is a unique alphanumeric identifier assigned to a security and is used to facilitate the clearance and settlement of trades in the security. - |
| fn |
- 57 In 2007, NASD and the member-related functions of NYSE Regulation, Inc., the regulatory subsidiary of New York Stock Exchange LLC ("NYSE"), were consolidated. As part of this regulatory consolidation, the NASD changed its name to FINRA. See Securities Exchange Act Release No. 56146 (July 26, 2007), 72 FR 42190 (August 1, 2007). FINRA and the National Futures Association ("NFA") are currently the only national securities associations registered with the Commission; however, the NFA has a limited purpose registration with the Commission under Section 15A(k) of the Exchange Act, 15 U.S.C. 78o-3(k). See also Securities Exchange Act Release No. 44823 (September 20, 2001), 66 FR 49439 (September 27, 2001). - |
| fn |
- 58 See In the Matter of National Association of Securities Dealers, Inc., Order Instituting Public Proceedings Pursuant to Section 19(h)(1) of the Securities Exchange Act of 1934, Making Findings and Imposing Remedial Sanctions, Exchange Act Release No. 37538 (August 8, 1996), Administrative Proceeding File No. 3-9056 and Report Pursuant to Section 21(a) of the Securities Exchange Act of 1934 Regarding the NASD and The Nasdaq Stock Market LLC ("Nasdaq"). See also Securities Exchange Act Release No. 39729 (March 6, 1998), 63 FR 12559 (March 13, 1998) (order approving proposed rules comprising OATS) ("OATS Approval Order"). - |
| fn |
- 59 See Securities Exchange Act Release No. 47689 (April 17, 2003), 68 FR 20200 (April 24, 2003) (order approving proposed rule change by NYSE relating to order tracking) ("OTS Approval Order"). - |
| fn |
- 60 See In the Matter of Certain Activities of Options Exchanges, Administrative Proceeding File No. 3-10282, Securities Exchange Act Release No. 43268 (September 11, 2000) (Order Instituting Public Administrative Proceedings Pursuant to Section 19(h)(1) of the Securities Exchange Act of 1934, Making Findings and Imposing Remedial Sanctions) ("Options Settlement Order"). See, e.g., Securities Exchange Act Release No. 50996 (January 7, 2005), 70 FR 2436 (order approving proposed rule change by CBOE relating to Phase V of COATS). - |
| fn |
- 61 See Securities Exchange Act Release No. 63311 (November 12, 2010), 75 FR 70757 (November 18, 2010) (SR-FINRA-2010-044) (order approving proposed rule change by FINRA relating to the expansion of OATS to all NMS stocks). - |
| fn |
- 62 See Securities Exchange Act Release Nos. 65523 (October 7, 2011), 76 FR 64154 (October 17, 2011) (SR-NYSE-2011-49); 65524 (October 7, 2011), 76 FR 64151 (October 17, 2011) (SR-NYSEAmex-2011-74); 65544 (October 12, 2011), 76 FR 64406 (October 18, 2011) (SR-NYSEArca-2011-69). - |
| fn |
- 63 See FINRA Rule 7410(j) (defining "Order" for purposes of OATS, to mean "any oral, written, or electronic instruction to effect a transaction in an NMS stock or an OTC equity security that is received by a member from another person for handling or execution, or that is originated by a department of a member for execution by the same or another member, other than any such instruction to effect a proprietary transaction originated by a trading desk in the ordinary course of a member's market making activities." Additionally, Nasdaq, Nasdaq OMX BX, Inc. ("BX") and Phlx equities ("PSX") members that are registered as market makers in a certain security are similarly exempted from recording OATS audit trail data for the security in which they are registered to make a market. See Nasdaq and BX Rules 6951(i); PSX Rule 3401(i). The Commission notes that members of Nasdaq, BX and PSX, that are not also members of FINRA, are required by those exchanges to record the audit trail data required by OATS; however, they are only required to report that data through OATS upon request by their respective exchanges. See Nasdaq and BX Rules 6955(b); PSX Rule 3405(b). Additionally, as of October 17, 2011, members of NYSE and NYSE Amex, who are not also FINRA members, are required to record their trade and order activity. These non-FINRA members are not required to report this data through OATS unless requested. See NYSE and NYSE Amex Equities Rules 7450(b); see, e.g., Securities Exchange Act Release Nos. 65523 (October 7, 2011), 76 FR 64154 (October 17, 2011); 65524 (October 7, 2011), 76 FR 64151 (October 17, 2011); 65544 (October 12, 2011), 76 FR 64406 (October 18, 2011) (notice of immediate effective of proposed rule change to adopt the FINRA Rule 7400 series, the OATS rules, and making certain conforming changes to the NYSE and NYSE Amex Equities rules). Members of NYSE Arca, who are not also FINRA members, were required to record their trade and order activity as of March 31, 2012. See NYSE Arca Equities Rule 7450(b); see Securities Exchange Act Release No. 65544 (October 12, 2011), 76 FR 64406 (October 18, 2011) (notice of immediate effective of proposed rule change to adopt the FINRA Rule 7400 series, the OATS rules, and making certain conforming changes to the NYSE Arca Equities rules). See also Securities Exchange Act 66094 (January 4, 2012), 77 FR 1545 (January 10, 2012) (notice of immediate effectiveness to extend the implementation date of the NYSE Arca Equities Rule 7400 Series, the OATS rules, for Equity Trading Permit Holders that are not FINRA members from January 31, 2012 to March 31, 2012). - |
| fn |
- 64 FINRA has represented to Commission staff that, as part of its own surveillance activities, FINRA acquires some of this order handling system data from non-FINRA members to supplement the data it receives from its members via OATS, but that matching data across the audit trails yields varying levels of success and accuracy due to the disparate methods used by the different order handling systems to collect and store data. FINRA represented that, during the period from November 28, 2011 to February 24, 2012, approximately 2% of reportable OATS data related to exchange orders could not be linked with matching exchange data. See Commission Staff Memorandum to File No. S7-11-10 regarding telephone conversations with FINRA, dated April 17, 2012 ("Commission Staff Memorandum"). Also, since this process only involves acquiring trade and order data from select sources, it still does not produce a complete record of all market activity. The Commission notes that, when considering data covering a time period of approximately 26 months, the percentage of reportable OATS data related to exchange orders that could not be linked with matching exchange data remained at approximately 2%. Id. - |
| fn |
- 65 Common reasons given by FINRA for syntax rejections include: missing mandatory fields, invalid fields, and invalid field combinations (e.g., a Limit Price without a Time in Force Code). OATS will reject records as duplicates if more than one record is submitted with the same Order Receiving Firm Market Participant Identifier, Order Received Date, and Order Identifier or if more than one record contains all of the same information. http://www.finra.org/Industry/Compliance/MarketTransparency/OATS/FAQ/P085542 (last viewed on May 23, 2012). - |
| fn |
- 66 See Commission Staff Memorandum, supra note 64. FINRA estimates that, from the period November 28, 2011 to February 24, 2012 approximately 0.10% of the intra-firm data reported daily by broker-dealers were rejected for errors. Id. The Commission notes that, when considering data covering a time period of approximately 26 months, the percentage of the intra-firm data reported daily by broker-dealers rejected for errors was more than double this amount. Id. - |
| fn |
- 67 See FINRA Letter, p. 11. FINRA represented to Commission staff that many of the validation errors result from problems encountered in translating order information from broker-dealer formats into OATS format. See Commission Staff Memorandum, supra note 64. - |
| fn |
- 68 Id. - |
| fn |
- 69 Id. - |
| fn |
- 70 FINRA estimates that during the period from November 28, 2011 to February 24, 2012 approximately 0.5% of each day's reportable events remained unmatched (i.e., multi-firm events, such as routes, that cannot be reconciled). See Commission Staff Memorandum, supra note 64. When considering data covering a time period of approximately 26 months, the percentage of each day's reportable events remaining unmatched was more than double this amount. Id. - |
| fn |
- 71 For example, FINRA has been given access to order audit trail information from certain SROs pursuant to Regulatory Services Agreements. - |
| fn |
- 72 ISG is an international group of exchanges, market centers, and regulators that perform market surveillance in their respective jurisdictions. The organization provides a forum for its members to share information and coordinate regulatory efforts to address potential intermarket manipulation and trading abuses. - |
| fn |
- 73 See Section II.A.2.b., infra. - |
| fn | - - |
| fn |
- 75 Examples of schemes that typically rely on orders from accounts at multiple brokers include: (1) "network" insider trading schemes in which the participants cultivate multiple sources of non-public information and trade on the information they receive over an extended period of time and through accounts at a large number of broker-dealers; (2) wash trading; and (3) order layering. Unlike insider trading, for example, which is neither defined nor expressly prohibited in the Act, wash trading is specifically prohibited in the statute. The entering of matched orders for the purpose of creating the illusion of market activity or to artificially affect the price is one of the oldest and most difficult to detect manipulative practices. Technology that permits the routing of thousands of orders to different venues in micro seconds has made cross market surveillance for this activity extremely difficult. "Order layering" is similar to wash trading. In this practice, a market participant can enter numerous non-bona fide market moving orders, often in substantial size relative to a security's legitimate volume to create the false impression of buy or sell side pressure. When such orders induce others to execute against profitable limit orders, the market participants immediately cancel the pending orders that manipulated the price. As with wash sales, multiple traders can enter orders on different venues, impacting the NBBO and making the activity difficult to detect. - |
| fn |
- 76 For example, implementation of a consolidated audit trail also will help regulators monitor reliance on the use of the safe harbor provision for issuer repurchases in Rule 10b-18 under the Exchange Act. 17 CFR 240.10b-18. Rule 10b-18 under the Exchange Act provides issuers with a safe harbor from liability for manipulation under Sections 9(a)(2) and 10(b) of the Exchange Act, and Rule 10b-5 under the Exchange Act, when they repurchase their common stock in the market in accordance with the Rule's manner, timing, price, and volume conditions. The data required to be included in the consolidated audit trail will assist regulators in monitoring issuer repurchases that rely on Rule 10b-18's safe harbor protections to ensure that they comply with all required criteria. - |
| fn |
- 77 The Commission receives an average of over 200 market-related TCRs each month. - |
| fn |
- 78 See FINRA/NYSE Euronext Letter, p. 2. - |
| fn |
- 79 See Rule 613(f). - |
| fn |
- 80 See note 45, supra. - |
| fn |
- 81 See "Preliminary Findings Regarding the Market Events of May 6, 2010: Report of the Staffs of the CFTC and the SEC to the Joint Advisory Commission Emerging Regulatory Issues." (May 18, 2010). See http://www.sec.gov/sec-cftc-prelimreport.pdf. - |
| fn |
- 82 For detailed discussions and chronologies of the investigation into the events of May 6, 2010, see SEC (http://www.sec.gov/spotlight/sec-cftcjointcommittee.shtml) and CFTC (http://www.cftc.gov/PressRoom/Events/AdvisoryCommitteeMeetings/index.htm) webcasts and minutes of public meetings held with the Joint CFTC-SEC Advisory Committee on Emerging Regulatory Issues on May 24, 2010, June 22, 2010, August 11, 2010, November 5, 2010, and February 18, 2011. - |
| fn |
- 83 See note 45, supra, at p. 11. - |
| fn |
- 84 Id. - |
| fn |
- 85 Id. - |
| fn |
- 86 Id. at p. 18, 80. - |
| fn |
- 87 See Securities Exchange Act Release No. 61358 (January 14, 2010), 75 FR 3594 (January 21, 2010) ("Concept Release on Equity Market Structure"). - |
| fn |
- 88 See note 1, supra. - |
| fn |
- 89 See ICI Letter, p. 6-7; Liquidnet Letter, p. 4-5; SIFMA Letter, p. 18-19; CBOE Letter, p. 6 (questioning the need for a large trader reporting system if a consolidated audit trail is implemented). - |
| fn |
- 90 See FINRA/NYSE Euronext letter, p. 7. - |
| fn |
- 91 See SIFMA Letter, p. 18. - |
| fn |
- 92 See Liquidnet Letter, p. 5. - |
| fn |
- 93 Id. - |
| fn |
- 94 See Rule 613(j)(4). - |
| fn |
- 95 Though certain reporting requirements of Rule 13h-1 may eventually be unnecessary due to Rule 613, the Commission notes that Rule 13h-1 will be implemented much more expeditiously compared to the consolidated audit trail, and therefore will address the Commission's near-term need for access to more information about large traders and their activities. - |
| fn |
- 96 Section 3(a)(3)(A) of the Exchange Act defines the term "member" to mean: "(i) any natural person permitted to effect transactions on the floor of the exchange without the services of another person acting as broker; (ii) any registered broker or dealer with which such a natural person is associated; (iii) any registered broker or dealer permitted to designate as a representative such a natural person; and (iv) any other registered broker or dealer which agrees to be regulated by such exchange and with respect to which the exchange undertakes to enforce compliance with the provisions of the [Exchange Act], the rules and regulations thereunder, and its own rules." Section 3(a)(3)(A) further provides that, "[f]or purposes of Sections 6(b)(1), 6(b)(4), 6(b)(6), 6(b)(7), 6(d), 17(d), 19(d), 19(e), 19(g), 19(h), and 21 of [the Exchange Act], the term 'member' when used with respect to a national securities exchange also means, to the extent of the rules of the exchange specified by the Commission, any person required by the Commission to comply with such rules pursuant to Section 6(f) of this title." Finally, Section 3(a)(3)(B) provides that "[t]he term 'member' when used with respect to a registered securities association means any broker or dealer who agrees to be regulated by such association and with respect to whom the association undertakes to enforce compliance with the provisions of [the Exchange Act]." See 15 U.S.C. 78c(a)(3)(A) and 15 U.S.C. 78c(a)(3)(B). - |
| fn |
- 97 The proposed Rule would have explicitly required each national securities exchange and national securities association to be a sponsor of the NMS plan submitted pursuant to the Rule and approved by the Commission. See proposed Rule 613(a)(4). "Sponsor," when used with respect to an NMS plan, is defined in Rule 600(a)(70) of Regulation NMS to mean any self-regulatory organization which is a signatory to such plan and has agreed to act in accordance with the terms of the plan. See 17 CFR 242.600(a)(70). - |
| fn |
- 98 Proposed Rule 613(j)(1) would have defined the term "customer" to mean the beneficial owner(s) of the account originating the order and the person exercising investment discretion for the account originating the order, if different from the beneficial owner(s). - |
| fn |
- 99 The proposed Rule would have defined "material terms of the order" to include, but not be 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, or short exempt; if a short sale, the locate identifier, open/close indicator, time in force (if applicable), whether the order is solicited or unsolicited, and whether the account has a prior position in the security; 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. See proposed Rule 613(j)(3). - |
| fn |
- 100 "The OPRA Plan" is the Plan for Reporting of Consolidated Options Last Sale Reports and Quotation Information filed with the Commission pursuant to, and meeting the requirements of, Rule 608 of Regulation NMS. The OPRA Plan governs the dissemination of trade and quotation information for listed options. In this capacity, it provides real-time quotation and transaction information to market participants. See 17638 (March 18, 1981), 22 SEC Docket 484 (March 31, 1981) (order approving the OPRA Plan). - |
| fn |
- 101 The effective transaction reporting plans include the Consolidated Tape Association Plan ("CTA Plan") and the Joint Self-Regulatory Organization Plan Governing the Collection, Consolidation and Dissemination of Quotation and Transaction Information for Nasdaq-listed Securities Traded on Exchanges on an Unlisted Trading Privilege Basis ("UTP Plan"). - |
| fn |
- 102 See Proposing Release, supra note 4, at 32586 and 32594. - |
| fn |
- 103 Id. - |
| fn |
- 104 For comments on general costs of the proposed Rule, see, e.g., Thomson Reuters Letter, p. 2; Liquidnet Letter, p. 1; CBOE Letter, p. 2; Nasdaq Letter I, p. 2; Angel Letter, p. 1-2; IAG Letter, p. 3.; Kaufman Letter, attachment p. 3; Wells Fargo Letter, p. 4; Noetic Partners Letter, p. 2; Leuchtkafer Letter, p. 1-5; Broadridge Letter, p. 3; SIFMA Letter, p. 1-2, FINRA Letter, p. 3; FINRA Proposal Letter, p. 2.; High Speed Letter, p. 1; Belanger Letter, p. 7-8. - |
| fn |
- 105 See Section II.C., infra, for a discussion of specific concerns raised by commenters. - |
| fn |
- 106 See FINRA/NYSE Euronext Letter, p. 1. NYSE Euronext is the publicly traded parent of a number of subsidiaries, including three SROs, NYSE, NYSE Amex, and NYSE Arca. - |
| fn |
- 107 See Nasdaq Letter I, p. 2. The NASDAQ OMX Group, Inc. is the publicly traded parent of a number of subsidiaries, including three SROs, Nasdaq, Phlx, and BX. - |
| fn |
- 108 See Direct Edge Letter, p. 1. Direct Edge is the parent of two SROs, EDGA Exchange, Inc. and EDGX Exchange, Inc. - |
| fn |
- 109 See CBOE Letter, p. 2. - |
| fn |
- 111 Id. - |
| fn |
- 112 Id. - |
| fn |
- 113 See BATS Letter, p. 1. - |
| fn |
- 114 See Liquidnet Letter, p. 1. - |
| fn |
- 115 Id. at p. 1-2. - |
| fn |
- 116 See SIFMA Letter, p. 1-2. - |
| fn |
- 117 Id. at p. 2. - |
| fn |
- 119 See FIF Letter, p. 1. - |
| fn |
- 120 See Nasdaq Letter I, p. 2. - |
| fn |
- 121 See Thomson Reuters Letter, p. 2; Noetic Partners Letter, p. 2; FTEN Letter, p. 1; Ross Letter; Correlix Letter, p. 2.; FINRA Proposal Letter, p. 2.; High Speed Letter, p. 1; Belanger Letter, p. 7-8; Aditat Letter, p. 2 (stating that FIX protocol is already used in the industry today, making it cheaper to create systems to handle consolidated audit trail data as the data already exists in a "suitable format"). - |
| fn | - - |
| fn |
- 123 See FTEN Letter, p. 1. - |
| fn |
- 124 Id. at p. 3. - |
| fn |
- 125 See Know More Software Letter, p. 1. - |
| fn |
- 126 See Belanger Letter, p. 4. - |
| fn |
- 127 See Leuchtkafer Letter, p. 4. See also IAG Letter, p. 3. - |
| fn |
- 128 See, e.g., SIFMA Letter, p. 2, 15-16; FINRA/NYSE Euronext Letter, p. 7; FINRA Letter, p. 3; Angel Letter, p. 2; CBOE Letter, p. 2-6 (suggesting several ways that the costs of the proposal could be reduced, including: leveraging existing SRO experience with audit trail systems and imposing uniformity across markets in those systems; requiring the submission of audit trail information through a batch process after the close of the trading day; deleting the requirement that all market maker quotes be submitted to the proposed consolidated audit trail; making clear that broker-dealers have no obligation to report order information that has already been reported to an exchange; and revisiting the need for a large trader reporting system if that proposed rule is adopted.). - |
| fn |
- 130 See Section III.F.2., infra; see also, e.g., BATS Letter, p. 1-2; Broadridge Letter, p. 3; FIF Letter, p. 4-5; FINRA/NYSE Euronext Letter, p. 7; FINRA Letter, p. 3; ICI Letter, p. 4-5; Knight Letter, p. 2; Scottrade Letter, p. 1-2; SIFMA Letter, p. 3-6; SIFMA February 2012 Letter. Some commenters also questioned whether the costs to provide data on a real-time basis would outweigh the benefits. See Scottrade Letter, p. 1-2; FINRA/NYSE Euronext Letter, p. 4; GETCO Letter, p. 2; BATS Letter, p. 2; SIFMA Letter, p. 3-8; CBOE Letter, p. 4; FINRA Letter, p. 11-13; Wells Fargo Letter, p. 3; ICI Letter, p. 4-6; GETCO Letter, p. 2; Direct Edge Letter, p. 3; Leuchtkafer Letter; SIFMA Drop Copy Letter, p. 1; Ross Letter, p. 1; FINRA Proposal Letter, p. 3; SIFMA February 2012 Letter; FIA Letter, p. 2. - |
| fn |
- 131 See Scottrade Letter, p. 1-2; ICI Letter, p. 4-5; SIFMA Letter, p. 4; Knight Letter, p. 2. See also Broadridge Letter, p. 3; FIF Letter, p. 4; FIA Letter, p. 2. - |
| fn |
- 132 See SIFMA Letter, p. 4-6. - |
| fn |
- 133 Id. at p. 5. - |
| fn |
- 134 See SIFMA Letter, p. 3-4. - |
| fn |
- 135 See SIFMA Drop Copy Letter. - |
| fn |
- 136 Id. - |
| fn |
- 137 A "drop copy" is an electronic copy of a message automatically generated by the existing order management and execution systems used by broker-dealers and SROs. - |
| fn |
- 138 See SIFMA Drop Copy Letter. - |
| fn |
- 139 See GETCO Letter, p. 3-4. - |
| fn |
- 140 See Wells Fargo Letter, p. 3. - |
| fn |
- 141 See Correlix Letter, p. 2-3. - |
| fn |
- 142 Id. - |
| fn |
- 143 As discussed in Section II.C.4, infra, both SIFMA and FINRA submitted several comment letters with increasing levels of detail on the extent to which existing infrastructures could be used to achieve different forms of the various reporting requirements of the proposed Rule. In one of its later comment letters, FINRA submitted a detailed blueprint describing how it would build a consolidated audit trail that it believed would meet the primary objectives of the proposed Rule in a relatively short timeframe and with minimum costs to the industry. See FINRA Proposal Letter; SIFMA Letter, p. 16-18. See also BOX Letter, p. 2; BATS Letter, p. 2.; CBOE Letter, p. 2-3; Angel Letter, p. 2-3; Wells Fargo Letter, p. 2; Knight Letter, p. 3; FIF Letter, p. 5-6; Schumer Letter, p. 1; FIA Letter, p. 3. - |
| fn |
- 144 See, e.g., FINRA/NYSE Euronext Letter; FINRA Letter; Schumer Letter, p. 1. - |
| fn |
- 145 See Noetic Partners Letter II, p. 2; High Speed Letter, p. 1 (opining that estimated costs could be reduced if data were stored in an off-the-shelf cloud-based storage system or if a petabyte storage facility was built to store data and also estimating that "an integrated analysis system combining bespoke software for first-cut filtering of data from the repository, along with [commercial off-the-shelf software] for detailed analysis, could be developed for less than $10M"). See also Know More Software Letter, p. 1; Belanger Letter, p. 4; FTEN Letter, p. 1, 13. - |
| fn |
- 146 See Noetic Partners Letter II, p. 2. - |
| fn |
- 147 Id. - |
| fn |
- 148 See Section I., supra. - |
| fn |
- 149 See, generally, Section III., infra. - |
| fn |
- 150 See Section I., supra, for a summary of the changes to proposed Rule 613. - |
| fn |
- 151 See Rule 613(c)(3); Section I., supra; Section III.B.1.e., infra. - |
| fn |
- 152 See Rule 613(j)(1); Section I., supra; Section III.B.1.d.iv., infra. - |
| fn |
- 153 See Rule 613(a)(1)(i) through (xii); Section I., supra; Section III.C.2.a., infra. - |
| fn |
- 154 See FIF Letter II, p. 2-3; STA Letter, p. 2; Nasdaq Letter I, p. 6-7. - |
| fn |
- 155 See FIF Letter II, p. 1, 3; STA Letter, p. 1, 3. - |
| fn |
- 156 See FIF Letter II, p. 2; STA Letter, p. 1. - |
| fn |
- 157 See FIF Letter II, p. 1; STA Letter, p. 1-2. - |
| fn |
- 158 See FIF Letter, p. 1, 9; FIF Letter II, p. 1-2; STA Letter, p. 2; Direct Edge Letter, p. 2-3, 5. - |
| fn |
- 159 See FIF Letter, p. 1. - |
| fn |
- 160 See FIF Letter II, p. 2. - |
| fn |
- 161 See Direct Edge Letter, p. 2-3, 5. See also STA Letter, p. 1-3 (recommending the use of working groups comprising the Commission, FINRA, exchanges, broker-dealers, investors, vendors, and institutional asset managers to conduct business analysis and requisite discussions with the industry in planning a consolidated audit trail that meets the Commission's goals). - |
| fn |
- 162 Id. at p. 3. - |
| fn |
- 163 See Broadridge Letter, p. 2. - |
| fn |
- 164 See Broadridge Letter, p. 2; FIF Letter, p. 8. See also Ross Letter, p. 1 (discussing examples of information security details to consider); Nasdaq Letter I, p. 6 (stating that the proposed Rule provided "incomplete technical information on which design and features make the most sense"). - |
| fn |
- 165 See FIF Letter II, p. 1-2; STA Letter, p. 2. - |
| fn |
- 166 See FIF Letter II, p. 2; STA Letter, p. 2-3; see also Nasdaq Letter I, p. 7 (arguing for "scheduling flexibility at the initial stage" of designing the consolidated audit trail). - |
| fn |
- 167 See proposed Rule 613(a)(1). - |
| fn |
- 168 See FIF Letter II, p. 3. The commenter also provided the cost to the industry for the expansion of OATS to all NMS stocks - $48 million. The Commission notes that this is the cost for the project as a whole, not solely for the planning phase, and therefore is not entirely applicable to the cost of the creating and filing the NMS plan required by Rule 613. - |
| fn |
- 169 The time remaining was spent on "testing and other activities." See FIF Letter II, p. 3. - |
| fn |
- 170 See Section III.C.2.a., infra. - |
| fn |
- 171 See Section III.C.2.b., infra. - |
| fn |
- 172 17 CFR 242.608. - |
| fn |
- 173 17 CFR 242.608(b)(2). - |
| fn |
- 174 See FINRA Proposal Letter. - |
| fn |
- 175 See FINRA Proposal Letter, p. 4, 6 (arguing against requiring the name and address of the beneficial owner of an account, as well as of the individual making the investment decision, and against requiring tax identification or social security numbers for individual investors). - |
| fn |
- 176 Id. at p. 7 and Appendix B. - |
| fn |
- 177 Id. - |
| fn |
- 178 Id. at p. 3-4 (noting that this information would be available for query by regulators within one hour of receipt, would include a unique order identifier and MPID, and would be added on T+1 to the "order lifecycle" using OATS and TRF data). - |
| fn |
- 179 Id. at p. 4. - |
| fn |
- 180 See Angel Letter, p. 3 (also noting, "While the OATS data are extremely useful for understanding market behavior and for searching for various violations, these data are not really needed for real time surveillance. Real time surveillance is generally focused on the question of whether or not some change needs to take place immediately . . . . The extensive OATS data regarding the handling of individual orders are more useful for economic analysis and enforcement activities and do not need to be reported in real time.") - |
| fn |
- 181 Id. - |
| fn |
- 183 See FINRA/NYSE Euronext Letter, p. 7. See also FINRA Letter, p. 3 (stating that "the necessary components to an effective, comprehensive, and efficient consolidated audit trail are: (1) uniform data (both data content and data format); (2) reliable data; and (3) timely access to the data by SROs and the SEC. FINRA believes this can be achieved most effectively, efficiently, and expeditiously by expanding FINRA's existing OATS requirements to additional securities and non-FINRA member broker-dealers and by consolidating exchange data in a central repository to be used with OATS data"). - |
| fn |
- 184 See BATS Letter, p. 2. - |
| fn | - - |
| fn |
- 186 Id. - |
| fn |
- 187 See FINRA Letter, p. 6. Specifically, FINRA proposed enhancements to OATS and outlined a phased approach for implementation. It explained that, under its approach, implementation would begin with equity securities in the first two phases, followed by options in the third and fourth phases. FINRA further proposed that it could "establish an intraday abbreviated order submission capability based on SIFMA's drop-copy proposal." FINRA estimated the initial cost for the first two phases of the OATS enhancement would be between $100 to $125 million and the ongoing annual costs to be between $30 million and $40 million. While FINRA's proposal appears to include many of the elements required by Rule 613, the Commission notes that the proposal does not include a Customer-ID (which was similarly lacking in the SIFMA proposal), nor would all broker-dealers be required to report order information to the central repository (certain firms that route orders exclusively to another reporting firm that is solely responsible for further routing decisions would be exempt from reporting obligations; additionally, FINRA proposed retaining exemptive authority in certain limited situations to provide relief to small member firms that do not otherwise qualify for exclusion from the definition of an OATS Reporting Member). Further, FINRA's proposal would not collect customers' names, addresses and account numbers. See FINRA Proposal Letter, p. 10; 14-16; Appendix. The Commission believes a unique Customer-ID and customer account information are critical to the efficacy and usefulness of the consolidated audit trail, and therefore is requiring the NMS plan submitted for its consideration to include such information. - |
| fn |
- 188 Id. This commenter also noted that OATS compliance rates have improved to over 99% since the system was first implemented, and emphasized that creating a new system would result initially in low compliance rates until users became familiar with the system. Id. at p. 11; see also FINRA/NYSE Euronext Letter, p. 8. - |
| fn |
- 189 See FIF Letter, p. 6 (also providing thoughts on the functionalities of OATS that should be considered in creating the consolidated audit trail, such as OATS' ability to identify and reject duplicative reporting; to link reports between firms and Nasdaq exchanges without using a unique customer identifier; its possible flexibility in incorporating additional order types; its current incorporation of quote data; and its current identification of index arbitrage and program trading, and ability to possibly add a large trader identification field "to enhance analysis of high volume, algorithm trading"). - |
| fn |
- 190 See BOX Letter, p. 2; CBOE Letter, p. 2. - |
| fn |
- 191 See BOX Letter, p. 2. - |
| fn |
- 192 See CBOE Letter, p. 2. - |
| fn |
- 193 See SIFMA Drop Copy Letter. The FIX Protocol is a series of messaging specifications for the electronic communication of trade-related messages. It has been developed through the collaboration of banks, broker-dealers, exchanges, industry utilities and associations, institutional investors, and information technology providers from around the world. These market participants share a vision of a common, global language for the automated trading of financial instruments. See http://fixprotocol.org/what-is-fix.shtml (last viewed on May 30, 2012). - |
| fn |
- 194 Id. at p. 1. - |
| fn |
- 195 Id. at p. 1-2. - |
| fn |
- 196 See Section II.A.1.c., supra. - |
| fn |
- 197 This Section III.A. discusses the use of a NMS plan to create, implement, and maintain a consolidated audit trail. Section III.C., infra, focuses on the process the SROs must follow when submitting the NMS plan to the Commission. - |
| fn |
- 198 17 CFR 242.608. See Rule 613(a)(2). - |
| fn |
- 199 See Proposing Release, supra note 4, at 32568. - |
| fn | - - |
| fn |
- 201 See Thomson Reuters Letter, p. 2. - |
| fn |
- 202 See CBOE Letter, p. 7. - |
| fn |
- 203 See FINRA Letter, p. 15; Angel Letter, p. 3. - |
| fn |
- 204 See FINRA Letter, p. 15. - |
| fn |
- 205 See Angel Letter, p. 3. - |
| fn |
- 206 See Rule 613(a). The proposed Rule provided that the NMS plan must be filed with the Commission pursuant to Rule 608. Adopted Rule 613(a)(2) clarifies that the NMS plan must also satisfy the requirements set forth in Rule 608(a). See Rule 608(a) of Regulation NMS; 17 CFR 242.608(a). - |
| fn |
- 207 See Section III.C., infra. - |
| fn |
- 208 17 CFR 242.608. See Rule 613(a)(2). - |
| fn |
- 209 See Thomson Reuters Letter, p. 2. - |
| fn |
- 210 See Section I., supra; Sections III.B., III.C., infra. - |
| fn |
- 211 See Section III.B.1.d.i.(A)., infra. - |
| fn |
- 212 See FINRA Letter, p. 15. - |
| fn |
- 213 See CBOE Letter, p. 7. - |
| fn |
- 214 See Rule 613(a)(1)(xi). - |
| fn |
- 215 See Rule 613(b)(7)(i). Because members of the SROs will be required to report data pursuant to the NMS plan, the Rule provides that the plan must require that the Advisory Committee include representatives of the member firms of the SROs. However, the Commission believes that it is advisable for the SROs to consider including other interested parties such as SIPs, vendors, investors, and/or academics on the Advisory Committee. In addition, the Commission expects that the Advisory Committee would include the Commission's Chief Technology Officer as an observer. See Section III.B.3.b., infra. - |
| fn |
- 216 See Rule 613(b)(7). - |
| fn |
- 217 17 CFR 242.608(b)(1). - |
| fn |
- 218 See Angel Letter, p. 3. - |
| fn |
- 219 See Section II.A., supra. The Commission notes that, in the Proposing Release, it used the term "proprietary orders" to describe orders that were generated for the account of a broker-dealer. See Proposing Release, supra note 4, at 32570. To avoid confusion with the proposed "Volcker Rule," which proposes new regulations with respect to "proprietary" trading by commercial banks and their affiliates, the Commission is using the term "principal orders" in this Release to describe orders that were generated for the account of a broker-dealer. See Securities Exchange Act Release No. 65545 (October 12, 2011), 76 FR 68846 (November 7, 2011) (File No. S7-41-11). - |
| fn |
- 220 See Section I., supra. - |
| fn |
- 221 See proposed Rule 613(c)(5). - |
| fn |
- 222 The Commission notes that any expansion of the consolidated audit trail to cover non-NMS securities would be effectuated through notice and comment. - |
| fn |
- 223 See Liquidnet Letter, p. 2 (suggesting limiting the scope of the first phase of audit trail implementation to end-of-day-reporting to ensure that it can be completed in a timely and cost-effective manner; this commenter also recommended that the first phase apply the consolidated audit trail to all market participants, not just the SROs, as proposed). See also FIF Letter, p. 7 (suggesting that the consolidated audit trail cover just NMS stocks - then at a later date, all NMS securities, including options); FINRA Proposal Letter, p. 5 (suggesting several phases of expansion, beginning with NMS stocks and over-the-counter ("OTC") equity securities, and ultimately including standardized options, fixed income securities, conventional options, and security-based derivatives in the consolidated audit trail); SIFMA Letter, p. 16-17 (believing that OATS could form the basis for the consolidated audit trail, stating that OATS should be modified to include non-Nasdaq-listed securities, listed options, quotes, street side and exchange-to-exchange routing and market making and recommending phasing in NMS stocks first, then any additional data elements, then listed options and, finally, non-NMS securities); FIF Letter II, p. 2 (suggesting that the consolidated audit trail have "multi-instrument capabilities, most importantly options and futures but also fixed income and other instruments). - |
| fn |
- 224 See Broadridge Letter, p. 4. - |
| fn |
- 225 See Nasdaq Letter II, p. 3. - |
| fn |
- 226 See Liquidnet Letter, p. 2; FINRA Proposal Letter, p. 5; SIFMA Letter, p. 16-17; Marketcore Letter, p. 1. - |
| fn |
- 227 See Marketcore Letter, p. 1. - |
| fn |
- 228 See Ameritrade Letter, p. 3. See also Mansfield Letter, p. 1 (suggesting other data, including "metrics" and "market environmental information" to be included in the consolidated audit trail). - |
| fn |
- 229 See Direct Edge Letter, p. 4. - |
| fn |
- 230 See Proposing Release, supra note 4, at 32568-70; Rule 613(c)(5). - |
| fn |
- 231 See Rule 613(i). Specifically, Rule 613(i) now provides that the SROs provide a document outlining how such exchanges and associations "could" incorporate non-NMS securities into the consolidated audit trail, rather than how the exchanges and associations "would propose to" incorporate non-NMS securities; and that the exchanges and associations should provide details for each order and reportable event that "may" be required to be provided, and which market participants "may" be required to provide the data. As proposed, the comparable provision of Rule 613(i) required that the exchanges and associations should provide details for each order and reportable event that "would" be required to be provided, and which market participants "would" be required to provide the data. - |
| fn |
- 232 See Section III.B.3.b., infra. - |
| fn |
- 233 See Ameritrade Letter, p. 3; Liquidnet Letter, p. 2; Marketcore Letter, p. 1; FINRA Proposal Letter, p. 5; SIFMA Letter, p. 16-17. - |
| fn |
- 234 See Rule 613(a)(1)(vi). See also Section III.C.2.a.i., infra. - |
| fn |
- 235 See note 222, supra. - |
| fn |
- 236 See Rule 613(a)(3), which states that the NMS plan must require the plan sponsors: (i) within two months after effectiveness of the NMS plan to select a plan processor; (ii) within four months after effectiveness of the NMS plan to synchronize their business clocks and require the members of each such exchange and association to synchronize their business clocks; (iii) within one year after effectiveness of the NMS plan to provide to the central repository the data specified in Rule 613(c); (iv) within fourteen months after effectiveness of the NMS plan to implement a new or enhanced surveillance system(s) as required by Rule 613(f); (v) within two years after effectiveness of the NMS plan to require their members, except those members that qualify as small broker-dealers as defined in § 240.0–10(c), to provide to the central repository the data specified in Rule 613(c); and (vi) within three years after effectiveness of the NMS plan to require their members that qualify as small broker-dealers as defined in § 240.0–0(c) to provide to the central repository the data specified in Rule 613(c). - |
| fn |
- 237 See Section III.D., infra. - |
| fn |
- 238 The Commission also believes that limiting the application of the Rule initially to only NMS securities should help ensure that the implementation schedule prescribed by the Rule is achievable. See Section III.D., infra. - |
| fn |
- 239 See Section II.A.2, supra. - |
| fn |
- 240 See note 223, supra. - |
| fn |
- 241 The Commission notes that the financial markets have become increasingly interrelated, with transactions occurring in the futures markets affecting transactions in the securities markets. To the extent that instruments other than NMS securities (e.g., futures on a securities index or security-based swaps) can be substitutes for trading in NMS securities, or are otherwise linked to such trading (e.g., as part of a strategy that involves multiple products), having access to an audit trail that includes these instruments would improve regulators' ability to more quickly detect potentially manipulative or other illegal activity that could occur across markets. The Commission recognizes, however, that any such expansion to include products not under the Commission's jurisdiction, and thus not contemplated by this Rule, would need to be coordinated with the CFTC or other applicable regulatory authorities, and would likely require a separate rulemaking, which would include a consideration of the costs and benefits of such an expansion. In this regard, the Commission believes that it could be beneficial to discuss with the CFTC, at the appropriate time, the possibility of including within the consolidated audit trail data relating to futures or swap products regulated by the CFTC that are based on securities. The Commission is therefore directing the Commission staff to work with the SROs, the CFTC staff, and other regulators and market participants to determine how other asset classes, such as futures, might be added to the consolidated audit trail. The information from such an expanded consolidated audit trail could benefit both the CFTC and the Commission. An example of a non-NMS security is a security-based swap. The Commission notes that, separately, it has proposed rules requiring the reporting of security-based swap information to registered security-based swap data repositories ("SDR") or the Commission. See Securities Exchange Act Release No. 63446, File No. S7-34-10 (November 19, 2010), 75 FR 75208 (December 2, 2010) (proposing Regulation SBSR under the Exchange Act providing for the reporting of security-based swap information to registered security-based SDR or the Commission, and the public dissemination of security-based swap transaction, volume, and pricing information); see also Securities Exchange Act Release No. 63447, File No. S7-35-10 (November 19, 2010), 75 FR 77306 (December 10, 2010) (proposing rules governing the SDR registration process, duties, and core principles). - |
| fn |
- 242 See 17 CFR 242.100 et seq.; 17 CFR 240.10b-5. Rule 105 of Regulation M prohibits the short selling of equity securities that are the subject of a public offering for cash and the subsequent purchase of the offered securities from an underwriter or broker or dealer participating in the offering if the short sale was effected during a period that is the shorter of the following: (i) beginning five business days before the pricing of the offered securities and ending with such pricing; or (ii) beginning with the initial filing of such registration statement or notification on Form 1-A or Form 1-E and ending with the pricing. Thus, Rule 105 prohibits any person from selling short an equity security immediately prior to an offering and purchasing the security by participating in the offering. Rule 10b-5 provides that "[i]t shall be unlawful for any person, directly or indirectly, by the use of any means or instrumentality of interstate commerce, or of the mails or of any facility of any national securities exchange, (a) [t]o employ any device, scheme, or artifice to defraud, (b) [t]o make any untrue statement of a material fact or to omit to state a material fact necessary in order to make the statements made, in the light of the circumstances under which they were made, not misleading, or (c) [t]o engage in any act, practice, or course of business which operates or would operate as a fraud or deceit upon any person, in connection with the purchase or sale of any security." - |
| fn |
- 243 See Direct Edge Letter, p. 4. - |
| fn |
- 244 See Rule 613(i). - |
| fn |
- 245 See Section III.B.3.b., infra. - |
| fn |
- 246 See note 2145, supra. - |
| fn |
- 247 See Proposing Release, supra note 4, at 32570; proposed Rule 613(j)(4). - |
| fn |
- 248 Id. - |
| fn |
- 249 See note 219, supra. - |
| fn |
- 250 See Proposing Release, supra note 4, at 32571. - |
| fn |
- 251 See FINRA Letter, p. 10; SIFMA Letter, p. 15; Liquidnet Letter, p. 3; FINRA Proposal Letter, p. 6. - |
| fn |
- 252 See SIFMA Letter, p. 13; CBOE Letter, p. 5. - |
| fn |
- 253 See SIFMA Letter, p. 13; CBOE Letter, p. 5. - |
| fn |
- 254 See CBOE Letter, p. 5. See also Options Settlement Order, supra, note 60. See, e.g., Securities Exchange Act Release No. 50996 (January 7, 2005), 70 FR 2436 (order approving proposed rule change by CBOE relating to Phase V of COATS). - |
| fn |
- 255 See Liquidnet Letter, p. 3. - |
| fn |
- 256 See Ameritrade Letter, p. 3. - |
| fn |
- 257 See SIFMA Letter, p. 15. - |
| fn |
- 258 See BOX Letter, p. 3. - |
| fn |
- 259 Such costs might include the costs to purchase or build new systems and/or costs to modify existing systems to record and report the required data. As discussed in Section I., supra, the NMS plan would include detailed information about costs for the public and the Commission to consider. - |
| fn |
- 260 See Rule 613(j)(4). - |
| fn |
- 261 See, e.g., FINRA Rule 5320; NYSE Arca Equities Rule 6.16. - |
| fn |
- 262 See Section II.A., supra. - |
| fn |
- 263 See BOX Letter, p. 3. - |
| fn |
- 264 See SIFMA Letter, p. 15. - |
| fn |
- 265 See Rule 613(c)(7)(ii)(F). The Commission notes that the NMS plan submitted by the plan sponsors would need to provide appropriate detail as to how orders routed within a single broker-dealer would be reported. For example, the NMS plan would need to address the routing of an order received by a customer-facing sales desk within a broker-dealer to a separate trading or market-making desk within the same broker-dealer that actually determines how to execute the order. - |
| fn |
- 266 See Ameritrade Letter, p. 3. - |
| fn |
- 267 See CBOE Letter, p. 5; TIAA-CREF Letter, p. 2; Wachtel Letter, p. 1; SIFMA Letter p. 13; FINRA Proposal Letter, p. 5-6; GETCO Letter, p. 3-4; Nasdaq Letter II, p. 3. - |
| fn |
- 268 See TIAA-CREF letter, p. 2-3. Another commenter echoed this concern and recommended that the consolidated audit trail develop a means to avoid such duplicative reporting, explaining that this is a problem with the current OATS system. See Wells Fargo Letter, p. 2. - |
| fn |
- 269 See TIAA-CREF letter, p. 2. - |
| fn |
- 270 See FINRA Proposal Letter, p. 5-6. - |
| fn |
- 271 Id. - |
| fn |
- 272 See Wachtel Letter, p. 1. The Commission notes any exemptions granted by FINRA under FINRA Rule 7470 may not exceed a period of two years, unless extended. See FINRA Rule 7470. FINRA's authority to grant exemptions under FINRA Rule 7470 expires on July 10, 2015. See FINRA Rule 7470(c). - |
| fn |
- 273 See CBOE Letter, p. 5-6; SIFMA Letter, p. 13; GETCO Letter, p. 3-4. - |
| fn |
- 274 See CBOE Letter, p. 5-6 (stating its belief that "it would be redundant for both the market makers and the exchanges to all submit this information to the CAT. We recommend that the exchanges be permitted to submit information on market maker quotes to the CAT. Market makers who submit quotes to an exchange would have no obligation other than to correctly identify themselves to the exchange as the party submitting the quotation. The exchange could add the rest of the required information (participant identifier, unique order identifier, etc.) to the quote and transmit it to the CAT"). - |
| fn |
- 275 See SIFMA Letter, p. 13. - |
| fn |
- 276 See GETCO Letter, p. 3-4. Another commenter proposed to develop a platform that would collect audit trail information from the SROs and other sources of information, and thus reduce the obligations on broker-dealers to report data. See Nasdaq Letter II, p. 3. - |
| fn |
- 277 See Rules 613(c)(5) through (7). - |
| fn |
- 278 The Commission notes that the Rule does not preclude the NMS plan from allowing broker-dealers to use a third party to report the data required to the central repository on their behalf. In particular, the Commission recognizes that introducing brokers may wish to contract with clearing broker-dealers for this purpose and that the SROs may need to amend their rules to address the allocation of responsibility between the parties. In such cases, the Commission expects that the clearing contract, as mandated by the SRO's rules, as amended, would address the allocation of responsibility for the reporting of required data. - |
| fn |
- 279 The Commission has adopted Rule 613(c)(5) and (6) using the terms "record" and "report" the required audit trail data, rather than "collect" and "provide" the required audit trail data, as proposed. See also Section III.B.1.e., infra. - |
| fn |
- 280 The Rule as adopted requires the NMS plan submitted to the Commission for its consideration to require broker-dealers and SROs to record and report to a central repository only the audit trail information for actions each took with respect to an order. For example, if a member receives an order from a customer, the member will be required to report its receipt of that order (with the required information) to the central repository. If the member then routes the order to an exchange for execution, the member will be required to report the routing of that order (with the required information) to the central repository. Likewise, the exchange receiving the routed order will be required to report the receipt of that order from the member (with the required information) to the central repository. If the exchange executes the order on its trading system, the exchange will be required to report that execution of the order (with the required information) to the central repository, but the member will not also be required to report the execution of the order. If the member executes the order in the OTC market, however, rather than routing the order to an exchange (or other market center) for execution, the member will be required to report the execution of the order (with the required information) to the central repository. In this regard, there is no duplicative reporting of audit trail information because each market participant is required to report only the audit trail data for the actions it has taken with respect to an order. The Commission notes that, for orders that are modified or cancelled, Rule 613(c)(7)(iv) would require the broker-dealer who received the modification from a customer, for example, to report the order modification to the central repository. Thus, if broker-dealer A received a modification to a customer's order from the customer, broker-dealer A would be required to report such modification to the central repository. If broker-dealer A had already routed the customer's order to another broker-dealer ("broker-dealer B"), the customer's modification would also need to be reported by broker-dealer A to broker-dealer B. The receipt of the customer's modification by broker-dealer B would also need to be reported to the central repository, pursuant to Rule 613(c)(7)(iv). The same reporting obligations would apply if the modification were originated by broker-dealer A. - |
| fn |
- 281 Such costs might include the costs to purchase or build new systems and/or costs to modify existing systems to record and report the required data. As discussed in Section I., supra, the NMS plan would include detailed information about costs for the public and the Commission to consider. - |
| fn |
- 282 See Section III.C.2.iii., infra. - |
| fn |
- 283 See Wachtel Letter, p. 1. - |
| fn |
- 284 See Section III.D., infra. - |
| fn |
- 285 If a clearing broker-dealer receives an order from a small broker-dealer during the period between the time the Rule is applicable to large broker-dealers and the time the Rule is applicable to small broker-dealers, the broker-dealer performing the clearing function for the small introducing broker will be subject to only the requirements of the Plan applicable directly to the clearing broker-dealer, while the small introducing broker will not be subject to the reporting requirements at that time. - |
| fn |
- 286 In particular, the Commission acknowledges that certain elements are not collected by existing audit trails and thus SROs and members would incur additional costs to record and report such information. The Commission also acknowledges that there might be additional costs with respect to assigning customer identifiers, the broker-dealer identifiers and the order identifiers because such assignments might, depending on the NMS plan, require coordination amongst various different entities and possibly further systems changes. - |
| fn |
- 287 See proposed Rules 613(c)(7)(i)(I), 613(c)(7)(ii)(G), 613(c)(7)(iii)(F) and 613(c)(7)(iv)(D). - |
| fn |
- 288 A broker or dealer currently must mark all sell orders of any equity security as long, short, or short exempt. See Rule 200(g)(1) under the Exchange Act, 17 CFR 242.200(g)(1). A sell order may be marked short exempt only if the conditions of Rule 201(c) or (d) under the Exchange Act are met (17 CFR 242.201(c) and (d)). See Rule 200(g)(2) under the Exchange Act, 17 CFR 242.200(g)(2). - |
| fn |
- 289 See Kumaraguru Letter, p. 1. - |
| fn |
- 290 Id. - |
| fn |
- 291 See Ameritrade Letter, p. 3. - |
| fn |
- 292 Id. - |
| fn |
- 293 See FINRA Proposal Letter, Appendix A. - |
| fn |
- 294 See Section II.A.2., supra. - |
| fn |
- 295 See Kumaraguru Letter, p. 1. - |
| fn |
- 296 See Rule 613(j)(3); see also Section III.B.1.d.iii.(C).(2)., infra (discussing the definition of "customer" as applied to investment advisers). - |
| fn |
- 297 See Section III.B.1.d.ii., infra, for a discussion of the proposed requirement to report the unique identifier of the registered representative receiving or originating an order. - |
| fn |
- 298 See Proposing Release, supra note 4, at 32575. - |
| fn |
- 299 See Angel Letter, p. 2-3. - |
| fn |
- 300 Order type information is important because it reflects the intention of the person originating an order with regard to how an order should be handled, and also provides information regarding the potential impact of orders on the market. - |
| fn |
- 301 See Proposing Release, supra note 4, at 32575. - |
| fn |
- 302 See proposed Rule 613(j)(3). - |
| fn |
- 303 See Angel Letter, p. 2-3. - |
| fn |
- 304 Id. - |
| fn |
- 305 See Managed Funds Association Letter, p. 2; SIFMA Letter, p. 11; SIFMA Drop Copy Letter, p. 2. - |
| fn | - - |
| fn |
- 307 See SIFMA Letter, p. 11. SIFMA subsequently submitted an alternative proposal that did not include a flag for algorithms, citing lack of clarity in the Commission's definition of algorithmic order, and stating that the FIX standard lacks existing fields to flag such orders. Id. at 2. - |
| fn |
- 308 See Angel Letter, p. 2-3. - |
| fn |
- 309 See Rule 613(j)(7). - |
| fn |
- 310 See Proposed Rule 613(c)(7)(i)(F). - |
| fn |
- 311 See SIFMA Letter, p. 12; Liquidnet Letter, p. 6; FINRA Letter, p. 4; FINRA Proposal Letter, p. 6. - |
| fn |
- 312 See FINRA Letter, p. 4 (explaining that "multiple firms can currently be represented by a single MPID that is used for market access arrangements and is assigned to another firm that has no direct relationship to the trading activity being reported under that MPID"). This commenter also supported the use of more specific "sub-identifiers" to allow regulators to distinguish between desks or trading units within a firm. - |
| fn |
- 313 Id. at p. 9. FINRA also requested that the Commission reconsider the need for reporting the identification of the beneficial owner, the identification of the person exercising investment discretion, and the unique identifier of the branch office and registered representative. For further discussion of this comment, see note 170 supra and accompanying text. - |
| fn |
- 314 See FINRA Proposal Letter, p. 6, 13. The CRD is the central licensing and registration system operated by FINRA which contains employment, qualification and disciplinary histories for securities industry professionals who do business with the public. - |
| fn |
- 315 See FINRA Proposal Letter, p. 6, 13. - |
| fn |
- 316 Id. at p. 6. - |
| fn |
- 317 See Angel Letter, p. 2. - |
| fn |
- 318 This standard is being developed by Technical Committee 68 (TC68) of ISO, in whose meetings a Commission staff representative participates. Its final publication is subject to the resolution of specific issues on implementation, operating procedures, and the need to coordinate with a global legal entity identifier initiative conducted by the global regulatory community, in which a Commission staff representative is also participating. - |
| fn |
- 319 One commenter requested the Commission consider how the Department of Treasury's newly-created Office of Financial Research ("OFR") would impact reporting requirements imposed by the consolidated audit trail. See SIFMA Letter, p. 22-23. The commenter noted that the collection powers granted to the OFR, as well as its authority to require standardized reporting of data, could affect how data is submitted to the consolidated audit trail. Id. at p. 22. The commenter suggested that any information that is provided to the consolidated audit trail should not be required to be provided to the OFR again or in a different format. Id. The Commission understands that the OFR has been participating in and encouraging efforts by interested parties to have a standard for assigning unique entity identifiers created by an internationally recognized standards body ("IRSB") and that the ISO has issued a draft ISO standard, ISO 17442, for the financial services industry that is proposed to provide a viable global solution for the accurate and unambiguous identification of legal entities engaged in financial transactions. See ISO Press Release "ISO Financial Services Standard Wins Industry Support Six Months Ahead of Publication," July 25, 2011. Because the ISO standard is still in draft form and issues of implementation, governance and operating procedures remain to be resolved, the Commission does not believe that it is appropriate for it to mandate the use of the ISO standard at this time. The Commission notes, however, that to the extent that unique entity identifiers become available from an IRSB, Rule 613 provides SROs with sufficient flexibility to submit, if they so chose, an NMS plan that makes use of those identifiers and requires all or some reporting parties to obtain such identifiers, assuming such identifiers otherwise meet the requirements of the Rule. - |
| fn |
- 320 See proposed Rule 613(c)(7)(iv)(E) (requiring the reporting of the identity of the person giving a modification or cancellation instruction for an order); adopted Rule 613(c)(7)(iv)(F) (requiring the CAT-Reporter-ID or Customer-ID of such person instead). - |
| fn |
- 321 See note 313, supra. - |
| fn |
- 322 See proposed Rule 613(c)(7)(i)(F). - |
| fn | - - |
| fn | - - |
| fn |
- 325 See Rule 613(j)(3) for a definition of "customer." - |
| fn |
- 326 See Proposing Release, supra note 4, at 32573; proposed Rule 613(c)(7)(i)(B). - |
| fn |
- 327 See CBOE Letter, p. 2; Managed Funds Association Letter, p. 2; FINRA Letter, p. 9; SIFMA Drop Copy Letter, p. 1; SIFMA Letter, p. 9. - |
| fn |
- 328 See CBOE Letter, p. 2. - |
| fn | - - |
| fn |
- 330 See FINRA Letter, p. 9. - |
| fn |
- 331 See SIFMA Drop Copy Letter, p. 1. See also SIFMA Letter, p. 9. - |
| fn |
- 332 See Liquidnet Letter, p. 4; SIFMA Letter, p. 10-11; Knight Letter, p. 2; Scottrade Letter, p. 1; Direct Edge Letter, p. 3; FINRA Proposal Letter, p. 4. - |
| fn |
- 333 See Angel Letter, p. 2; FIF Letter, p. 2; BOX Letter, 2. - |
| fn |
- 334 See SIFMA Letter, p. 10; Wells Fargo Letter, p. 3; Ross Letter, p. 1; ICI Letter, p. 3; FIF Letter, p. 2. - |
| fn |
- 335 See SIFMA Drop Copy Letter, p. 1. See also SIFMA Letter, p. 9. - |
| fn |
- 336 Id. - |
| fn |
- 337 See SIFMA Letter p. 9, 10. - |
| fn |
- 338 See Liquidnet Letter, p. 4; SIFMA Letter, p. 10-11; Knight Letter, p. 2; Scottrade Letter, p. 1; Direct Edge Letter, p. 3; FINRA Proposal Letter, p. 4; SIFMA Letter, p. 11. - |
| fn |
- 339 See Proposing Release, supra note 4, at 32573; Liquidnet Letter, p. 4. - |
| fn |
- 340 See SIFMA Letter, p. 10. - |
| fn |
- 341 See Knight Letter, p. 2. - |
| fn |
- 342 See Scottrade Letter, p. 1. See also Knight Letter, p. 2; Direct Edge Letter, p. 4. - |
| fn |
- 343 See Direct Edge Letter, p. 3. - |
| fn |
- 344 See FINRA Proposal Letter, p. 4. - |
| fn |
- 345 See SIFMA Letter, p. 11. - |
| fn |
- 346 See Angel Letter, p. 2; FIF Letter, p. 2; BOX Letter, p 2. - |
| fn |
- 347 See Angel Letter, p. 2. This commenter stated that "[i]t would be relatively simple and cheap to add four fields to each trade report that would contain the account numbers of the buyer and seller and the Market Participant Identifier (MPID) for the original order entry firms." - |
| fn |
- 348 See FIF Letter, p. 2. This commenter recommended that the requirement for such unique customer identifiers be tabled until after regulators have experience using CAT without this identifier. - |
| fn |
- 349 See FIF Letter, p. 2. - |
| fn |
- 350 See BOX Letter, p. 2. - |
| fn |
- 351 See Section II.A.3., supra. - |
| fn | - - |
| fn |
- 353 See SIFMA Letter, p. 11. - |
| fn |
- 354 Id. See also FINRA Proposal Letter, Appendix B (setting forth a method for identifying large traders through the "registration of unique market participant identifiers rather than by requiring broker-dealers to provide the CAT processor with any large trader numbers assigned by the SEC in order reports, thereby minimizing the ability of market participants to reverse engineer a large trader's identity or trading strategy"). - |
| fn |
- 355 See FINRA Proposal Letter, p. 6-7. - |
| fn |
- 356 See SIFMA Letter, p. 10; Wells Fargo Letter, p. 3; Ross Letter, p. 1; ICI Letter, p. 2; FIF Letter, p. 2. - |
| fn |
- 357 See SIFMA Letter, p. 10 (noting that "in recent years, increased concerns about identity theft and client confidentiality have led the securities industry to move away from using social security identification numbers or taxpayer identification numbers as a way to monitor clients and customers. The SEC has affirmed that it would guard access to customer social security and taxpayer identification numbers with even more safeguards than it does other information in the central repository of the consolidated audit trail. Although the SEC has a strong record of protecting investor privacy, the very presence of potentially billions of unique customer identifiers tied to personal information in a central repository would create a substantial risk of misuse and identity theft. The risk of unique customer identifiers being stolen or misused would be magnified in a real-time reporting system"). - |
| fn |
- 358 See Wells Fargo Letter, p. 3. However, this commenter also noted that, "[w]hile the full panoply of privacy concerns that flow from having a unique order identifier being available to every participant in the order execution process may be difficult to assess, creating a system that has that unique identifier available for primarily the post trade review likely solves both the privacy and cost issues in a manner reasonable for both clients, market participants and regulators." Id. - |
| fn |
- 359 See Ross Letter, p. 1 (asking at what level of security to encrypt customer data, and for how long to encrypt it for, as well as how long the Commission would need to decrypt the customer's name – whether on a real time or overnight basis, and noting that data encryption is expensive and could enlarge message sizes.) See also ICI, p. 3 (suggesting that the Commission expressly state who would have access, when they could access it, and how they could use it; and also recommending requiring that all data sent to the central repository be encrypted and that certain fields be "masked" or that reporting of information in such fields be delayed until end-of-day to reduce concerns about leaked information being used for frontrunning). - |
| fn |
- 360 See FIF Letter, p. 2. - |
| fn |
- 361 Because existing SRO audit trails do not require customer information to be reported, regulators must request that information identifying the customer, often from a multitude of sources, which can result in significant delays in investigating market anomalies or violative trading. Additionally, indirect access to an exchange (such as "sponsored access" arrangements) also has made it more difficult to use the current EBS system and Rule 17a–25 to identify the originating customer because the broker-dealer through whom an order is sent to an exchange may not know or have direct access to information identifying the customer who originally submitted the order. - |
| fn |
- 362 See notes 331-334, supra, and accompanying text. - |
| fn |
- 363 See Angel Letter, p. 2. - |
| fn |
- 364 See SIFMA Letter, p. 9-11; FINRA Proposal Letter, p. 4 and 6. - |
| fn |
- 365 For purposes of the following discussion, the Commission will use the terms "unique customer identifier" and "Customer-ID" interchangeably. - |
| fn |
- 366 Under the Rule, each customer would be assigned a unique customer identifier, or Customer-ID. However, an order may have more than one Customer-ID if the account holder differs from the person from whom the broker-dealer is authorized to take trading instructions or if more than one person is an account holder for the account or is authorized to give trading instructions for the account. - |
| fn |
- 367 See Rule 613(a)(1)(xi). - |
| fn |
- 368 See SIFMA Letter, p. 11. - |
| fn |
- 369 See SIFMA Letter, p. 11. - |
| fn |
- 370 See Section III.B.1.e., infra. - |
| fn |
- 371 See FINRA Letter, p. 8-9. - |
| fn |
- 372 See ICI Letter, p. 2-4; SIFMA Letter, p. 10-11; Angel Letter, p. 2; Ross Letter, p. 1. - |
| fn |
- 373 See Section III.B.2.e., infra. - |
| fn |
- 374 See Ross Letter, p. 1. - |
| fn |
- 375 See Rule 613(a)(1)(iv). - |
| fn |
- 376 See also Section III.B.2.e., infra, for a discussion of the provisions in the NMS plan designed to protect the privacy and confidentiality of the consolidated audit trail data. - |
| fn |
- 377 See Rule 613(j)(4). - |
| fn |
- 378 See Rule 613(e)(2). See also Section III.B.2.d., infra. - |
| fn |
- 379 See FINRA Letter, p. 9. - |
| fn |
- 380 See SIFMA Letter, p. 11. - |
| fn |
- 381 Id. - |
| fn |
- 382 The Commission also notes that it retains the authority to request additional information from broker-dealers (and other market participants it regulates) where information about a customer of a broker-dealer beyond that required by Rule 613(j)(3) is needed to fulfill its mission. - |
| fn |
- 383 Rule 17a-3(a)(9), among other things, requires a broker-dealer to make and keep a record of the name and address of the "beneficial owner" of each cash or margin account with the broker-dealer. 17 CFR 240.17a-3(a)(9). Rule 613 is not intended to alter in any way the information that a broker-dealer is currently required to obtain under Rule 17a-3(a)(9). - |
| fn |
- 384 The Commission notes that, under Rule 613, both joint account holders would also receive their own unique customer identifier. - |
| fn |
- 385 See Rule 613(j)(3)(ii). - |
| fn |
- 386 For the purpose 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)(i). - |
| fn |
- 387 Pursuant to the definition of "customer" under adopted Rule 613, the Rule would not capture owners of a fund because they are not the account holders at the broker-dealer. - |
| fn |
- 388 This is because, for the purpose 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). If an individual creates and operates two separate entities (as an employee of each such entity) that each maintain a trading account at one or more broker-dealers, the broker-dealers would be required to record and report the Customer-IDs of those entities, and not the customer ID of the individual trader. - |
| fn |
- 389 See Proposing Release, supra note 4, at 32576. - |
| fn |
- 390 See Thomson Reuters Letter, p. 3; Liquidnet Letter, p. 6-7; SIFMA Letter, p. 12; FINRA Letter, p. 7; FIF Letter, p. 3; FIF Letter II, p. 2. - |
| fn |
- 391 See Liquidnet Letter, p. 6-7; SIFMA Letter, p. 12; FINRA Letter, p. 7; FIF Letter, p. 3. - |
| fn |
- 392 See FINRA Letter, p. 7-8. FINRA expressed concern that, if two child orders from the same parent order are sent to the same market center, regulators would need to look at time stamps and other attributes, such as share quantity and price, to attempt to create an accurate linkage for each individual child order. FINRA stated that this complexity could be avoided if members used a separate unique routed order identifier for each routed order. Id. - |
| fn |
- 393 See FINRA Proposal Letter, p. 7-8. - |
| fn |
- 394 See FIF Letter II, p. 2. - |
| fn |
- 395 See SIFMA Letter, p. 12. See also SIFMA Drop Copy Letter, p. 2 (suggesting a routed order identifier or a child order identifier which would be separate from the unique order identifier of the parent order, and would be reported to the consolidated audit trail separately on a non-real-time basis, as well as linkage information). - |
| fn |
- 396 See FIF Letter, p. 3 (recommending the linking of the order information in a fashion similar to OATS whereby the information would only be available to regulators). - |
| fn |
- 397 See SIFMA Letter, p. 12. In addition, another commenter suggested that order identifiers should be unique by broker and day, similar to the approach used by OATS. See Liquidnet Letter, p. 7. - |
| fn |
- 398 See Rule 613(c)(7)(i)(B); Rule 613(c)(7)(ii)(A); Rule 613(c)(7)(iii)(A); Rule 613(c)(7)(iv)(A); Rule 613(c)(7)(v)(A); Rule 613(c)(7)(vi)(C); and Rule 613(j)(1). - |
| fn |
- 399 See Rule 613(j)(1). - |
| fn |
- 400 See Section III.C.2.a., infra. - |
| fn |
- 401 See FIF Letter, p. 3; Liquidnet Letter, p. 7; SIFMA Letter, p. 12; SIFMA Drop Copy Letter, p. 12; FINRA Letter, p. 8. - |
| fn |
- 402 See Section II.A., supra. - |
| fn |
- 403 See Rule 613(j)(1). For example, one of the methods that the SROs could consider using to demonstrate the efficacy of their approach would be to engage appropriate third party experts to confirm that the system's proposed design and functionality would achieve its stated accuracy and reliability benchmarks. - |
| fn |
- 404 See Section III.C.2.a.i., infra; Rule 613(a)(1)(iii) and (iv). - |
| fn |
- 405 See Rule 613(e)(1). - |
| fn |
- 406 See FINRA Letter, p. 4-7. - |
| fn |
- 407 See SIFMA Letter, p. 12. See also FIF Letter, p. 3. - |
| fn |
- 408 See SIFMA Letter, p. 12. - |
| fn |
- 409 See proposed Rules 613(c)(7)(i)(H), 613(c)(7)(ii)(C), 613(c)(7)(iii)(C), 613(c)(7)(iv)(B), 613(c)(7)(v)(C). - |
| fn |
- 410 See Endace Letter, p. 1-2. - |
| fn |
- 411 See Endace Letter, p. 1. The Commission notes that this commenter also suggested that the same time increment be extended to market data feeds to help increase transparency and deter fraudulent activity; however, this comment is outside the scope of this Release. - |
| fn |
- 412 Id. at 2-3. - |
| fn |
- 413 See SIFMA Letter, p. 14. - |
| fn |
- 414 See FIF Letter, p. 6-7. - |
| fn |
- 415 Id. See Section III.B.1.d.v., infra, for further discussions of "time drift" and the issues raised by this commenter in that regard. - |
| fn | - - |
| fn |
- 417 See Rules 613(c)(7)(i)(E), 613(c)(7)(ii)(C), 613(c)(7)(iii)(C), 613(c)(7)(iv)(C), and 613(c)(7)(v)(C). - |
| fn |
- 418 See, e.g., Securities Industry Automated Corporation's ("SIAC") Consolidated Quotation System ("CQS") Output Specifications Revision 40 (January 11, 2010); SIAC's Consolidated Tape Service ("CTS") Output Specifications Revision 55 (January 11, 2010); and Nasdaq's Unlisted Trading Privileges Plan Quotation Data Feed Interface Specifications Version 12.0a (November 9, 2009). - |
| fn |
- 419 See, e.g., http://batstrading.com/resources/features/bats_exchange_Latency.pdf (describing, among other things, the time it takes to accept, process, and acknowledge or fill a member order). - |
| fn |
- 420 See Endace Letter, p. 1. - |
| fn |
- 421 See FIF Letter, p. 7. - |
| fn |
- 422 See Section III.B.1.h., infra, for a discussion of clock synchronization. - |
| fn |
- 423 See FIF Letter, p. 6-7. - |
| fn |
- 424 Similarly, although reporting in increments finer than a millisecond would also enable the accurate time-sequencing of events originating from within a single system or systems operating off the same clock, the Commission recognizes that the effects of time drift across the clocks of different systems could limit the efficacy of time-sequencing sub-millisecond events across those systems. - |
| fn |
- 425 See FINRA's Order Audit Trail System, Frequently Asked Questions, http://www.finra.org/Industry/Compliance/MarketTransparency/OATS/NMS/P122893 (last visited on May 15, 2012). - |
| fn |
- 426 See Endace Letter, p. 1 (stating that "[t]oday Exchanges such as NYSE Euronext and BATS are claiming that they are executing orders in less than a millisecond (see Wall Street Journal on the January 6th 2010) and are displaying details of these trades in increments of milliseconds on their market data feeds. Clearly from an Exchange perspective the publishing of trade data at one millisecond increments is not just possible, its current practice. However, Endace believes that one millisecond increments is not good enough"); SIFMA Letter, p. 14 (acknowledging that, "[a]lthough firm systems tend to capture time stamps in milliseconds, reporting in milliseconds would require changes to internal systems given that existing audit trails such as OATS require reporting of time stamps accurate only to the second"). - |
| fn |
- 427 See SIFMA Letter, p. 14. - |
| fn |
- 428 See Rule 613(a)(1)(xii). - |
| fn |
- 429 See Rule 613(a)(1)(vii). - |
| fn |
- 430 See Rule 608(b)(1) under Regulation NMS, 17 CFR 242.608(b)(1). - |
| fn |
- 431 See GETCO Letter, p. 4. - |
| fn |
- 432 Id. - |
| fn |
- 433 Id. - |
| fn |
- 434 OATS rules currently require the recording and reporting of orders routed internally. See FINRA Rule 7440(c). - |
| fn |
- 435 The Commission acknowledges that certain orders received by an exchange may be routed to another exchange; however, the routing of such an order to the other exchange is largely subject to the rules of the exchange and Rule 613 will capture such routing as a reportable event. - |
| fn |
- 436 In general, flash orders are communicated to certain market participants and either executed immediately or withdrawn immediately after communication. The Commission has proposed and sought comment on whether to amend Rule 602 of Regulation NMS under the Exchange Act to eliminate an exception for the use of flash orders by equity and options exchanges. See Securities Exchange Act Release Nos. 60684 (September 18, 2009), 74 FR 48632 (September 23, 2009); 62445 (July 2, 2010), 75 FR 39625 (July 9, 2010). - |
| fn |
- 437 See Section III.B.1.d.vi., supra, for a discussion of the modifications to Rule 613(c)(7)(ii) through (iii). - |
| fn |
- 438 The Commission notes that OATS rules also require both the FINRA reporting member routing an order and the FINRA reporting member receiving the order to record and report certain audit trail data. See FINRA Rule 7440(C). See also Rule 613(c)(7)(ii)(D) and Rule 613(c)(7)(iii)(D) through (E). - |
| fn |
- 439 See SIFMA Drop Copy Letter, p. 4. - |
| fn |
- 440 Id. - |
| fn |
- 441 See Liquidnet Letter, p. 7. - |
| fn |
- 442 See, e.g., FINRA Rule 7440(d); Nasdaq Rule 6950; NYSE Rule 132B. - |
| fn |
- 443 See SIFMA Drop Copy Letter, p. 4. - |
| fn |
- 444 See Section III.B.1.iii., supra. - |
| fn |
- 445 See Liquidnet Letter, p. 7. - |
| fn |
- 446 While the Commission is not requiring that execution data be linked with the public trade report using a common identifier, the Commission notes that the Rule does not prohibit the SROs from including a provision in the NMS plan for the establishment of a common identifier to link the audit trail execution reports for buy and sell orders to the public trade report. - |
| fn |
- 447 See Rule 613(j)(9) for a definition of "reportable event." - |
| fn |
- 448 See proposed Rule 613(c)(3). - |
| fn |
- 449 See Proposing Release, supra note 4, at 32572. - |
| fn |
- 450 See Thomson Reuters Letter, p. 3; Aditat Letter, p. 2; FTEN Letter p. 3; Ameritrade Letter, p. 1 (stating that the scalability of its systems could support real-time reporting); Nasdaq Letter II, p. 3 (stating that a platform supported by FTEN and SMARTS technology would support the real-time provision of data). - |
| fn |
- 451 See Ameritrade Letter, p. 1. - |
| fn |
- 452 See Aditat Letter, p. 1-2. FIX Protocol is a series of messaging specifications for the electronic communication of trade-related messages. It has been developed through the collaboration of banks, broker-dealers, exchanges, industry utilities and associations, institutional investors, and information technology providers from around the world. See What is FIX? available at http://fixprotocol.org/what-is-fix.shtml (last visited on May 7, 2011). - |
| fn |
- 454 See Scottrade Letter, p. 1-2; ICI Letter, p. 4-5; SIFMA Letter, p. 4-5; Knight Letter, p. 2. See also BATS Letter, p. 2; Broadridge Letter, p. 3; FIF Letter, p. 4; GETCO Letter, p. 3-4; CBOE Letter, p. 4; FIA Letter, p. 2. In particular, FIA noted its belief that "real-time reporting accounts for a significant portion of the considerable costs associated with the CAT." See FIA Letter, p. 2. - |
| fn |
- 455 See FINRA/NYSE Euronext Letter, p. 5; FINRA Letter, p. 13; SIFMA Letter, p. 5; CBOE Letter, p. 4 (stating that, "given the increased speed of order submission, quote changes, and order cancellation, modifications and executions, a real time submission requirement could strain the systems capacities and computer resources of SROs and many member firms"). - |
| fn |
- 456 See FINRA Letter, p. 13. See also Berkeley Letter, p. 2 (noting the "peta-scale" problem of collecting audit trail data generally). - |
| fn |
- 458 See FINRA/NYSE Euronext Letter, p. 5-6 (noting that "drawing conclusions based solely on real time data increases the potential for inaccuracy because the data has not gone through the full range of validations . . . ."). See also Wells Fargo Letter, p. 3 ("[A]ccurate market information often does not happen in real time."); FINRA Letter, p. 11-12 (stating that current order-handling practices make "accurate real time order reporting problematic, and automated surveillance is only useful if the underlying data is accurate and complete . . . ."); SIFMA Letter, p. 5 ("There also would be data integrity costs in the form of less reliable data, or data that would have to be revised or resubmitted where it otherwise may not have been required if firms had a short window of time to more thoroughly 'scrub' or validate their submissions."); Direct Edge Letter, p. 3 ("Real-time data may be less reliable than information collected after the validations that come with settling a transaction."). - |
| fn |
- 459 See Knight Letter, p. 2-3. See also CBOE Letter, p. 4 ("[G]enerally our belief is that next day (T+1) data, which incorporates additional information such as cleared trade data, is a better report resource for generating surveillance and compliance reviews."); FINRA/NYSE Euronext Letter, p. 6 (stating that, "from a market surveillance standpoint, reliable and complete data received on a T+1 basis . . . is generally superior to unvalidated real-time data"); FIA Letter, p. 2 ("We believe the Commission's Proposal overvalues any potential benefits achieved by real-time reporting as compared to reporting on day after trade, or 'T+1,' basis."). - |
| fn |
- 460 See FINRA Letter, p. 11-12. - |
| fn |
- 461 Id. at p. 11. - |
| fn |
- 462 See Nasdaq Letter I, p. 9-10. - |
| fn |
- 463 See Nasdaq Letter II, p. 3. - |
| fn |
- 465 See FINRA Letter, p. 11. - |
| fn |
- 466 See SIFMA February 2012 Letter, p. 1. - |
| fn |
- 467 See FINRA/NYSE Euronext Letter, p. 4; FINRA Letter, p. 11; FIA Letter, p. 2. - |
| fn |
- 468 See FINRA Proposal Letter, p. 4. - |
| fn |
- 469 See SIFMA Drop Copy Letter, p. 1-2. See also FINRA Proposal Letter, p. 10. - |
| fn |
- 470 See GETCO Letter, p. 2; BATS Letter, p. 2. - |
| fn |
- 471 See FIA Letter, p. 2. - |
| fn |
- 473 See FINRA/NYSE Euronext Letter, p. 4. Similarly, FINRA believes "the SEC has significantly overvalued the regulatory benefits to be achieved . . . while underestimating some of the problems with relying on real-time data. This is true not only because certain information is difficult, if not impossible, to provide on a real-time basis, but also because real-time data is less reliable." See FINRA Letter, p. 10-11. See also SIFMA February 2012 Letter, p. 1 (stating, "[a]ny potential incremental benefit of receiving this information on a real-time basis is, in our view, substantially outweighed by the additional expense and implementation delays associated with building and maintaining a real-time system"); FIA Letter, p. 2 ("It is not apparent to us from the Proposal that the additional costs associated with a real-time audit trail, compared to a T+1 audit trail, would be offset by any incremental benefits to the Commission."). - |
| fn |
- 474 See CBOE Letter, p. 4. - |
| fn |
- 475 See SIFMA Letter, p. 3; see also SIFMA February 2012 Letter, p. 1 (questioning the regulatory need for real-time data versus data provided on an "end-of-day or 'T+1" basis); FIA Letter, p. 2. - |
| fn |
- 476 See Scottrade Letter, p. 2; ICI Letter, p. 5; BATS Letter, p. 2; Angel Letter, p. 3; Broadridge Letter, p. 3. - |
| fn |
- 477 See ICI Letter, p. 6. - |
| fn |
- 478 See SIFMA Drop Copy Letter, p. 1. The commenter stated that "implementation options and complexity are significantly different if the reporting regime is within'minutes' rather than 'seconds.' If real-time reporting is required in seconds, then significant re-engineering is required within broker-dealer order management systems and trading systems to support such a requirement (e.g., passing additional information between systems, performance tuning to compensate for additional processing of payload). Instead, if the definition of real-time allows for reporting within minutes (e.g., 10-15 minutes) of the events, it would be substantially less intrusive on order management systems and may allow for greater flexibility in designing reporting systems architecture and more standardized content for events such as order modifications, as described below. Also, as with prior implementations of new trade reporting regimes in the U.S. (e.g., ACT and TRACE), having more liberal reporting timeframes for an appropriate initial period (e.g., 12 months or more) to provide a sufficient period to optimize processes would be very helpful." This commenter also questioned "the need for real-time reporting of the entire set of data elements in the CAT proposal," and believed that "reporting on a T+1 (or in some cases later) basis should satisfy the SEC's stated regulatory objectives more efficiently." Id. See also Nasdaq Letter II, p. 3 (stating its proposed platform could support the provision of data in real time or within 10-15 minutes using drop copies). - |
| fn |
- 479 See GETCO Letter, p. 4. The commenter also believed this approach would lower the costs of the consolidated audit trail. - |
| fn |
- 480 See Bean Letter, p. 1. - |
| fn |
- 481 See BOX Letter, p. 2. - |
| fn |
- 482 Id. at p. 3. - |
| fn |
- 483 See Nasdaq Letter II, p. 2. - |
| fn |
- 484 See FINRA/NYSE Euronext Letter, p. 6. This commenter stated that "[a]n alternative to the all-encompassing real time order audit trail set forth in the Proposal would be to standardize and consolidate existing real time reporting systems (e.g., enhancing trade reporting and quotation systems with standardized and uniform identification for all broker-dealers) and enhance existing reporting requirements where the need is narrowly focused." See also FINRA Proposal Letter, p. 3-4, 10-11. - |
| fn |
- 485 See FIF Letter, p. 4; Ross Letter, p. 1. - |
| fn |
- 486 See FIF Letter, p. 4. - |
| fn |
- 487 See Ross Letter, p. 1. - |
| fn |
- 488 See Ameritrade Letter, p. 2. - |
| fn |
- 489 Id. - |
| fn |
- 490 Id. - |
| fn |
- 491 Id. - |
| fn |
- 492 Id. - |
| fn |
- 493 See Thomson Reuters Letter, p. 2. - |
| fn |
- 494 See Rule 613(c)(3). The Rule further provides that the NMS plan "may accommodate voluntary reporting prior to 8: 00 a.m. Eastern Time, but shall not impose an earlier reporting deadline on the reporting parties." Id. - |
| fn |
- 495 Id. - |
| fn |
- 497 See Thomson Reuters Letter, p. 3; Aditat Letter, p. 2; FTEN Letter p. 3; Ameritrade Letter, p. 1 (stating that the scalability of its systems could support real-time reporting); Nasdaq Letter II, p. 3 (stating that a platform supported by FTEN and SMARTS technology would support the real-time provision of data). - |
| fn |
- 498 See SIFMA Drop Copy Letter. - |
| fn |
- 499 See Section II.A.1.c., supra. - |
| fn |
- 500 See Rule 613(c)(3). The Commission notes that Rule 613, as proposed, was inconsistent in its use of the terms "provide" and "report." To eliminate this inconsistency, the Commission is replacing all uses of "provide" with "report," which the Commission believes more accurately describes the requirement the Commission is imposing on national securities exchanges, national securities associations, and members. - |
| fn |
- 501 See note 494, supra. - |
| fn |
- 502 See note 453, supra, and accompanying text. - |
| fn |
- 503 The Commission notes that, consistent with adopting an incremental approach to the creation of a consolidated audit trail, even though it is not requiring audit-trail data to be reported in real time, it is adding various additional requirements, discussed in Section III.C.2.a., infra, to the Rule regarding the evolution of the consolidated audit trail, including the possibility for reduced reporting times in the future as technologies evolve. - |
| fn |
- 504 The current OATS technical specifications require OATS reporting by 8: 00 a.m. on the calendar day after the reportable event. The Commission notes that the FINRA rules for OATS reporting, however, require that data "shall be transmitted on the day such event occurred" – unless information required by FINRA Rule 7440(b), (c), or (d) (order receipt and origination; order transmittal; order modifications, cancellations, and executions) is unavailable – in such cases, OATS requires reporting on the day the information becomes available. See FINRA Rule 7450(b)(2). Because of the discrepancy between the technical specifications and the applicable FINRA rule, the Commission approved FINRA's proposed rule change to allow OATS reporting as late as 8: 00 a.m. the next day. See Securities Exchange Act Release No. 66021 (December 21, 2011), 76 FR 81551 (December 28, 2011). - |
| fn |
- 505 The Commission notes that the Rule, as adopted, provides that an NMS plan must require information to be reported by 8: 00 a.m. the following trading day, while OATS requires information to be reported by 8: 00 a.m. the following calendar day. Thus, the Rule as adopted provides for a longer reporting period than does OATS with respect to weekends and holidays. - |
| fn |
- 506 As noted in the Proposing Release, supra note 4, at 32592, broker-dealers that rely mostly on their own internal order routing and execution management systems would have needed to make changes to or replace those systems to collect and report the required order and reportable event information to the central repository to comply with the proposed Rule. - |
| fn |
- 507 See e.g., BATS Letter, p. 2; CBOE Letter, p. 2-3; Wells Fargo Letter, p. 2; Knight Letter, p. 3; High Speed, p. 1; FTEN Letter p. 1; Correlix Letter, p. 2; Thomson Reuters Letter, p. 2; FINRA Proposal Letter, p. 16; FINRA/NYSE Euronext Letter, p. 7. - |
| fn |
- 508 See Proposing Release, supra note 4, at 32572. - |
| fn |
- 509 See FTEN Letter, p. 3-4, 13-15; Thomson Reuters Letter, p. 2-3. - |
| fn |
- 510 Id. - |
| fn |
- 511 See FTEN Letter, p. 4, 12, 14. See also SIFMA Drop Copy Letter. - |
| fn |
- 512 See FIX Letter, p. 1; Aditat Letter, p. 2. - |
| fn |
- 513 Id. - |
| fn |
- 514 See Nasdaq Letter II, p. 3. - |
| fn |
- 515 See Rule 613(c)(2). - |
| fn |
- 516 See FTEN Letter, p. 3-4, 13; Thomson Reuters Letter, p. 2-3. See also SIFMA Drop Copy Letter. - |
| fn |
- 517 The Commission believes that, if the NMS plan does not require data to be reported to the central repository in a uniform format, broker-dealers and SROs may not have to make substantial changes to their order management and execution systems to comply with Rule 613, and thus may face lower costs than if data were required to be reported in a uniform format because in that instance, broker-dealers may need to make substantial changes to their order management and execution systems to comply with Rule 613. The Commission acknowledges, however, that there would be costs to convert data to a "uniform electronic format for consolidation and storage." On balance, however, the Commission preliminarily believes that broker-dealers might benefit from economies of scale when normalizing data. - |
| fn |
- 518 See Rule 613(a)(1)(iii). - |
| fn |
- 519 See Proposing Release, supra note 4, at 32578. - |
| fn |
- 520 See proposed Rule 613(c)(4), 613(c)(7)(vi) through (vii). - |
| fn | - - |
| fn |
- 522 See Rule 613(c)(7)(viii). - |
| fn |
- 523 See Section III.B.1.g.i., supra. - |
| fn |
- 524 Rule 613(c)(4) now requires that "each member of a national securities exchange or national securities association" provide the information set forth in the Rule; as proposed, Rule 613(c)(4) required "each national securities exchange, national securities association, and member" to provide the information set forth in the Rule. - |
| fn |
- 525 The Commission has also amended Rule 613(c)(4), as proposed, to include the provision of information sufficient to identify the customer and customer account information. See Rule 613(c)(7)(viii); Section III.B.1.g.ii.(C)., supra. - |
| fn |
- 526 See proposed Rule 613(c)(4), 613(c)(7)(vi), 613(c)(7)(vii). - |
| fn |
- 527 See proposed Rules 613(c)(7)(vi)(D), 613(c)(7)(vi)(E), and 613(c)(7)(vi)(F). - |
| fn |
- 528 See Proposing Release, supra note 4, at 32573; proposed Rule 613(c)(7)(i)(A), (C). - |
| fn |
- 529 See Liquidnet Letter, p. 3; Direct Edge Letter, p. 4 (emphasizing that it would be more important for exchanges to obtain the identity of the brokers on both sides of an execution for cross-market surveillance purposes); SIFMA Letter, p. 6, 9; Ameritrade Letter, p. 3. - |
| fn |
- 530 See FIF Letter, p. 2-3. - |
| fn |
- 531 This commenter suggested an alternative if the Commission believed customer information was necessary, using both EBS and OATS: EBS could send the central repository customer account information (including account number), and OATS would add a field for the account number to link the OATS reports and customer information together. Id. at p. 2-3. - |
| fn |
- 532 See SIFMA Letter, p. 6, 9. - |
| fn |
- 533 See Ameritrade Letter, p. 2-3. - |
| fn |
- 534 Id. - |
| fn |
- 535 See Liquidnet Letter, p. 3. - |
| fn |
- 536 See Liquidnet Letter, p. 3, 5-6. - |
| fn |
- 537 See FIF Letter II, p. 2. - |
| fn |
- 538 See SIFMA Letter, p. 6; Liquidnet Letter, p. 3. - |
| fn |
- 539 See also Rule 613(j)(4) which defines "customer account information" to include, but not be limited to, account number, account type, customer type, date account opened, and large trader identifier (if applicable). - |
| fn |
- 540 Rule 613(j)(3), as adopted, defines the term "customer" to mean the account holder(s) of the account at a registered broker-dealer originating the order; and any person from whom the broker-dealer is authorized to accept trading instructions for such account, if different from the account holder(s). - |
| fn |
- 541 See Proposing Release, supra note 4, at 32573. - |
| fn |
- 542 The Commission notes that, under the Rule, a broker-dealer must only report the account number for the account the customer used to submit an order, not the account numbers for all accounts of a customer. - |
| fn |
- 543 See Rule 613(c)(4). - |
| fn |
- 544 As adopted, Rule 613(c)(7)(viii) provides that, "[f]or original receipt or origination of an order, the following information: (A) Information of sufficient detail to identify the customer; and (B) Customer account information" be recorded and reported to the central repository. - |
| fn |
- 545 See Proposing Release, supra note 4, at 32578. - |
| fn |
- 546 See Section III.B.1.d.iii., supra. - |
| fn |
- 547 See FIF Letter, p. 3. - |
| fn |
- 548 See Section III.B.3.b., infra. - |
| fn |
- 549 See Ameritrade Letter, p. 2-3. - |
| fn |
- 550 However, if any information previously reported by a broker-dealer to the central repository changes, the broker-dealer would need to report the updated information to the central repository by 8: 00 a.m. Eastern Time on the trading day following the day that the broker-dealer receives the updated information - |
| fn |
- 551 See Proposing Release, supra note 4, at 32566. - |
| fn |
- 552 See, e.g., Rules 17a-3, 17a-4, 17a-25 under the Exchange Act, 17 CFR 240.17a-3, 17a-4, 17a-25. - |
| fn |
- 553 See Liquidnet Letter, p. 3, 5-6. - |
| fn |
- 554 See Rule 613(j)(3); see also Section III.B.1.d.iii.(C)(2)., supra (discussing the definition of "customer" as applied to investment advisers). - |
| fn |
- 555 See Proposing Release, supra note 4, at 32573. - |
| fn |
- 556 See SIFMA Letter, p. 21. - |
| fn |
- 557 Id. - |
| fn |
- 558 Id. - |
| fn |
- 559 The Rule does, of course, require the NMS plan submitted to the Commission for its consideration to require the foreign broker-dealer to disclose information about itself to the U.S. broker-dealer, as such information would be expected to be part of the records of the U.S. broker-dealer holding a foreign broker-dealer account. - |
| fn |
- 560 See proposed Rule 613(d)(1). - |
| fn |
- 561 See proposed Rule 613(d)(2). - |
| fn |
- 562 See proposed Rule 613(a)(3)(ii). - |
| fn |
- 563 See SIFMA Letter, p. 14; FIF Letter, p. 6-7; Broadridge Letter, p. 3; Endace Letter, p. 2. - |
| fn |
- 564 See FIF Letter, p. 6. - |
| fn |
- 565 See FIF Letter, p. 6-7 (stating that currently "time drift" is an issue, despite advancements in synchronization technology, with at least one exchange experiencing time drifts between one and three seconds, and the SIP having its own time drift). - |
| fn |
- 566 See SIFMA Letter, p. 14. - |
| fn |
- 567 See Broadridge Letter, p. 3. - |
| fn |
- 568 See FIF Letter, p. 7. - |
| fn |
- 569 See Endace Letter, p. 2. - |
| fn |
- 570 See Liquidnet Letter, p. 8. - |
| fn |
- 571 See OATS Reporting Technical Specifications (May 3, 2011), available at http://www.finra.org/web/groups/industry/@ip/@comp/@regis/documents/appsupportdocs/p123579.pdf (last accessed December 8, 2011). In addition, FINRA allows clock drift of an additional two seconds before re-synchronization is required. - |
| fn |
- 572 See Endace Letter, p. 2. - |
| fn |
- 573 See FIF Letter, p. 6-7. - |
| fn |
- 574 The Commission notes that one commenter suggested that the cost might be limited because GPS receivers could be used and installed for a few thousand dollars per installation. See Endace Letter, p. 2. - |
| fn |
- 575 See Section III.B.1.d.v., supra (explaining the importance to enforcement cases of an accurately timed record of order events). - |
| fn |
- 576 See proposed Rule 613(d)(2). - |
| fn |
- 577 See Rule 613(d)(2). - |
| fn |
- 578 Rule 613(d)(2) provides that "[e]ach national securities exchange and national securities association [shall] evaluate annually the clock synchronization standard to determine whether it should be shortened, consistent with changes in industry standards . . . ." - |
| fn |
- 579 See FIF Letter, p. 7. - |
| fn |
- 580 See proposed Rule 613(e)(1). - |
| fn |
- 581 The term "facility" is defined in Section 3(a)(2) of the Exchange Act, with respect to an exchange, to include "its premises, tangible or intangible property whether on the premises or not, any right to use such premises or property or any service thereof for the purpose of effecting or reporting a transaction on an exchange (including, among other things, any system of communication to or from the exchange, by ticker or otherwise, maintained by or with the consent of the exchange), and any right of the exchange to the use of any property or service." 15 U.S.C. 78c(a)(2). - |
| fn |
- 582 See proposed Rule 613(e)(2). - |
| fn |
- 583 See proposed Rule 613(a)(4). - |
| fn |
- 584 See proposed Rule 613(a)(3)(i). - |
| fn |
- 585 See Ameritrade Letter, p. 4; High Speed Letter, p. 1; BATS Letter, p. 2. - |
| fn |
- 586 See Ameritrade Letter, p. 4. - |
| fn |
- 587 See High Speed Letter, p. 1. - |
| fn |
- 588 See BATS Letter, p. 2. - |
| fn |
- 589 See FINRA Proposal Letter, p. 14-16. - |
| fn |
- 590 See High Speed Letter, p. 1. - |
| fn |
- 591 See Ameritrade Letter, p. 4. - |
| fn |
- 592 See note 581, supra (describing the nature of a "facility"). - |
| fn |
- 593 See Ameritrade Letter, p. 4. - |
| fn |
- 594 See, e.g., 15 U.S.C. 78b; 15 U.S.C. 78f(b); 15 U.S.C. 78o-3(b); 15 U.S.C. 78s(h)(1). - |
| fn |
- 595 Section 19(b)(1) of the Exchange Act defines the term "proposed rule change" to mean "any proposed rule or rule change in, addition to, or deletion from the rules of [a] self-regulatory organization." Pursuant to Section 3(a)(27) and 3(a)(28) of the Exchange Act, the term "rules of a self-regulatory organization" means (1) the constitution, articles of incorporation, bylaws and rules, or instruments corresponding to the foregoing, of an SRO, and (2) such stated policies, practices and interpretations of an SRO (other than the Municipal Securities Rulemaking Board) as the Commission, by rule, may determine to be necessary or appropriate in the public interest or for the protection of investors to be deemed to be rules. - |
| fn |
- 596 See Ameritrade Letter, p. 4. - |
| fn |
- 597 See note 581, supra (describing the nature of a "facility"). - |
| fn |
- 598 15 U.S.C. 78s. - |
| fn |
- 599 17 CFR 242.608(d)(1). If the Commission does not make a finding that the action or failure to act is consistent with the provisions of the NMS plan and was applied in a manner consistent with the Act, or if it finds that such action or failure to act imposes any burden on competition not necessary or appropriate in furtherance of the purposes of the Act, the Commission, by order, can set aside such action and/or require such action with respect to the matter reviewed as the Commission deems necessary or appropriate in the public interest, for the protection of investors, and the maintenance of fair and orderly markets, or to remove impediments to, and perfect the mechanisms of, the NMS plan. 17 CFR 242.608(d)(3). - |
| fn |
- 600 The Commission notes that, as part of its inspection and examination program, its staff has the authority to examine the application of any penalty provisions in the NMS plan to determine whether they have been applied fairly. In this manner, the Commission will be able to monitor how the plan sponsors have applied any penalty provisions set out in the NMS plan approved by the Commission. - |
| fn |
- 601 See Section III.B.2.b., infra; Rule 613(e)(1). - |
| fn |
- 602 See Section III.B.2.e., infra; Rule 613(e)(4)(i). - |
| fn |
- 603 See proposed Rule 613(e)(1). - |
| fn |
- 604 See Sections III.B.1.d. and III.B.1.f., supra. - |
| fn |
- 605 See Rule 613(c)(2); see Section III.B.1.f., supra. - |
| fn |
- 606 See Proposing Release, supra note 4, at 32564. See also Section III.B.2.d., infra. - |
| fn |
- 607 See note 516, supra. - |
| fn |
- 608 See Section III.B.1.d., supra. - |
| fn |
- 609 See proposed Rule 613(e)(5)(i). - |
| fn |
- 610 The effective transaction reporting plans include the CTA Plan and the UTP Plan. See note 101, supra; proposed Rule 613(e)(5)(ii). - |
| fn |
- 611 See proposed Rule 613(e)(5)(iii). - |
| fn |
- 612 See Liquidnet Letter, p. 7. See also Section III.B.d.vii., supra. - |
| fn |
- 613 See proposed Rule 613(e)(5)(i) through (iii). - |
| fn |
- 614 See proposed Rule 613(e)(7)(i) through (iii). - |
| fn |
- 615 See Liquidnet Letter, p. 7. - |
| fn |
- 616 Quote condition is a field in the CQS feed that provides information on a quote, including whether such quote is an opening quote, closing quote, news pending, slow on ask side, slow on bid side, order imbalance or non-firm quote. See CQS Output Multicast Line Interface Specification, Version 48 (October 11, 2011), Appendix G. - |
| fn |
- 617 Manual quotes are not eligible for automatic execution and do not have trade through protection under Rule 611 of Regulation NMS. See 17 CFR 242.600(57) for a definition of a protected bid or protected offer. - |
| fn |
- 618 17 CFR 242.611. - |
| fn |
- 619 See proposed Rule 613(e)(6). - |
| fn |
- 620 See Nasdaq Letter I, p. 10-11. - |
| fn |
- 621 See Ross Letter, p. 1. - |
| fn |
- 622 See proposed Rule 613(e)(6). - |
| fn |
- 623 See Section III.C.2.a.i., infra. - |
| fn |
- 624 See Rule 613(a)(1)(ii). - |
| fn |
- 625 The Commission acknowledges there would be costs to the central repository for retaining data received or collected by the central repository pursuant to Rule 613. As discussed in Section I., supra, the NMS plan submitted to the Commission for its consideration will include a detailed analysis of the costs of the Rule for the Commission and the public to consider after the NMS plan has been submitted. - |
| fn |
- 626 See Proposing Release, supra note 4, at 32582. - |
| fn |
- 627 See Aditat Letter, p. 2; FIF Letter, p. 4; FINRA Letter, p. 11; Nasdaq Letter I, p. 8. - |
| fn |
- 628 See Nasdaq Letter I, p. 8. - |
| fn |
- 629 See FIF letter, p. 4. - |
| fn |
- 630 See Aditat Letter, p. 2. - |
| fn |
- 631 See Commission Staff Memorandum, supra, note 64. - |
| fn |
- 632 Id. - |
| fn |
- 633 Id. - |
| fn |
- 634 See FINRA Letter, p. 11. - |
| fn |
- 635 Id. - |
| fn |
- 636 Id. - |
| fn |
- 637 Id. - |
| fn |
- 638 Id. - |
| fn |
- 639 Id. FINRA also noted, however, that "compliance rates for OATS steadily improved over time as members gained experience with the system. For example, when the OATS rules were first implemented, the match rate between executed orders and the related trade report submitted to an NASD transaction reporting system was only 76%. Currently, this match rate is consistently over 99%, which reflects the significant time and effort that has been expended by the industry to make their systems OATS compliant. FINRA believes that creation of a new system, rather than building off of an existing reporting infrastructure, will necessarily create a learning curve and lead to reduced compliance rates over the short-term." Id. The Commission acknowledges that there could be a learning curve for compliance with the NMS plan requirements for the reporting of data. The Commission, however, expects the NMS plan to minimize such reduced compliance rates to the extent reasonably practicable. - |
| fn |
- 640 See Nasdaq Letter I, p. 13. - |
| fn |
- 641 See Endace Letter, p. 2-3. - |
| fn |
- 642 Id. at p. 3. - |
| fn |
- 643 Rule 613(e)(4)(ii) provides that the NMS plan shall include policies and procedures, including standards, to ensure the timeliness, accuracy, integrity, and completeness of the data provided to the central repository. - |
| fn |
- 644 See Section II.A., supra. - |
| fn |
- 645 See Aditat Letter, p. 2; FIF Letter, p. 4; FINRA Letter, p. 11; Nasdaq Letter I, p. 8. - |
| fn |
- 646 See Rule 613(e)(6)(i). The term "error rate" is defined in Rule 613(j)(6) to mean "[t]he percentage of reportable events collected by the central repository in which the data reported does not fully and accurately reflect the order event that occurred in the market." The SROs should consider calculating an aggregate error rate as well as error rates for subcategories such as trade reporting and quote reporting. - |
| fn |
- 647 See Rule 613(e)(6)(iii) through (iv). - |
| fn |
- 648 See Rule 613(e)(6). - |
| fn |
- 649 The Commission recognizes that in any complex system there is always a risk of occasional unexpected errors, or errors caused by rare and unexpected events. However, the Commission believes that, by tracking error rates on a daily basis, the SROs, and the Commission would be able to observe any repeated patterns or longer-term trends that suggest more systematic problems or concerns with data collection, reporting, or consolidation processes. - |
| fn |
- 650 See Rule 613(e)(6)(iii) through (iv). - |
| fn |
- 651 See Commission Staff Memorandum, supra note 64. - |
| fn |
- 652 See Rule 613(a)(1)(ii). - |
| fn |
- 653 See proposed Rule 613(e)(2). - |
| fn |
- 654 Id. - |
| fn |
- 655 See proposed Rule 613(e)(3). - |
| fn |
- 656 See Liquidnet Letter, p. 8-9. See also SIFMA Letter, p. 19. - |
| fn |
- 657 See Angel Letter, p. 3; Albany Letter, p.1-4; and TIAA-CREF Letter, p.4. - |
| fn |
- 658 See Angel Letter, p. 3. - |
| fn |
- 659 See Albany Letter, p. 1-3. This commenter acknowledged the privacy concerns involved in making the data available for academic research, but stated that researchers have faced similar challenges before and researchers are capable of developing a way to access and share information without the risk of divulging trading strategies or identities. The commenter also stated that data released after a delay would limit the data's usefulness. - |
| fn |
- 660 See Van Bokkelen Letter, p. 1. - |
| fn |
- 661 See Rule 613(e)(3). See also Rule 613(a)(1)(ii) (requiring the NMS plan to detail how readily the NMS plan will allow data in the central repository to be accessed by regulators, as well as the regulators' manner of access); see also Section III.C.2.a.i., infra. - |
| fn |
- 662 See Sections III.C.2.a.i through ii., infra; Rule 613(a)(1)(ii) through (vii). - |
| fn |
- 663 See proposed Rule 613(e)(4)(i). However, a plan sponsor also would be permitted to use the data it submits to the central repository for commercial or other purposes as otherwise permitted by applicable law, rule or regulation. Id. - |
| fn |
- 664 See proposed Rule 613(h)(3), Rule 613(g)(4). - |
| fn |
- 665 See Proposing Release, supra note 4, at 32582. - |
| fn |
- 666 See Scottrade Letter, p. 2 (expressing concern that trading strategies and confidential customer information could be at risk from cyber-attacks or accidental data breaches); ICI Letter, p. 2-4; Ross Letter, p.; 1 Liquidnet Letter, p. 4. See also Ameritrade Letter, p. 3; Thomson Reuters Letter, p. 4; BATS Letter, p. 3; Managed Funds Association Letter, p. 2-3. - |
| fn |
- 667 See Ameritrade Letter, p. 3-4. - |
| fn |
- 668 See Liquidnet Letter p. 4. - |
| fn |
- 669 See Thomson Reuters Letter, p. 4. - |
| fn |
- 670 See TIAA-CREF Letter, p. 4. - |
| fn |
- 671 See ICI Letter, p. 2-4. - |
| fn |
- 672 Id. at 3. - |
| fn |
- 673 Id. - |
| fn |
- 674 See BATS Letter, p. 3. - |
| fn | - - |
| fn |
- 676 Id. - |
| fn |
- 677 See Ross Letter, p. 1. - |
| fn |
- 678 Id. - |
| fn |
- 679 5 U.S.C. 552. - |
| fn |
- 680 See ICI Letter, p. 4. - |
| fn |
- 681 For example, appropriate confidentiality protections will need to be programmed in any Commission systems that collect, store, or access data collected from the central repository. In addition, it may be appropriate to establish multiple access levels for Commission staff so that staff members are allowed only as much access as is reasonably necessary in connection with their duties. - |
| fn |
- 682 See ICI Letter, p. 3 - |
| fn |
- 683 Rule 613(e)(4)(i)(B); see ICI Letter, p. 3 (recommending that "the confidential nature of the information supports limiting access to the CAT data to regulators and repository staff"). - |
| fn |
- 684 See Rule 613(e)(4)(i)(C). The Commission expects that the central repository's CCO would be responsible for determining the frequency of these regular reviews in the first instance, in accordance with industry standards for the review of information security, taking into account the sensitivity of the data stored in the central repository. See Rule 613(b)(5) for a description of the CCO. - |
| fn |
- 685 See BATS Letter, p. 3. See also Managed Funds Association Letter, p. 2-3. - |
| fn |
- 686 The Commission notes that, as part of its inspection and examination program, its staff has the authority to examine the application of any security and confidentiality provisions in the NMS plan to determine whether they have been applied fairly. In this manner, the Commission will be able to monitor how the plan sponsors have applied any such provisions set out in the NMS plan approved by the Commission, and whether their uses of the consolidated audit trail were consistent with the plan and the Exchange Act. - |
| fn |
- 687 See Ross Letter, p. 1. - |
| fn |
- 688 Specifically, adopted Rule 613(e)(4) requires the NMS plan to include policies and procedures, including standards, to be used by the plan processor to ensure the security and confidentiality of all information submitted to the central repository. In addition, one of the considerations the NMS plan must address is how the security and confidentiality of all information, including customer information, submitted to the central repository, will be ensured. See Rule 613(a)(1)(iv). - |
| fn |
- 689 See ICI Letter, p. 4. - |
| fn |
- 690 See Rule 613(e)(4)(i)(D). - |
| fn |
- 691 See Liquidnet Letter, p. 4. - |
| fn |
- 692 See Section III.C.2.a.i., infra. - |
| fn |
- 693 See Rule 613(a)(1)(iv). - |
| fn |
- 694 See proposed Rule 613(h)(1). - |
| fn |
- 695 See proposed Rule 613(h)(2). - |
| fn |
- 696 See proposed Rule 613(h)(3). - |
| fn |
- 697 See Nasdaq Letter I, p. 13. - |
| fn |
- 698 Id. - |
| fn |
- 699 Id. - |
| fn |
- 700 Id. - |
| fn |
- 701 This technical modification simplifies the language of Rule 613(h)(1) and (2) from the proposal. Adopted Rule 613(h)(1) and (2) deletes the language "submitted pursuant to this section" and "of which it is a sponsor." Adopted Rule 613(h)(1) and (2), like the proposed Rule, requires each SRO to comply with the provisions of the NMS plan "approved by the Commission." Because each SRO will be a member of the NMS plan approved by the Commission, it is not necessary to include the phrases not adopted. - |
| fn |
- 702 Any such provision would be subject to notice and comment pursuant to Rule 608 of Regulation NMS. - |
| fn |
- 703 The Commission notes that any failure by a national securities exchange or national securities association to comply with the provisions of the NMS plan approved by the Commission will be considered a violation of Rule 613, and that the Commission could take appropriate steps to address such a violation, including imposing penalties as appropriate. See Rule 613(h)(2). - |
| fn |
- 704 See Section III.B.2.a., supra. - |
| fn |
- 705 See supra note 581 (describing the nature of a "facility"). - |
| fn |
- 706 15 U.S.C. 78q. - |
| fn |
- 707 17 CFR 242.608(d)(1). - |
| fn |
- 708 Id. - |
| fn |
- 709 See Nasdaq Letter I, p. 13. - |
| fn |
- 710 Any such provision would be subject to notice and comment pursuant to Rule 608 of Regulation NMS. - |
| fn |
- 711 15 U.S.C. 78s(b)(2). - |
| fn |
- 712 17 CFR 240.19b-4. - |
| fn |
- 713 See proposed Rule 613(g)(1). This provision in the proposed Rule echoes the requirement contained in Rule 608 that "each self-regulatory organization also shall, absent reasonable justification or excuse, enforce compliance with any such plan by its members and persons associated with its members." 17 CFR 242.608(c). - |
| fn |
- 714 See proposed Rule 613(g)(2). - |
| fn |
- 715 See proposed Rule 613(g)(3). - |
| fn |
- 716 See proposed Rule 613(g)(4). - |
| fn |
- 717 See Knight Letter, p. 3. - |
| fn |
- 718 See Knight Letter, p. 3. - |
| fn |
- 719 See Proposing Release, supra note 4, at 32585. - |
| fn |
- 720 See Nasdaq Letter I, p. 3, 13; Direct Edge Letter, p. 5; FIF Letter, p. 1, 8; FINRA Letter, p. 15; SIFMA February 2012 Letter, p. 1. - |
| fn |
- 721 See Nasdaq Letter I, p. 3, 13. - |
| fn |
- 722 Id. at p. 3. - |
| fn |
- 723 See FIF Letter, p. 1; Direct Edge Letter, p. 5. - |
| fn |
- 724 See FIF Letter, p. 8. - |
| fn |
- 725 See Direct Edge Letter, p. 4-5. - |
| fn |
- 726 Id. at p. 5. - |
| fn |
- 727 Id. - |
| fn |
- 728 See SIFMA February 2012 Letter, p. 1. - |
| fn |
- 729 Proposed Rule 613(b) required that the NMS plan include "a governance structure to ensure fair representation of the plan sponsors, and administration of the central repository, including the selection of the plan processor, . . . [a] provision addressing the requirements for the admission of new sponsors of the plan and the withdrawal of existing sponsors from the plan, . . . [a] provision addressing the percentage of votes required by the plan sponsors to effectuate amendments to the plan, . . . [a] provision addressing the manner in which the costs of operating the central repository will be allocated among the national securities exchanges and national securities associations that are sponsors of the plan, including a provision addressing the manner in which costs will be allocated to new sponsors to the plan. . . [and the] appointment of a Chief Compliance Officer to regularly review the operation of the central repository to assure its continued effectiveness in light of market and technological developments, and make any appropriate recommendations for enhancements to the nature of the information collected and the manner in which it is processed." - |
| fn |
- 730 See Rule 613(b)(6); Rule 613(b)(7). - |
| fn |
- 731 See Rule 613(b)(5). - |
| fn |
- 732 See Rule 613(b)(6). The written assessment could also further inform the extent to which it could be appropriate to share certain information collected by the consolidated audit trail with third parties. See Section III.B.2.d. - |
| fn |
- 733 See SIFMA February 2012 Letter, p. 1. - |
| fn |
- 734 See Rule 613(b)(7)(i). - |
| fn |
- 735 See Rule 613(b)(7)(ii). - |
| fn |
- 736 See Rule 613(b)(7)(i). - |
| fn |
- 737 See Rule 613(b)(7)(ii). - |
| fn |
- 738 See Rule 613(a)(1)(xi); Section III.C.2.a.iii.c., infra, for a discussion of the tenth consideration. - |
| fn |
- 739 See Nasdaq Letter I, p. 3, 13. - |
| fn |
- 740 See, e.g., Options Order Protection and Locked/Crossed Market (Securities Exchange Act Release No. 60405 (July 30, 2009), 74 FR 39362 (August 6, 2009)) (including a unanimous voting requirement). - |
| fn |
- 741 See FIF Letter, p. 1; Direct Edge Letter, p. 5. - |
| fn |
- 742 As discussed and for the reasons set forth in Section I., supra, in light of the multi-step process for developing and approving an NMS plan that will govern the creation, implementation, and maintenance of a consolidated audit trail, the Commission is deferring a detailed analysis of costs and benefits of this requirement of the Rule until after the NMS plan has been submitted. - |
| fn |
- 743 See proposed Rule 613(a)(3)(iv). - |
| fn |
- 744 See Nasdaq Letter I, p. 10; Thomson Reuters Letter, p. 4. - |
| fn |
- 745 See Thomson Reuters Letter, p. 4. - |
| fn |
- 746 See FINRA/NYSE Euronext Letter, p. 3-4. See also Nasdaq Letter I, p. 8. - |
| fn |
- 747 See IAG Letter, p. 2. - |
| fn |
- 748 See BATS Letter, p. 2-3. - |
| fn |
- 749 See Nasdaq Letter I, p. 10. - |
| fn |
- 750 See iSys Letter, p. 2-3. - |
| fn |
- 751 See Rule 613(f). - |
| fn |
- 752 17 CFR 240.17d-2. - |
| fn |
- 753 The Commission has examined the issue of a single market regulator in the past, specifically in the Intermarket Trading Concept Release (see Securities Exchange Act Release No. 47849 (May 14, 2003), 68 FR 27722 (May 20, 2003)); however, a single regulator structure is not suggested by the adopted Rule. - |
| fn |
- 754 These cost savings may accrue to any SRO that would no longer need to operate a retired system, as well as to any SRO members that would no longer be required to report to such systems. - |
| fn |
- 755 See FIF Letter, p. 1, 9; FIF Letter II, p. 1-2; STA Letter, p. 2; Direct Edge Letter, p. 2-3, 5. See also Section II.C.3. - |
| fn |
- 756 See FIF Letter II, p. 2. - |
| fn |
- 757 Id. at p. 3. - |
| fn |
- 758 See Broadridge Letter, p. 2; FIF Letter, p. 8. See also Ross Letter, p. 1 (discussing examples of information security details to consider); Nasdaq Letter I, p. 6 (stating that the proposed Rule provided "incomplete technical information on which design and features make the most sense"). - |
| fn |
- 759 See FIF Letter II, p. 2-3; STA Letter, p. 2. See also Nasdaq Letter I, p. 6. - |
| fn |
- 760 See FIF Letter II, p. 1, 3; STA Letter, p. 1, 3. See also Nasdaq Letter I, p. 6. - |
| fn |
- 761 See FIF Letter II, p. 2; STA Letter, p. 1. - |
| fn |
- 762 See FIF Letter II, p. 1; STA Letter, p. 1-2. - |
| fn |
- 763 See FIF Letter II, p. 2; STA Letter, p. 2. - |
| fn |
- 764 See FIF Letter II, p. 1-2; STA Letter, p. 2. - |
| fn |
- 765 See FIF Letter II, p. 2; STA Letter, p. 2-3. - |
| fn |
- 766 See proposed Rule 613(a)(1). - |
| fn |
- 767 See FIF Letter II, p. 3. The commenter also provided the cost to the industry for the expansion of OATS to all NMS stocks - $48 million. The Commission notes that this is the cost for the project as a whole, not solely for the planning phase, and therefore is not entirely attributable to the cost of the creation and filing of the NMS plan required by Rule 613. - |
| fn |
- 768 The time remaining was spent on "testing and other activities." See FIF Letter II, p. 3. - |
| fn |
- 769 See Nasdaq Letter I, p. 12; FIF Letter II, p. 2-3; STA Letter, p. 1-3; Direct Edge Letter, p. 2-3, 5. - |
| fn |
- 770 See Section I., supra. - |
| fn |
- 771 See, e.g., FINRA Letter, p. 14 (advocating that SROs build off existing audit trails to develop a consolidated audit trail) and Nasdaq Letter I, p. 11-12 (arguing against building off existing audit trail systems and supporting the development of new system to establish a consolidated audit trail). See also Section II.C.4., supra. - |
| fn |
- 772 These actions include the requirement that the SROs develop an NMS plan, utilizing their own resources and undertaking their own research that addresses the specific details, cost estimates, considerations, and other requirements of the Rule. - |
| fn |
- 773 See Section III.B.2.c., supra. - |
| fn |
- 774 The Commission notes that another related consideration that must be discussed by the NMS plan includes the alternative approaches to creating the consolidated audit trail that the plan sponsors considered. See Rule 613(a)(1)(xii). - |
| fn |
- 775 See Section II.A., supra, for additional discussion of the timeliness of access to current audit trail data. - |
| fn |
- 776 See Proposing Release, supra note 4, at 32564. - |
| fn |
- 777 Id. at 32564-32565 and 32594. Differences in audit trail data requirements between markets can hinder the ability of regulators to piece together related illegal trading activity occurring across several markets. - |
| fn |
- 778 Id. at 32594. - |
| fn |
- 779 Id. at 32567. - |
| fn |
- 780 "Transmission from the SRO or member to receipt by the central repository" refers to the process through which SROs and their members report data to the central repository. - |
| fn |
- 781 "Data extraction, transformation and loading at the central repository" is the process during which the central repository accepts data reported by the SROs and their members, converts it into a uniform electronic format, if necessary, and receives it into the central repository's internal systems. - |
| fn |
- 782 "Data maintenance and management at the central repository" refers to the process for storing data at the central repository, indexing the data for linkages, searches, and retrieval, dividing the data into logical partitions when necessary to optimize access and retrieval, and the creation and storage of data backups. - |
| fn |
- 783 As noted in Section III.B.1.d.iv., supra, for example, regardless of whether the NMS plan elects to use a series of order identifiers or a unique order identifier, it will be very important to demonstrate how the approach selected in the NMS plan will ensure that information about all events pertaining to an order will be reliably and accurately linked together in a manner that allows regulators efficient access to complete order information. - |
| fn |
- 784 See Proposing Release, supra note 4, at 32582, 32596. - |
| fn |
- 785 In addition, proposed Rule 613(e)(4)(i) required plan sponsors, and employees of the plan sponsors and central repository to agree to use appropriate safeguards to ensure the confidentiality of such data, and not to use such data other than for surveillance and regulatory purposes. - |
| fn |
- 786 See Scottrade Letter, p. 2; ICI Letter, p. 2-4; Liquidnet Letter, p. 4; Ameritrade Letter, p. 3; Thomson Reuters Letter, p. 4; BATS Letter, p. 3; Managed Funds Association Letter, p. 2-3; Ross Letter, p. 1. The Commission notes that it is adopting Rule 613(e)(4) with modifications – the Commission has added provisions to the Rule to help ensure the confidentiality of the data submitted to and retained by the central repository. See Section III.B.2.e., supra. - |
| fn |
- 787 Rule 613(i) requires the NMS plan to include a provision requiring each SRO to jointly provide to the Commission a document outlining how the consolidated audit trail could be expanded to products other than NMS securities. See also Section III.B.1.a., supra. The consideration of flexibility and scalability of the systems requires the SROs to address whether the system proposed in the SRO's NMS plan submission can accommodate the expansion, while the document required by Rule 613(i) will discuss more broadly how the SROs could incorporate into the consolidated audit trail information with respect to equity securities that are not NMS securities, debt securities, primary market transactions in equity securities that are not NMS securities, and primary market transactions in debt securities, including details for each order and reportable event that may be required to be provided, which market participants may be required to provide the data, an implementation timeline, and a cost estimate. - |
| fn |
- 788 See Concept Release on Equity Market Structure, supra note 87. - |
| fn |
- 789 See Proposing Release, supra note 4, at 32568-32569. - |
| fn |
- 790 Id. at 32569-70. - |
| fn |
- 791 Id. at 32567. - |
| fn |
- 792 See Proposing Release, supra note 4, at 32569 and 32610. The Commission noted in the Proposing Release that a "primary market transaction is any transaction other than a secondary market transaction and refers to any transaction where a person purchases securities in an offering." Proposing Release at n. 167. - |
| fn |
- 793 See Section II.A. for a discussion of these four qualities. - |
| fn |
- 794 See, e.g., Exchange Act Rules 17a-3 and 17a-4 (requiring broker-dealers to make and keep "records of purchases and sales of securities"). - |
| fn |
- 795 Regulation S-K requires registrants to provide information related to the number of offered securities that are underwritten by each syndicate member in an effort to describe the nature of the obligation of the syndicate members with respect to the offered securities. See 17 CFR 229.508(a). This information comprises investor-focused disclosures, rather than information that may be needed by regulators for investigative and other purposes, such as the information contemplated by Rule 613(a)(1)(vi). - |
| fn |
- 796 For example, FINRA rules require the lead underwriters of an IPO to collect and provide issuers – but not the public, FINRA, or the Commission – with names of institutional investors who received allocations and aggregated information regarding the allocation to retail investors. See FINRA Rule 5131(d). The Depository Trust Company ("DTC") also collects information on some IPO allocations in its IPO Tracking System at the discretion of the lead underwriter. See 61 FR 25253 (May 20, 1996). However, as well as being discretionary and therefore only addressing a subset of primary market transactions, the IPO Tracking System only includes allocations to persons with DTC accounts, which generally excludes retail investors. - |
| fn |
- 797 See, e.g., FINRA Rules 5130 and 5131. FINRA Rule 5130 imposes certain restrictions on primary market transactions. FINRA Rule 5131 prohibits certain allocation practices such as "spinning," which refers to an underwriter's allocation of IPO shares to directors or executives of investment banking clients in exchange for receipt of investment banking business. See Securities Exchange Act Release No. 64521 (May 18, 2011), 76 FR 29808 (May 23, 2011) (Order Approving SR-FINRA-2011-017). Certain "quid pro quo" practices are also addressed by FINRA Rule 5131. - |
| fn |
- 798 Currently, SROs must request customer account information during examinations of broker-dealers to check for compliance with order marking rules. - |
| fn |
- 799 This approach also may unduly burden the lead underwriter as the "gatekeeper" of such information and prevents the Commission and SROs from pursuing investigative techniques that may rely on reaching out to individual market participants for preliminary information without using the underwriter. - |
| fn |
- 800 See note 242, supra. - |
| fn |
- 801 See note 795, supra. - |
| fn |
- 802 "Laddering" is a practice that generally refers to inducing investors to give orders to purchase shares in the aftermarket at particular prices in exchange for receiving IPO allocations. See NYSE/NASD IPO Advisory Committee report and Recommendations (May 2003), at 6, available at http://www.finra.org/web/groups/industry/@ip/@reg/@guide/documents/industry/p010373.pdf. - |
| fn |
- 803 See, e.g, FINRA Letter, p. 14; SIFMA Letter, p. 16-18. - |
| fn |
- 804 The methodology in the Proposing Release assumed that the scope of the required systems changes would be comparable to those made in connection with Regulation NMS. See Proposing Release, supra note 4, at 32597 n. 352. See also Section I., supra. - |
| fn |
- 805 These actions include the requirement that the SROs develop an NMS plan, utilizing their own resources and undertaking their own research that addresses the specific details, cost estimates, considerations, and other requirements of the Rule. - |
| fn |
- 806 See Section I., supra. - |
| fn |
- 807 See Rule 613(a)(1)(vii). - |
| fn |
- 808 See Wells Fargo Letter, p. 4; SIFMA Letter, p. 22. - |
| fn |
- 809 See Wells Fargo Letter, p. 4. - |
| fn |
- 810 See Liquidnet Letter, p. 9. - |
| fn |
- 811 See SIFMA Letter, p. 22. - |
| fn |
- 812 See Nasdaq Letter I, p. 13-14; BOX Letter, p. 3; Liquidnet Letter, p. 9; Kaufman Letter, attachment p. 3. - |
| fn |
- 813 See Nasdaq Letter I, p. 13-14. - |
| fn |
- 814 See Kaufman Letter, attachment p. 3. - |
| fn |
- 815 See Schumer Letter, p. 1. - |
| fn |
- 816 Id. at p. 1-2. - |
| fn |
- 817 Id. at p. 2. - |
| fn |
- 818 See Section III.B.2., supra. - |
| fn |
- 819 See Section III.B.1., supra. - |
| fn |
- 820 See Section I., supra. - |
| fn |
- 821 See 17 CFR 242.608(a)(4)(ii)(C). - |
| fn |
- 822 See Rule 613(a)(1)(viii). - |
| fn |
- 823 See Rule 613(a)(5). - |
| fn |
- 824 See Section II.C.3., supra, for a summary of comments suggesting wider involvement in the development of the consolidated audit trail. - |
| fn |
- 825 See FIF Letter II, p. 2; SIFMA February 2012 Letter, p. 1; STA Letter, p. 1-2. - |
| fn |
- 826 See SIFMA February 2012 Letter, p. 1. - |
| fn |
- 827 See Broadridge Letter, p. 2. - |
| fn |
- 828 See FIF Letter II, p. 2, STA Letter, p. 1-2. - |
| fn |
- 829 See Direct Edge Letter, p. 2. - |
| fn |
- 830 See Direct Edge Letter, p. 2. - |
| fn |
- 831 See Ameritrade Letter, p. 2. - |
| fn |
- 832 See IAG Letter, p. 3 (also recommending that the consolidated audit trail, in general, should involve a reduction in its size and scope, as well as a review of the capabilities of existing systems). - |
| fn |
- 833 See FIF Letter II, p. 1-3. See also STA Letter, p. 1-3 (recommending the same, but with the inclusion of the investor community and institutional asset managers). - |
| fn |
- 834 See also Rules 613(a)(1)(vii)(A) and (D), respectively requiring "[a]n estimate of the costs to the plan sponsors for establishing and maintaining the central repository" and an explanation of "[h]ow the plan sponsors propose to fund the creation, implementation, and maintenance of the consolidated audit trail, including the proposed allocation of such estimated costs among the plan sponsors, and between the plan sponsors and members of the plan sponsors." - |
| fn |
- 835 The Commission notes that any NMS plan submitted and any amendment to the plan would be subject to notice and public comment, during which members of the industry and other interested persons may provide comments on the NMS plan. 17 CFR 242.608(b)(1). - |
| fn |
- 836 See Rule 613(b)(7). See also Section III.B.3.b., supra. - |
| fn |
- 837 See Rule 613(a)(1)(xii). - |
| fn |
- 838 See Rule 613(a)(1)(ix). - |
| fn |
- 839 See Proposing Release, supra note 4, at 32595. - |
| fn |
- 840 See SIFMA Letter, p. 2. - |
| fn |
- 841 Id. - |
| fn |
- 842 See FINRA Letter, p. 2. - |
| fn |
- 843 Id. at p. 2-3. - |
| fn |
- 844 See FINRA/NYSE Euronext Letter, p. 4. - |
| fn |
- 845 See Liquidnet Letter, p. 1. - |
| fn |
- 846 See BATS Letter, p. 4. See also FIA Letter, p. 1; FIF Letter II, p. 2. - |
| fn |
- 847 See Nasdaq Letter I, p. 11. The Commission notes that this comment letter was submitted prior to the adoption of the Large Trader Reporting Rule. See note 1, supra, and accompanying text. - |
| fn |
- 848 To further facilitate this review, the Commission expects that the plan sponsors would keep minutes of their meetings to formulate the NMS plan, and that such minutes would be readily reviewable by the Commission. - |
| fn |
- 849 17 CFR 242.608(b)(2). To approve such a plan, the Commission must find that such plan or amendment is necessary or appropriate in the public interest, for the protection of investors and the maintenance of fair and orderly markets, to remove impediments to, and perfect the mechanisms of, a national market system, or otherwise in furtherance of the purposes of the Act. - |
| fn |
- 850 See Rules 613(a)(1)(v), (b)(6), (d)(2). See also Sections III.B. and III.C.2.a.i., supra (discussing the consideration of flexibility and scalability of the systems used by the central repository; the requirement that the NMS plan require the plan sponsors to provide a written assessment with an evaluation of, and a detailed plan to improve, the performance of the consolidated audit trail at least every two years; and the requirement to annually evaluate the clock synchronization and time stamp standards). - |
| fn |
- 851 17 CFR 242.608(a)(2). For example, if the requirements of the plan are not amended after the annual evaluation of the clock synchronization and time stamp standards to be consistent with changes in the industry standards, the Commission has the authority and means to propose an amendment to those requirements of the plan. The Commission can approve an amendment to an effective national market system plan that was initiated by the Commission, by rule. 17 CFR 242.608(b)(2). - |
| fn |
- 852 See FIF Letter, p. 1, 9; FIF Letter II, p. 1-2; Direct Edge Letter, p. 2-3, 5; Section III.C.1.a., supra. - |
| fn |
- 853 For purposes of these use-cases, an "off-line" analysis is defined to be any analysis performed by a regulator based on data that is extracted from the consolidated audit trail database, but that uses the regulator's own analytical tools, software, and hardware. - |
| fn |
- 854 Fixed search criteria are those that are based on specific pre-defined data elements that are stored in the consolidated audit trail database. In contrast, dynamic search criteria are those that are based on numerical levels, thresholds, or other combinations of mathematical formula or logic that would require some amount of additional calculations to be performed on, and derived from, pre-defined data elements already stored in the database to complete the search operation and return to the user the data that meets the requested criteria. - |
| fn |
- 855 See FIF Letter II, p. 2. See also STA Letter, p. 2 (stating "[t]he SEC should allow six months for the CAT selection process rather than the two months currently identified in the proposed release"). - |
| fn |
- 856 See FIF Letter II, p. 3. - |
| fn |
- 857 See Direct Edge Letter, p. 2-3, 5. See also STA Letter, p. 1-3. - |
| fn |
- 858 These additional provisions relate to: (1) the security and confidentiality of the central repository (see Rule 613(e)(4)(i)(A) through (D) and Section III.B.2.e., supra); (2) error rates (see Rule 613(e)(6) and Section III.B.2.c., supra); (3) an Advisory Committee (see Rule 613(b)(7) and Section III.B.3.b., supra); (4) a retrospective assessment of the performance of the consolidated audit trail, as well as a plan to improve its performance (see Rule 613(b)(6)(i) through (iv) and Section III.B.3.b., supra); and (5) potential penalties (see Rule 613(h)(3) and Section III.B.3.a.1., supra). - |
| fn |
- 859 See Sections III.C.2.a. and c., supra. - |
| fn |
- 860 See Section I., supra. See also Section III.D., infra, for a discussion of the timelines pertaining to the implementation of the consolidated audit trail. - |
| fn |
- 861 See Section I., supra. See also Rule 613(a)(5) (providing, in part, that the Commission "shall consider the impact of the national market system plan, or amendment, as applicable, on efficiency, competition, and capital formation"). - |
| fn |
- 862 See Section I., supra. - |
| fn |
- 863 44 U.S.C. 3501 et. seq. - |
| fn |
- 864 Commission staff estimated that each SRO would expend (400 Attorney hours x $305 per hour) + (100 Compliance Manager hours x $258 per hour) + (220 Programmer Analyst hours x $193 per hour) + (120 Business Analyst hours x $194 per hour) = $213,540 per SRO to prepare and file the NMS plan. Commission staff also estimated that each SRO would outsource, on average, 50 hours of legal work, at an average hourly rate of $400, for a total of $20,000 per SRO, for an aggregate one-time cost to prepare and file an NMS plan of $233,540 per SRO. See Proposing Release, supra note 4, at 32596. The $305 per hour figure for an Attorney; the $258 per hour figure for a Compliance Manager; the $193 per hour figure for a Programmer Analyst; and the $194 per hour figure for a Business Analysis (Intermediate) were from SIFMA's Management & Professional Earnings in the Securities Industry 2008, modified by Commission staff to account for an 1800-hour work-year and multiplied by 5.35 to account for bonuses, firm size, employee benefits, and overhead. Based on industry sources, the Commission estimated that the hourly rate for outsourced legal services in the securities industry is $400 per hour. - |
| fn |
- 865 Commission staff estimated that the SROs would incur an aggregate one-time cost of ($233,540 per SRO) x (15 SROs) = $3,518,100 to prepare and file an NMS plan. - |
| fn |
- 866 See Proposing Release, supra note 4, at note 299. - |
| fn |
- 867 See Rule 613(a)(1)(i) through (xii); Section III.C.2.a., supra. - |
| fn |
- 868 See Rule 613(h)(3); Section III.B.3.a.1., supra. - |
| fn |
- 869 See, e.g., Rule 613(e)(4)(i)(A) through (D). For example, Rule 613(e)(4)(i)(A) requires that the NMS plan require that all plan sponsors and their employees, as well as all employees of the central repository, agree to use appropriate safeguards to ensure the confidentiality of such data and not use such data for purposes other than surveillance or regulatory purposes. Additionally, Rule 613(e)(4)(i)(B) requires the NMS plan to require that each SRO adopt and enforce rules that: (1) require information barriers between regulatory staff and non-regulatory staff with regard to access and use of data in the central repository and (2) permit only persons designated by plan sponsors to have access to the data in the central repository. See Section III.B.2.e., supra. - |
| fn |
- 870 See Rule 613(b)(6)(i) through (iv). See Section III.B.3.b., supra. - |
| fn |
- 871 See Rule 613(e)(6)(i) through (ii). See Section III.B.2.c., supra. See also Rule 613(e)(6)(iii) through (iv). - |
| fn |
- 872 See Rule 613(b)(7). - |
| fn |
- 873 Commission staff now estimates that each SRO would expend 700 Attorney hours, 300 Compliance Manager hours, 880 Programmer Analyst hours, and 880 Business Analyst hours. - |
| fn |
- 874 The $378 per-hour figure for an Attorney; the $279 per hour figure for a Compliance Manager; the $196 per hour figure for a Programmer Analyst; and the $201 per hour figure for a Business Analyst (Intermediate) are from SIFMA's Management & Professional Earnings in the Securities Industry 2011, modified by Commission staff to account for an 1800-hour work-year and multiplied by 5.35 to account for bonuses, firm size, employee benefits, and overhead. At the time the Proposing Release was published, there were 14 national securities exchanges. On August 13, 2010, the Commission granted the application of BATS-Y Exchange for registration as a national securities exchange. See Securities Exchange Act Release No. 62719, 75 FR 51295 (August 19, 2010). Additionally, on April 27, 2012, the Commission granted the application of BOX Options Exchange for registration as a national securities exchange. See Securities Exchange Act Release No. 66871, 77 FR 26323 (May 3, 2012). - |
| fn |
- 875 Commission staff estimates that each SRO would incur an aggregate one-time cost of (700 Attorney hours x $378 per hour) + (300 Compliance Manager hours x $279 per hour) + (880 Programmer Analyst hours x $196 per hour) + (880 Business Analyst hours x $201 per hour) = $697,660 per SRO to prepare and file an NMS plan. In addition, Commission staff estimates that each SRO would incur a one-time external cost of (50 legal hours x $400 per hour) = $20,000. As a result, the Commission staff estimates that the aggregate one-time cost to each SRO to prepare and file an NMS plan, including external costs, would be ($20,000 in external costs) + ($697,660 in aggregate internal costs) = $717,660 per SRO to prepare and file an NMS plan. - |
| fn |
- 876 Commission staff estimates that the SROs would incur an aggregate one-time cost of ($717,660 per SRO) x (17 SROs) = $12,200,200 to prepare and file an NMS plan. - |
| fn |
- 877 See Proposing Release, supra note 4, at 32596. - |
| fn |
- 878 See Section I., supra. - |
| fn |
- 879 See FIF Letter II, p. 2-3. See also STA Letter, p. 2-3. - |
| fn |
- 880 See proposed Rule 613(a)(3)(iii). - |
| fn |
- 881 See proposed Rule 613(a)(3)(v). - |
| fn |
- 882 See Nasdaq Letter I, p. 3. - |
| fn |
- 883 See Bean Letter, p. 1. - |
| fn |
- 886 See Kaufman Letter, Attachment p. 1; Schumer Letter, p. 1. - |
| fn |
- 887 See Schumer Letter, p. 1. - |
| fn |
- 888 See Nasdaq Letter I, p. 7. - |
| fn |
- 889 See FINRA Proposal Letter, p. 5-6; and Wachtel Letter, p. 1. - |
| fn |
- 890 See Rule 613(g)(1). - |
| fn |
- 891 The Commission notes that the SROs could begin drafting the document even before an NMS plan is approved by the Commission. - |
| fn |
- 892 See FINRA Proposal Letter, p. 5-6; Wachtel Letter, p. 1. - |
| fn |
- 893 See Section III.B.1.c., supra. - |
| fn |
- 894 See Rule 613(a)(3)(vi); see also Rule 613(a)(3)(v). - |
| fn |
- 895 17 CFR 240.0-10. - |
| fn |
- 896 17 CFR 240.0-10(c). - |
| fn |
- 897 Pursuant to Rules 613(a)(3)(i) through (vi), the NMS plan must require the SROs to meet the following implementation deadlines: (1) within two months after effectiveness of the national market system plan jointly (or under the governance structure described in the plan) select a person to be the plan processor; (2) within four months after effectiveness of the national market system plan synchronize their business clocks and require members of each such exchange and association to synchronize their business clocks in accordance with Rule 613(d); (3) within one year after effectiveness of the national market system plan provide to the central repository the data specified in Rule 613(c); (4) within fourteen months after effectiveness of the national market system plan implement a new or enhanced surveillance system(s) as required by Rule 613(f); (5) within two years after effectiveness of the NMS plan, require members of each such exchange and association (except those that qualify as small broker-dealers as defined in § 240.0-10(c)) to provide to the central repository the data specified in Rule 613(c); and (6) within three years after effectiveness of the national market system plan require members of each such exchange and association that qualify as small broker-dealers as defined in § 240.0–10(c) to provide to the central repository the data specified in Rule 613(c). -897 Pursuant to Rules 613(a)(3)(i) through (vi), the NMS plan must require the SROs to meet the following implementation deadlines: (1) within two months after effectiveness of the national market system plan jointly (or under the governance structure described in the plan) select a person to be the plan processor; (2) within four months after effectiveness of the national market system plan synchronize their business clocks and require members of each such exchange and association to synchronize their business clocks in accordance with Rule 613(d); (3) within one year after effectiveness of the national market system plan provide to the central repository the data specified in Rule 613(c); (4) within fourteen months after effectiveness of the national market system plan implement a new or enhanced surveillance system(s) as required by Rule 613(f); (5) within two years after effectiveness of the NMS plan, require members of each such exchange and association (except those that qualify as small broker-dealers as defined in § 240.0-10(c)) to provide to the central repository the data specified in Rule 613(c); and (6) within three years after effectiveness of the national market system plan require members of each such exchange and association that qualify as small broker-dealers as defined in § 240.0–10(c) to provide to the central repository the data specified in Rule 613(c). - |
| fn |
- 898 See Section III.C.3., supra. - |
| fn |
- 899 See Rule 613(a)(5) (providing, in part, that the Commission "shall consider the impact of the national market system plan on efficiency, competition, and capital formation"). See also Section I., supra. - |
| fn |
- 900 See Rule 613(a)(1). - |
| fn |
- 901 See Rule 613(c). - |
| fn |
- 902 See Rule 613(a)(1)(i) through (xii). - |
| fn |
- 903 For example, the NMS plan must include provisions: (1) to ensure fair representation of the plan sponsors; (2) for administration of the central repository, including selection of the plan processor; (3) addressing the requirements for admission of new plan sponsors and withdrawal of existing plan sponsors; (4) addressing the percentage of votes required by the plan sponsors to effectuate amendments to the plan; (5) addressing the manner in which the costs of operating the central repository would be allocated among the SROs that are sponsors of the plan, including a provision addressing the manner in which costs would be allocated to new sponsors to the plan; (6) requiring the appointment of a Chief Compliance Officer to regularly review the operation of the central repository to assure its continued effectiveness, and make any appropriate recommendations for enhancements to the nature of the information collected and the manner in which it is processed; and (7) including an enforcement mechanism to ensure that each SRO and member is collecting and providing to the central repository the information required. See Rule 613(b), 613(g)(4), and 613(h)(3). - |
| fn |
- 904 For example, the NMS plan must include a provision requiring the creation and maintenance by the plan processor of a method of access to the data stored in the central repository, that includes the ability to run searches and generate reports. See Rule 613(e)(3). Additionally, the NMS plan is required to include policies and procedures, including standards, to be used by the plan processor to: (1) ensure the security and confidentiality of all information submitted to the central repository; (2) ensure the timeliness, accuracy, integrity and completeness of the data provided to the central repository; (and (3) ensure the accuracy of the consolidation by the plan processor of the data provided to the central repository. See Rule 613(e)(4). The NMS plan also must include a provision requiring the plan sponsors to provide to the Commission, at least every two years after effectiveness of the national market system plan, a written assessment of the operation of the consolidated audit trail. See Rule 613(b)(6). The NMS plan is also required to include an Advisory Committee to advise the plan sponsors on the implementation, operation and administration of the central repository. See Rule 613(b)(7). Further, the NMS plan must specify a maximum error rate to be tolerated by the central repository for the data it collects, and processes for identifying and correcting errors in the data, for notifying the entities responsible for the reporting of the erroneous data, and for disciplining those who repeatedly report erroneous data. See Rule 613(e)(6)(i) through(iv). The NMS plan must also specify as a time by which the corrected data will be available to regulators. See Rule 613(e)(6)(iv). - |
| fn |
- 905 The NMS plan must include: (1) a provision that makes each SRO that sponsors the plan responsible for enforcing compliance by its members with the provisions of the plan; and (2) mechanisms to ensure that plan sponsors and their members comply with the requirements of the plan. See Rules 613(g)(3), 613(g)(4), and 613(h)(3). - |
| fn |
- 906 At the time the Proposing Release was published, there were 14 national securities exchanges. On August 13, 2010, the Commission granted the application of BATS-Y Exchange for registration as a national securities exchange. See Securities Exchange Act Release No. 62719, 75 FR 51295 (August 19, 2010). Additionally, on April 27, 2012, the Commission granted the application of BOX Options Exchange for registration as a national securities exchange. See Securities Exchange Act Release No. 66871, 77 FR 26323 (May 3, 2012). - |
| fn |
- 907 Commission staff estimated that each SRO would spend an aggregate one-time amount of (400 Attorney hours) + (100 Compliance Manager hours) + (220 Programmer Analyst hours) + (120 Business Analyst hours) x (15 SROs) = 12,600 burden hours to prepare and file the NMS plan. - |
| fn |
- 908 Based on industry sources, the Commission estimated that the hourly rate for outsourced legal services in the securities industry is $400 per hour. - |
| fn |
- 909 Commission staff estimated that the SROs would spend ($20,000 per SRO) x (15 SROs) = $300,000 in external costs to develop and draft the NMS plan. - |
| fn |
- 910 See Proposing Release, supra note 4, at 32596. - |
| fn |
- 911 See Rule 613(a)(1)(i) through (xii); Section III.C.2.a., supra. - |
| fn |
- 912 See Rule 613(h)(3); Section III.B.3.a.1., supra. - |
| fn |
- 913 See, e.g., Rule 613(e)(4)(i)(A) through (D). For example, Rule 613(e)(4)(i)(A) requires that the NMS plan require that all plan sponsors and their employees, as well as all employees of the central repository, agree to use appropriate safeguards to ensure the confidentiality of such data and not use such data for purposes other than surveillance or regulatory purposes. Additionally, Rule 613(e)(4)(i)(B) requires the NMS plan to require that each SRO adopt and enforce rules that: (1) require information barriers between regulatory staff and non-regulatory staff with regard to access and use of data in the central repository and (2) permit only persons designated by plan sponsors to have access to the data in the central repository. See Section III.B.2.e., supra. - |
| fn |
- 914 See Rule 613(b)(6)(i) through (iv). See Section III.B.3.b., supra. - |
| fn |
- 915 See Rule 613(e)(6)(i) through (ii). See Section III.B.2.c., supra. See Rule 613(e)(6)(iii) through (iv). - |
| fn |
- 916 See Rule 613(b)(7). - |
| fn |
- 917 See note 906, supra. - |
| fn |
- 918 Commission staff estimates that each SRO would spend an aggregate one-time amount of (700 Attorney hours) + (300 Compliance Manager hours) + (880 Programmer Analyst hours) + (880 Business Analyst hours) = 2,760 burden hours per SRO to prepare and file an NMS plan. In addition, Commission staff estimates that each SRO would incur a onetime external cost of (50 legal hours x $400 per hour) = $20,000. - |
| fn |
- 919 Commission staff estimates that the SROs would incur an aggregate one-time amount of (2,760 burden hours per SRO) x (17 SROs) = 46,920 burden hours to prepare and file an NMS plan. Commission staff estimates that ($20,000 per SRO) x (17 SROs) = $340,000 in external costs to prepare and file the NMS plan. - |
| fn |
- 920 See Proposing Release, supra note 4, at 32596. - |
| fn |
- 921 See Section I., supra. - |
| fn |
- 922 See FIF Letter II, p. 2-3. See also STA Letter, p. 2-3. - |
| fn |
- 923 See Rule 613(e)(4). The Commission believes that an outline or overview description of the policies and procedures, including standards, to be used by the plan processor that would be implemented under the NMS plan submitted to the Commission for its consideration would be sufficient to satisfy the requirement of the Rule. The Commission believes it is important for the NMS plan to establish the fundamental framework of these policies and procedures, but recognizes the utility of allowing the plan sponsors flexibility to subsequently delineate them in greater detail with the ability to make modifications as needed. See Section III.B.2.e., supra. - |
| fn |
- 924 See Rule 613(e)(4)(i)(A) through (D). - |
| fn |
- 925 See Rule 613(e)(4)(i)(A) through (D). - |
| fn |
- 926 See Rule 613(e)(2). - |
| fn |
- 927 See proposed Rule 613(e)(4)(i). - |
| fn |
- 928 17 CFR 240.17a-1. - |
| fn |
- 929 17 CFR 240.17a-4. - |
| fn |
- 930 5 U.S.C. 601 et seq. - |
| fn |
- 931 Although Section 601(6) of the RFA defines the term "small entity," the statute permits agencies to formulate their own definitions. The Commission has adopted definitions for the term "small entity" for the purposes of Commission rulemaking in accordance with the RFA. Those definitions, as relevant to this rulemaking, are set forth in Rule 0-10, 17 CFR 240.0-10. See Securities Exchange Act Release No. 18451 (January 28, 1982), 47 FR 5215 (February 4, 1982) (File No. AS-305). - |
| fn |
- 932 5 U.S.C. 605(b). - |
| fn |
- 933 See Proposing Release, supra note 4, at 32607. - |
| fn |
- 934 Id. - |
| fn |
- 935 See FINRA Proposal Letter, p. 5-6 and Wachtel Letter, p. 1. - |
| fn |
- 936 See Rule 613(a)(3)(vi). - |
| fn |
- 937 Section 604(a)(4) of the RFA. - |
| fn |
- 938 17 CFR 242.601. - |
| fn |
- 939 13 CFR 121.201. - |
jurisdiction: US
- regulatory_authority: Financial Industry Regulatory Authority
+ regulatory_authority: US/SEC
content_type: compilation
- document_title: 6800. CONSOLIDATED AUDIT TRAIL COMPLIANCE RULE
- source: FINRA Rule 6800
- source_type: FINRA Manual
+ document_title: CAT Reporting Technical Specifications for Industry Members
+ document_type: Specifications
+ source: US/SEC/Specifications/Technical Specifications
+ source_type: Technical Specifications
language: English
- pubdate: N/A effdate: N/A
- 6800. CONSOLIDATED AUDIT TRAIL COMPLIANCE RULE
-Topic: FINRA Manual, Rules, 6800
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ citation: N/A
+ pubdate: February 28, 2019 effdate: N/A
+ CAT Reporting Technical Specifications for Industry Members
+Topic: CAT Reporting Technical Specifications for Industry Members
+ Compliance User: Industry Members
Keywords:
- Trading,
- Small industry,
+ Technical Specifications,
- pubdate: N/A effdate: June 30, 2017
- 6810. Definitions
-Topic: FINRA Manual, Rules, 6800, Definition
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ 2/28/2019
+DRAFT Version 1.1
+pubdate: February 28, 2019 effdate: N/A
+ Preface
+Topic: CAT Reporting Technical Specifications for Industry Members, Preface
+ Compliance User: Industry Members
Keywords:
+ CAT NMS plan,
SRO,
- Definition,
- Trading,
+ CAT NMS LLC,
- For purposes of the Rule 6800 Series:
-(a) "Account Effective Date" means:
-(1) with regard to those circumstances in which an Industry Member has established a trading relationship with an institution but has not established an account with that institution:
-(A) when the trading relationship was established prior to November 15, 2018 for Industry Members other than Small Industry Members, or prior to November 15, 2019 for Small Industry Members, either
-(i) the date the relationship identifier was established within the Industry Member;
-(ii) the date when trading began (i.e., the date the first order was received) using the relevant relationship identifier; or
-(iii) if both dates are available, the earlier date will be used to the extent that the dates differ; or
-(B) when the trading relationship was established on or after November 15, 2018 for Industry Members other than Small Industry Members, or on or after November 15, 2019 for Small Industry Members, the date the Industry Member established the relationship identifier, which would be no later than the date the first order was received;
-(2) where an Industry Member changes back office providers or clearing firms prior to November 15, 2018 for Industry Members other than Small Industry Members, or prior to November 15, 2019 for Small Industry Members, the date an account was established at the relevant Industry Member, either directly or via transfer;
-(3) where an Industry Member acquires another Industry Member prior to November 15, 2018 for Industry Members other than Small Industry Members, or prior to November 15, 2019 for Small Industry Members, the date an account was established at the relevant Industry Member, either directly or via transfer;
-(4) where there are multiple dates associated with an account established prior to November 15, 2018 for Industry Members other than Small Industry Members, or prior to November 15, 2019 for Small Industry Members, the earliest available date;
-(5) with regard to Industry Member proprietary accounts established prior to November 15, 2018 for Industry Members other than Small Industry Members, or prior to November 15, 2019 for Small Industry Members:
-(A) the date established for the account in the Industry Member or in a system of the Industry Member or
-(B) the date when proprietary trading began in the account (i.e., the date on which the first orders were submitted from the account).
-With regard to paragraph (a)(2) through paragraph (a)(5), the Account Effective Date will be no later than the date trading occurs at the Industry Member or in the Industry Member's system.
-(b) "Active Accounts" means an account that has had activity in Eligible Securities within the last six months.
-(c) "Allocation Report" means 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 and provides the security that has been allocated, the identifier of the firm reporting the allocation, the price per share of shares allocated, the side of shares allocated, the number of shares allocated to each account, and the time of the allocation; provided, for the avoidance of doubt, any such Allocation Report shall not be required to be linked to particular orders or executions.
-(d) "Business Clock" means a clock used to record the date and time of any Reportable Event required to be reported under this Rule Series.
-(e) "CAT" means the consolidated audit trail contemplated by Rule 613 of SEC Regulation NMS.
-(f) "CAT NMS Plan" means the National Market System Plan Governing the Consolidated Audit Trail, as amended from time to time.
-(g) "CAT-Order-ID" means a unique order identifier or series of unique order identifiers that allows the Central Repository to efficiently and accurately link all Reportable Events for an order, and all orders that result from the aggregation or disaggregation of such order.
-(h) "CAT Reporting Agent" means a Data Submitter that is a third party that enters into an agreement with an Industry Member pursuant to which the CAT Reporting Agent agrees to fulfill such Industry Member's reporting obligations under this Rule Series.
-(i) "Central Repository" means the repository responsible for the receipt, consolidation, and retention of all information reported to the CAT pursuant to Rule 613 of SEC Regulation NMS and the CAT NMS Plan.
-(j) "Compliance Threshold" has the meaning set forth in Rule 6893(d).
-(k) "Customer" means:
-(1) the account holder(s) of the account at an Industry Member originating the order; and
-(2) any person from whom the Industry Member is authorized to accept trading instructions for such account, if different from the account holder(s).
-(l) "Customer Account Information" shall include, but not be limited to, account number, account type, customer type, date account opened, and large trader identifier (if applicable); except, however, that:
-(1) in those circumstances in which an Industry Member has established a trading relationship with an institution but has not established an account with that institution, the Industry Member will:
-(A) provide the Account Effective Date in lieu of the "date account opened";
-(B) provide the relationship identifier in lieu of the "account number"; and
-(C) identify the "account type" as a "relationship";
-(2) in those circumstances in which the relevant account was established prior to November 15, 2018 for Industry Members other than Small Industry Members, or prior to November 15, 2019 for Small Industry Members, and no "date account opened" is available for the account, the Industry Member will provide the Account Effective Date in the following circumstances:
-(A) where an Industry Member changes back office providers or clearing firms and the date account opened is changed to the date the account was opened on the new back office/clearing firm system;
-(B) where an Industry Member acquires another Industry Member and the date account opened is changed to the date the account was opened on the post-merger back office/clearing firm system;
-(C) where there are multiple dates associated with an account in an Industry Member's system, and the parameters of each date are determined by the individual Industry Member; and
-(D) where the relevant account is an Industry Member proprietary account.
-(m) "Customer Identifying Information" means information of sufficient detail to identify a Customer, including, but not limited to:
-(1) 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
-(2) 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, that an Industry Member that has an LEI for a Customer must submit the Customer's LEI in addition to other information of sufficient detail to identify a Customer.
-(n) "Data Submitter" means any person that reports data to the Central Repository, including national securities exchanges, national securities associations, broker-dealers, the SIPs for the CQS, CTA, UTP and Plan for Reporting of Consolidated Options Last Sale Reports and Quotation Information ("OPRA") Plans, and certain other vendors or third parties that may submit data to the Central Repository on behalf of Industry Members.
-(o) "Eligible Security" includes (1) all NMS Securities and (2) all OTC Equity Securities.
-(p) "Error Rate" means the percentage of Reportable Events collected by the Central Repository in which the data reported does not fully and accurately reflect the order event that occurred in the market.
-(q) "Firm Designated ID" means a unique identifier for each trading account designated by Industry Members for purposes of providing data to the Central Repository, where each such identifier is unique among all identifiers from any given Industry Member for each business date.
-(r) "Industry Member" means a member of a national securities exchange or a member of a national securities association that is required to record and report information pursuant to the CAT NMS Plan and this Rule 6800 Series.
-(s) "Industry Member Data" has the meaning set forth in Rule 6830(a)(2).
-(t) "Initial Plan Processor" means the first Plan Processor selected by the Operating Committee in accordance with Rule 613 of SEC Regulation NMS and Section 6.1 of the CAT NMS Plan.
-(u) "Listed Option" or "Option" have the meaning set forth in Rule 600(b)(35) of SEC Regulation NMS.
-(v) "Manual Order Event" means a non-electronic communication of orderrelated information for which Industry Members must record and report the time of the event.
-(w) "Material Terms of the Order" includes: the NMS Security or OTC Equity 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 (except on transactions in equities); 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 (except on market maker quotations); and any special handling instructions.
-(x) "NMS Security" means 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.
-(y) "NMS Stock" means any NMS Security other than an option.
-(z) "Operating Committee" means the governing body of the CAT NMS, LLC designated as such and described in Article IV of the CAT NMS Plan.
-(aa) "Options Market Maker" means a broker-dealer registered with an exchange for the purpose of making markets in options contracts traded on the exchange.
-(bb) "Order" or "order", with respect to Eligible Securities, shall include:
-(1) Any order received by an Industry Member from any person;
-(2) Any order originated by an Industry Member; or
-(3) Any bid or offer.
-(cc) "OTC Equity Security" means 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.
-(dd) "Participant" means each Person identified as such in Exhibit A of the CAT NMS Plan, as amended, in such Person's capacity as a Participant in CAT NMS, LLC.
-(ee) "Person" means any individual, partnership, limited liability company, corporation, joint venture, trust, business trust, cooperative or association and any heirs, executors, administrators, legal representatives, successors and assigns of such Person where the context so permits.
-(ff) "Plan Processor" means the Initial Plan Processor or any other Person selected by the Operating Committee pursuant to Rule 613 of SEC Regulation NMS and Sections 4.3(b)(i) and 6.1 of the CAT NMS Plan to perform the CAT processing functions required by Rule 613 of SEC Regulation NMS and set forth in the CAT NMS Plan.
-(gg) "Received Industry Member Data" has the meaning set forth in Rule 6830(a)(2).
-(hh) "Recorded Industry Member Data" has the meaning set forth in Rule 6830(a)(1).
-(ii) "Reportable Event" includes, but is not limited to, the original receipt or origination, modification, cancellation, routing, execution (in whole or in part) and allocation of an order, and receipt of a routed order.
-(jj) "SRO" means any self-regulatory organization within the meaning of Section 3(a)(26) of the Exchange Act.
-(kk) "SRO-Assigned Market Participant Identifier" means an identifier assigned to an Industry Member by an SRO or an identifier used by a Participant.
-(ll) "Small Industry Member" means an Industry Member that qualifies as a small broker-dealer as defined in SEA Rule 0-10(c).
-(mm) "Trading Day" shall have the meaning as is determined by the Operating Committee. For the avoidance of doubt, the Operating Committee may establish different Trading Days for NMS Stocks (as defined in Rule 600(b)(47) of SEC Regulation NMS), Listed Options, OTC Equity Securities, and any other securities that are included as Eligible Securities from time to time.
-Amended by SR-FINRA-2017-024 eff. June 30, 2017.
-Adopted by SR-FINRA-2017-003 eff. March 15, 2017.
+Rule 613 of the Securities Exchange Act of 1934 requires national securities exchanges and national securities associations (“SROs”) to submit a national market system plan to the Securities and Exchange Commission (“Commission” or “SEC”) to create, implement, and maintain a consolidated audit trail (the “CAT”) that would allow regulators to more efficiently and accurately track all activity in U.S. equity and listed options markets. Pursuant to Rule 613, the SROs filed with the Commission the National Market System Plan Governing the Consolidated Audit Trail (“CAT NMS Plan”), which was approved by the Commission on November 15, 2016.
+Under Rule 613(g)(2), each member of a national securities exchange or national securities association is required to comply with all the provisions of the CAT NMS Plan. Relatedly, as mandated under Rule 613, the CAT NMS Plan requires each SRO to adopt rules requiring its members to comply with Rule 613 and the CAT NMS Plan, and to agree to enforce compliance by its members in that regard. Accordingly, each SRO has adopted rules requiring its members to comply with Rule 613 and the CAT NMS Plan. See, e.g., FINRA Rule 6800 Series.
+The SROs jointly own CAT NMS, LLC, which was formed by the SROs to arrange for and oversee the creation, implementation, and maintenance of the CAT as required under Rule 613. Thus, the CAT is a facility of each SRO.
+This specification represents a phased approach to industry reporting. Key dates are as noted below. Please note that a proposed amendment to the CAT NMS Plan will be filed with the Commission to reflect the phased approach for Industry Member CAT reporting described in these Technical Specifications. The proposed amendment will be subject to the Commission's approval.
+
+ 
pubdate: N/A effdate: March 15, 2017
- 6820. Clock Synchronization
-Topic: FINRA Manual, Rules, 6800, Clock Synchronization
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: February 28, 2019 effdate: N/A
+ Executive Summary
+Topic: CAT Reporting Technical Specifications for Industry Members, Executive Summary
+ Compliance User: Industry Members
Keywords:
- Business Clock,
- Documentation,
- Certification,
- Violation,
+ CAT Industry Member Reporting Scenarios,
- (a) Clock Synchronization
-(1) Each Industry Member shall synchronize its Business Clocks, other than such Business Clocks used solely for Manual Order Events or used solely for the time of allocation on Allocation Reports, at a minimum to within a fifty (50) millisecond tolerance of the time maintained by the atomic clock of the National Institute of Standards and Technology ("NIST"), and maintain such synchronization.
-(2) Each Industry Member shall synchronize (A) its Business Clocks used solely for Manual Order Events and (B) its Business Clocks used solely for the time of allocation on Allocation Reports at a minimum to within a one second tolerance of the time maintained by the NIST atomic clock, and maintain such synchronization.
-(3) The tolerance for paragraph (a)(1) and (2) of this Rule includes all of the following:
-(A) The difference between the NIST atomic clock and the Industry Member's Business Clock;
-(B) The transmission delay from the source; and
-(C) The amount of drift of the Industry Member's Business Clock.
-(4) Business Clocks must be synchronized every business day before market open to ensure that timestamps for Reportable Events are accurate. To maintain clock synchronization, Business Clocks must be checked against the NIST atomic clock and re-synchronized, as necessary, throughout the day.
-(b) Documentation
-Industry Members must document and maintain their synchronization procedures for Business Clocks. Industry Members must keep a log of the times when they synchronize their Business Clocks and the results of the synchronization process. This log should include notice of any time a Business Clock drifts more than the applicable tolerance specified in paragraph (a) of this Rule. Such log must include 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 Rule if less than five years.
-(c) Certification
-Each Industry Member shall certify to FINRA that its Business Clocks satisfy the synchronization requirements set forth in paragraph (a) of this Rule periodically in accordance with the certification schedule established by the Operating Committee pursuant to the CAT NMS Plan.
-(d) Violation Reporting
-Each Industry Member with Business Clocks must report to the Plan Processor and FINRA violations of paragraph (a) of this Rule pursuant to the thresholds set by the Operating Committee pursuant to the CAT NMS Plan.
-Adopted by SR-FINRA-2017-003 eff. March 15, 2017.
+This document describes the requirements for the reporting of data to CAT by Industry Members, including detailed information about data elements and file formats of each Reportable Event. It also describes how Industry Members should submit files to CAT, including access instructions, network and transport options, and testing requirements.
+A separate companion document containing detailed reporting scenarios entitled CAT Industry Member Reporting Scenarios should be used as a guide for determining how the event types and field values laid out in this document should be applied when reporting various order handling and execution scenarios for both equities and options.
+Revision / Change Process
+
+ 
pubdate: N/A effdate: March 15, 2017
- 6830. Industry Member Data Reporting
-Topic: FINRA Manual, Rules, 6800, Industry Member Data Reporting
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Recording,
- Reporting,
- CAT-Order-ID,
- Industry Member Data,
- NMS Security,
- Symbology,
- Error Correction,
-
- (a) Recording and Reporting Industry Member Data
-(1) Subject to paragraph (a)(3) below, each Industry Member shall record and electronically report to the Central Repository the following details for each order and each Reportable Event, as applicable ("Recorded Industry Member Data") in the manner prescribed by the Operating Committee pursuant to the CAT NMS Plan:
-(A) for original receipt or origination of an order:
-(i) Firm Designated ID(s) for each Customer;
-(ii) CAT-Order-ID;
-(iii) SRO-Assigned Market Participant Identifier of the Industry Member receiving or originating the order;
-(iv) date of order receipt or origination;
-(v) time of order receipt or origination (using timestamps pursuant to Rule 6860); and
-(vi) Material Terms of the Order;
-(B) for the routing of an order:
-(i) CAT-Order-ID;
-(ii) date on which the order is routed;
-(iii) time at which the order is routed (using timestamps pursuant to Rule 6860);
-(iv) SRO-Assigned Market Participant Identifier of the Industry Member routing the order;
-(v) SRO-Assigned Market Participant Identifier of the Industry Member or Participant to which the order is being routed;
-(vi) if routed internally at the Industry Member, the identity and nature of the department or desk to which the order is routed; and
-(vii) Material Terms of the Order;
-(C) for the receipt of an order that has been routed, the following information:
-(i) CAT-Order-ID;
-(ii) date on which the order is received;
-(iii) time at which the order is received (using timestamps pursuant to Rule 6860);
-(iv) SRO-Assigned Market Participant Identifier of the Industry Member receiving the order;
-(v) SRO-Assigned Market Participant Identifier of the Industry Member or Participant routing the order; and
-(vi) Material Terms of the Order;
-(D) if the order is modified or cancelled:
-(i) CAT-Order-ID;
-(ii) date the modification or cancellation is received or originated;
-(iii) time at which the modification or cancellation is received or originated (using timestamps pursuant to Rule 6860);
-(iv) price and remaining size of the order, if modified;
-(v) other changes in the Material Terms of the Order, if modified; and
-(vi) whether the modification or cancellation instruction was given by the Customer or was initiated by the Industry Member;
-(E) if the order is executed, in whole or in part:
-(i) CAT-Order-ID;
-(ii) date of execution;
-(iii) time of execution (using timestamps pursuant to Rule 6860);
-(iv) execution capacity (principal, agency or riskless principal);
-(v) execution price and size;
-(vi) SRO-Assigned Market Participant Identifier of the Industry Member executing the order;
-(vii) whether the execution was reported pursuant to an effective transaction reporting plan or the Plan for Reporting of Consolidated Options Last Sale Reports and Quotation Information; and
-(F) other information or additional events as may be prescribed pursuant to the CAT NMS Plan.
-(2) Subject to paragraph (a)(3) below, each Industry Member shall record and report to the Central Repository the following, as applicable ("Received Industry Member Data" and collectively with the information referred to in Rule 6830(a)(1) "Industry Member Data")) in the manner prescribed by the Operating Committee pursuant to the CAT NMS Plan:
-(A) if the order is executed, in whole or in part:
-(i) An Allocation Report;
-(ii) SRO-Assigned Market Participant Identifier of the clearing broker or prime broker, if applicable; and
-(iii) CAT-Order-ID of any contra-side order(s);
-(B) if the trade is cancelled, a cancelled trade indicator; and
-(C) for original receipt or origination of an order, the Firm Designated ID for the relevant Customer, and in accordance with Rule 6840, Customer Account Information and Customer Identifying Information for the relevant Customer.
-(3) Each Industry Member that is an Options Market Maker is not required to report to the Central Repository the Industry Member Data regarding the routing, modification or cancellation of its quotes in Listed Options. Each Industry Member that is an Options Market Maker shall report to the Exchange the time at which its quote in a Listed Option is sent to the Exchange (and, if applicable, any subsequent quote modification time and/or cancellation time when such modification or cancellation is originated by the Options Market Maker).
-(b) Timing of Recording and Reporting
-(1) Each Industry Member shall record Recorded Industry Member Data contemporaneously with the applicable Reportable Event.
-(2) Each Industry Member shall report:
-(A) Recorded Industry Member Data to the Central Repository by 8:00 a.m. Eastern Time on the Trading Day following the day the Industry Member records such Recorded Industry Member Data; and
-(B) Received Industry Member Data to the Central Repository by 8:00 a.m. Eastern Time on the Trading Day following the day the Industry Member receives such Received Industry Member Data.
-(3) Industry Members may, but are not required to, voluntarily report Industry Member Data prior to the applicable 8:00 a.m. Eastern Time deadline.
-(c) Applicable Securities
-(1) Each Industry Member shall record and report to the Central Repository the Industry Member Data as set forth in paragraph (a) of this Rule for each NMS Security registered or listed for trading on such exchange or admitted to unlisted trading privileges on such exchange.
-(2) Each Industry Member shall record and report to the Central Repository the Industry Member Data as set forth in this paragraph (a) of this Rule for each Eligible Security for which transaction reports are required to be submitted to FINRA.
-(d) Security Symbology
-(1) For each exchange-listed Eligible Security, each Industry Member shall report Industry Member Data to the Central Repository using the symbology format of the exchange listing the security.
-(2) For each Eligible Security that is not exchange-listed, each Industry Member shall report Industry Member Data to the Central Repository using such symbology format as approved by the Operating Committee pursuant to the CAT NMS Plan.
-(e) Error Correction
-For each Industry Member for which errors in Industry Member Data submitted to the Central Repository have been identified by the Plan Processor or otherwise, such Industry Member shall submit corrected Industry Member Data to the Central Repository by 8:00 a.m. Eastern Time on T+3.
-Adopted by SR-FINRA-2017-003 eff. March 15, 2017.
+pubdate: February 28, 2019 effdate: N/A
+ 1. Introduction
+Topic: CAT Reporting Technical Specifications for Industry Members, Introduction
+ Compliance User: Industry Members
+ Keywords:
+ pubdate: February 28, 2019 effdate: N/A
+ 1.1. CAT Overview
+Topic: CAT Reporting Technical Specifications for Industry Members, Introduction, CAT Overview
+ Compliance User: Industry Members
+ Keywords:
+ Sec Rule 613,
+ CAT NMS plan,
+ CAT Reporting Agents,
+ Securities Information Processors (SIPS),
+
+ The Securities and Exchange Commission (SEC) approved Rule 613 under the Securities Exchange Act of 1934, which requires national securities exchanges and national securities associations (collectively, the Participants) to submit a national market system plan to create, implement, and maintain a consolidated audit trail (CAT NMS Plan) that would capture customer and order event information for orders in NMS Securities and OTC Equity Securities (Eligible Securities), across all markets, from the time of order inception through routing, cancellation, modification, execution, and allocation. The SEC approved the CAT NMS Plan on November 15, 2016.
+In accordance with SEC Rule 613, the CAT NMS Plan requires a Central Repository that will comprehensively track orders throughout their lifecycle and identify the Participants and Industry Members handling them, as well as the account holders and authorized traders for any account that originates an order (Customers1). Specific data elements will be submitted to the Central Repository by Participants, Industry Members, and CAT Reporting Agents. CAT Reporting Agents may be third-party firms reporting on behalf of other entities, or may be outside parties that are not required to submit data to the CAT, but from which the CAT may receive data per the CAT NMS Plan, such as the Securities Information Processors (SIPs).
+The CAT NMS Plan also requires the selection of an entity as the Plan Processor to be responsible for performing the processing functions required by Rule 613 and the Plan. The Operating Committee of CAT NMS LLC, a governing body composed of representatives of the Participants, oversees the operation of the CAT. The duties of the Operating Committee are further described in Article IV of the CAT NMS Plan.
+Refer to SEC Rule 613, available at: https://www.sec.gov/rules/final/2012/34-67457.pdf for more details. Refer also to CAT NMS Plan, available at: https://www.catnmsplan.com/wpcontent/uploads/2018/02/34-79318-exhibit-a.pdf
+pubdate: N/A effdate: March 15, 2017
- 6840. Customer Information Reporting
-Topic: FINRA Manual, Rules, 6800, Customer Information Reporting
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: February 28, 2019 effdate: N/A
+ 2. CAT Reporting Fundamentals
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals
+ Compliance User: Industry Members
Keywords:
- Customer Information,
- Updating,
- Error Correction,
+ Industry Member,
- (a) Initial Set of Customer Information
-Each Industry Member shall submit to the Central Repository the Firm Designated ID, Customer Account Information and Customer Identifying Information for each of its Customers with an Active Account prior to such Industry Member's commencement of reporting to the Central Repository and in accordance with the deadlines set forth in Rule 6880.
-(b) Daily Updates to Customer Information
-Each Industry Member shall submit to the Central Repository any updates, additions or other changes to the Firm Designated ID, Customer Account Information and Customer Identifying Information for each of its Customers with an Active Account on a daily basis.
-(c) Periodic Updates to Complete Set of Customer Information
-On a periodic basis as designated by the Plan Processor and approved by the Operating Committee, each Industry Member shall submit to the Central Repository a complete set of Firm Designated IDs, Customer Account Information and Customer Identifying Information for each of its Customers with an Active Account.
-(d) Error Correction
-For each Industry Member for which errors in Firm Designated ID, Customer Account Information and Customer Identifying Information for each of its Customers with an Active Account submitted to the Central Repository have been identified by the Plan Processor or otherwise, such Industry Member shall submit corrected data to the Central Repository by 5:00 p.m. on T+3.
-Adopted by SR-FINRA-2017-003 eff. March 15, 2017.
+pubdate: February 28, 2019 effdate: N/A
+ 2.1. Industry Member Perspective
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Industry Member Perspective
+ Compliance User: Industry Members
+ Keywords:
+ Industry Member,
+ New Order,
+ Order Accepted,
+
+ Industry Members should populate fields from their own perspective. For example, for “capacity”, the Industry Member should report based on the capacity in which the Industry Member acted. For a New Order and Order Accepted, reports should indicate the instructions as received; for an Order Route, the fields should include the instructions as sent to the destination.
+pubdate: February 28, 2019 effdate: N/A
+ 2.2. Key Data Elements
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Key Data Elements
+ Compliance User: Industry Members
+ Keywords:
+ Elements of CAT,
+
+ The sections below describe the key data elements of CAT that may be used in order events and/or metadata files.
+pubdate: February 28, 2019 effdate: N/A
+ 2.2.1. Reporter ID and Submitter ID
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Key Data Elements, Reporter ID and Submitter ID
+ Compliance User: Industry Members
+ Keywords:
+ Reporter ID,
+ Submitter ID,
+ CAT Reporting Agents,
+
+ Two CAT identifiers, the Reporter ID and the Submitter ID, i.e., CAT Reporting Agent, are used during the CAT file submission process to identify the Industry Member and, if applicable, the party authorized to submit CAT files on behalf of the Industry Member (CAT Reporting Agent).
+Reporter ID
+The CAT Reporter ID is the SRO assigned identifier that an Industry Member used to report order events to CAT. A CAT Reporter may use any SRO assigned identifier that is valid on the CAT Trading Day for which order events are submitted. CAT will use reference data submitted by Participant Reporters each day to identify the Industry Member to which the specific identifier is assigned. Each SRO assigned identifier is linked to the Industry Member's CRD number so that all reporting activity of a single Industry Member CAT reporter can be consolidated at the firm level in CAT.
+Submitter ID
+The Submitter ID is the identifier of the CAT Reporting Agent, the entity authorized to submit the files to CAT on behalf of the Industry Member. CAT Reporters may authorize third-parties (“CAT Reporting Agents”) to submit data to CAT on their behalf. The CAT Reporting Agent must be authorized to submit data on behalf of the Reporter. Each CAT Reporting Agent will be assigned a unique Submitter ID by CAT during onboarding. If an Industry Member submits data on its own behalf, then the Submitter ID assigned to the entity may be the same as the CAT Reporter ID.
+pubdate: February 28, 2019 effdate: N/A
+ 2.2.2. Order ID
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Key Data Elements, Order ID
+ Compliance User: Industry Members
+ Keywords:
+ Order ID,
+
+ The order ID used in order events, representing the internal order IDs assigned by the Industry Member, must be unique when combined with the date, reporter and symbol (or optionID).
+pubdate: February 28, 2019 effdate: N/A
+ 2.2.3. Timestamps
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Key Data Elements, Timestamps
+ Compliance User: Industry Members
+ Keywords:
+ Manual Order Events,
+ Industry Members,
+ Alternative Trading systems,
+ Member Data,
+
+ Each Industry Member must record and report Industry Member Data to the CAT with timestamps in milliseconds. However, to the extent that any Industry Member’s order handling or execution systems utilize timestamps in increments finer than milliseconds, such Industry Member must record and report Industry Member Data to the CAT with timestamps in such finer increments. CAT will accept granularity up to nanoseconds. Each Industry Member may record and report Manual Order Events to the CAT in increments up to and including one second, provided that each Industry Member shall record and report the time when a Manual Order Event has been captured electronically in an order handling and execution system of such Industry Member (“Electronic Capture Time”) in milliseconds. Each Industry Member may record and report the time of Allocation Reports in increments up to and including one second.
+There are two timestamps fields in each event - eventTimestamp and electronicTimestamp. The eventTimestamp is the time of order handling or execution pursuant to Section 6.8 of the CAT NMS Plan (e.g. origination, receipt, etc, depending on the respective order event). For manual order handling, eventTimestamp is the manual handling or execution time, which is required to be reported in increments of at least one second. When the manual order is later captured electronically, the systematized time must be captured in the electronicTimestamp field.
+With respect to sequence numbers, Alternative Trading Systems (ATSs) must provide a sequence number assigned by the ATS’s matching engine on all Reportable Events.
+pubdate: February 28, 2019 effdate: N/A
+ 2.2.4. Order Types
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Key Data Elements, Order Types
+ Compliance User: Industry Members
+ Keywords:
+ Data Dictionary,
+
+ CAT uses a standardized list of order types for Industry Members that can be found in the Data Dictionary. All events with the field orderType will require one of these standard order types as a value.
+For events reported by ATSs, an additional field (in addition to orderType) - atsOrderType - is used to capture ATS-specific order types. Please see Section 3.1.2 ATS Order Types for more details.
+Please note that brokers routing to ATSs are not required to use the atsOrderType field, nor the ATS specific codes in the standardized orderType field in their Order Route events. The orderType on the Order Route event will not be validated against an atsOrderType.
+pubdate: February 28, 2019 effdate: N/A
+ 2.2.5. Order Handling Instructions
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Key Data Elements, Order Handling Instructions
+ Compliance User: Industry Members
+ Keywords:
+ RAR,
+ New Order,
+ Order Accepted,
+
+ Special handling instructions are reported in the handlingInstructions field using a standardized list of handling instructions based on common exchange order types and codes. Multiple codes and values can be used in combination to describe the special handling instructions.
+In the event an Industry Member routes an order with exactly the same handling instructions received from the customer, they may use handlingInstructions code "RAR" (Routed as Received) on the Order Route event rather than re-stating all handlingInstructions values from the New Order/Order Accepted event.
+pubdate: February 28, 2019 effdate: N/A
+ 2.3. Reference Data
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data
+ Compliance User: Industry Members
+ Keywords:
+ IMID,
+
+ pubdate: February 28, 2019 effdate: N/A
+ 2.3.1. Industry Member Identifier (IMID)
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data, Industry Member Identifier (IMID)
+ Compliance User: Industry Members
+ Keywords:
+ Industry Member Identifier,
+ CHX Acronyms,
+ FINRA,
+ MPIDs,
+ Nasdaq MPIDs,
+ SRO,
+
+ An Industry Member Identifier, IMID, is any identifier assigned by an SRO to one of its members. Examples of SRO assigned identifiers include FINRA MPIDs, Nasdaq MPIDs, NYSE Mnemonics, CBOE User Acronyms, and CHX Acronyms.
+Reportable events will use fields with the Data Type "IMID" to refer to the Industry Member performing the action described by the event, and/or the entity that is the subject of the action described by the event. In other words, an IMID type field will be used in all scenarios where an Industry Member must refer to themselves or another Industry Member in an event.
+This IMID approach allows the Industry Member to use any SRO-Assigned Industry Member Identifier in the Reportable Events. Acknowledging the potential that the same SRO-assigned Industry Member Identifier may be used by different SRO for different entities, CAT will publish a daily file to highlight any conflict among the SRO-assigned Industry Member Identifiers. Such conflicts are detected in the processing of the daily member dictionaries submitted by each SRO. If a conflict is identified for a specific IMID, the Industry Member may choose to use either the SRO-Assigned Industry Member Identifier by another SRO that is not conflicted with other IDs, or the full format of the IMID - the combination of source (issuing SRO) and the SRO-Assigned Industry Member Identifier - to guarantee uniqueness of the IMID. For example, if AAAA is conflicted with another SRO-Assigned Market Participant Identifier in the CAT, the alternative can be to either use a different SRO-Assigned Market Participant Identifier assigned by another SRO (e.g., AAAB, pointing to the same Industry Member), or the full format FINRA:AAAA - a combination of ID and the source SRO.
+pubdate: February 28, 2019 effdate: N/A
+ 2.3.2. Firm Designated ID (FDID)
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data, Firm Designated ID (FDID)
+ Compliance User: Industry Members
+ Keywords:
+ FDID,
+ CAT NMS plan,
+ CAT Interpretative FAQ,
+
+ FDID is defined in Section 1.1 of the CAT NMS Plan as “a unique identifier for each trading account designated by Industry Members for purposes of providing data to the Central Repository, where each such identifier is unique among all identifiers from any given Industry Member for each business date.”
+FDID represents an account and not a specific customer. For example, John Doe has two accounts at BDA, a regular trading account (account #124) and an IRA account (account #456). BDA would have two different FDIDs in this case, one for John Doe's regular trading account and a second for John Doe's IRA account.
+The FDID for the trading account an order was received or originated for must be reported on all New Order Events.
+Unless a new account or entity identifier is assigned to a client or customer, each FDID must be unique and persistent for each trading account on any given day so that a single account may be tracked across time within a single broker-dealer. For example, if an Industry Member assigns a new account or entity identifier to a client or customer for any reason, such as due to a merger, acquisition or some other corporate action, then a new FDID may be created to identify the new account identifier/entity identifier in use at the Industry Member for the entity
+An actual account may not be used as the FDID for CAT reporting. See CAT Interpretive FAQ M2 for more information on the prohibition on use of actual account numbers.
+pubdate: February 28, 2019 effdate: N/A
+ 2.3.3. Equity Symbols
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data, Equity Symbols
+ Compliance User: Industry Members
+ Keywords:
+ Reportable Events,
+ Eligible Securities,
+ FINRA OTC Symbology,
+
+ Industry Members must report Reportable Events related to listed equity Eligible Securities to CAT using the symbology of the primary listing exchange and must report Reportable Events related to OTC Equity Securities using FINRA OTC symbology.
+pubdate: February 28, 2019 effdate: N/A
+ 2.3.3.1. CAT Symbol Master
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data, Equity Symbols, CAT Symbol Master
+ Compliance User: Industry Members
+ Keywords:
+ Symbol,
+
+ CAT will provide a start-of-day equity symbol master list at 6:00AM and an end-of-day equity symbol master list each day on www.catnmsplan.com.
+The symbol master file for Industry Members contains the following information:
+• the listing exchange,
+• the symbol in the symbology of the listing exchange, and
+• a flag indicating whether the symbol is a test symbol.
+pubdate: February 28, 2019 effdate: N/A
+ 2.3.4. Option Symbols
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data, Option Symbols
+ Compliance User: Industry Members
+ Keywords:
+ CAT NMS plan,
+ CAT Symbology,
+
+ As stated above, the CAT NMS Plan requires symbols to be reported to CAT in the symbology of the listing exchange. Standard option symbols established across exchanges as the result of the Option Symbology Initiative (OSI) should be used for any single-leg listed options.
+pubdate: February 28, 2019 effdate: N/A
+ 2.3.4.1. Flex Percent Option Symbols
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data, Option Symbols, Flex Percent Option Symbols
+ Compliance User: Industry Members
+ Keywords:
+ Flex Percent Options,
+ CAT System,
+
+ FLEX Percent options can only be uniquely identified using the OSI once their deterministic prices are known. When reporting the optionID for a FLEX Percent option, Industry Members must append "%" to the beginning of the standard OSI symbol. This will enable the CAT system to differentiate between a strike value that is expressed in percent terms from one that is expressed in dollars and cents.
+Thus, FLEX Percent option symbols expressed with percentage strike values will have 22 characters. For example, an option order with optionID %1AAPL 200131C00095000 indicates it is a Flex Percent option order on OSI symbol 1AAPL 200131C00095000.
+pubdate: February 28, 2019 effdate: N/A
+ 2.3.5. Corporate Actions
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data, Corporate Actions
+ Compliance User: Industry Members
+ Keywords:
+ Central Repository,
+ FINRA OTC Equity Symbols,
+ Data Distribution Service,
+ Industry Members,
+
+ The CAT System will maintain a historical symbology in the Central Repository that includes corporate actions.
+CAT will receive daily corporate action files and symbol updates from the various data sources (including equity and options listing exchanges, FINRA OTC Equity Symbols, Data Distribution Services from Options Clearing Corporation, etc.) and publish daily symbol master files to the Industry Members. The symbol changes impacted by corporate actions will be reflected in the daily symbol master files. Industry Members must use the updated symbol in Reportable Events from the effective date of the symbol change. Failure to report in the updated symbol would result in rejects of the record(s).
+Industry Members are not required to report order adjustments due to corporate actions, e.g., price or size changes. However, if an Industry Member chooses to report an adjustment resulting from a corporate action, the adjustment should be reported using the Order Modified event (or Order Adjusted event).
+pubdate: February 28, 2019 effdate: N/A
+ 2.3.5.1. Options Intraday Listing or Delisting
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data, Corporate Actions, Options Intraday Listing or Delisting
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ Industry Members,
+
+ CAT accommodates intraday listing of options by exchanges. Industry Members must report the OSI symbol as the optionID, just like for previously listed options.
+CAT will maintain a historical record of option symbols, including symbols that have been delisted.
+Exchanges and the OCC will provide reference data to CAT for option symbols that are listed or delisted intraday.
+pubdate: February 28, 2019 effdate: N/A
+ 2.4. Data Types
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Data Types
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ Data Validation,
+ Reporter Submitter,
+ Data Submitted,
+ Industry Members,
+ JSON,
+ CSV,
+ SRO,
+
+ CAT will accept two kinds of text-based files: JSON and CSV. The fundamental data types used throughout this document are described below. Other data types are defined in the Data Dictionary provided in Appendix G of this document.
+To support both JSON and CSV submissions, CAT will publish a JSON schema file on the CAT public website that describes each data type with required representation formats and a mapping that defines the position in a CSV representation that the data element would assume. A schema will be provided for each data object that can be reported in both JSON and CSV.
+Data Validation Based on Data Types
+All data submitted to CAT will be validated based on the defined data type of each item, including proper formatting and range checking. Examples of accepted values are detailed in the table below. Valid values for Choice fields are defined in the Data Dictionary for each data element. Valid data values, ranges, and formats will be specified in the record schema files, which will be used to validate submitted data element values. Records and values that fail validation will be marked as a failure and will be reported as feedback to the Reporter and Data Submitter as detailed in Section 7.
+Data Types
+
+ 
+ 
+ 
+ 
+ pubdate: February 28, 2019 effdate: N/A
+ 2.4.1. Name/Value Pairs
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Data Types, Name/Value Pairs
+ Compliance User: Industry Members
+ Keywords:
+ Name Part,
+ Value Part,
+ JSON,
+ CSV,
+
+ Some fields are described as containing Name/Value pairs. This signifies a list of zero or more attributes, where each attribute is either a name with no value, or a name with an accompanying value such that the name and value are separated by a single equal sign (ASCII decimal 61, hex 3D). Multiple attributes, i.e., Name/Value Pairs, are separated by the pipe symbol (ASCII decimal 124, hex 7C). If an attribute is boolean in nature, it can optionally be represented as a name alone, where its value is implied by its presence (true) or absence (false).
+The Name part is the string up to the first pipe symbol or equal sign. Names must not contain commas (ASCII 44, hex 2C), pipes, equal-signs, or double-quotes (ASCII decimal 34, hex 22). If the name terminates with a pipe, it is a boolean value, and its presence indicates true. If the name terminates with an equal sign, the value must follow.
+The Value part is the string starting with the character just after the equal sign, up to either a pipe symbol or the end of the string. Values may contain an equal sign, but must not contain commas, pipes or double-quotes.
+For example, the following JSON represents a hypothetical name/value pair field, with a boolean attribute and a price attribute: { "data": "XYZ|ABC=12.55" }
+The above format works for both JSON and CSV data entry. However, when submitting data in JSON, a more native JSON style can optionally be used by assigning a JSON object as the value for a Name Value Pair attribute. Note, however, that boolean values must be explicitly set. The above example can alternatively be submitted as:
+{ "data": { "XYZ": true, "ABC": 12.55 } }
+pubdate: February 28, 2019 effdate: N/A
+ 2.4.2. Required, Conditional, and Optional Fields
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Data Types, Required, Conditional, and Optional Fields
+ Compliance User: Industry Members
+ Keywords:
+ Throughout this document, event types and their fields will be defined. Each field will be notated with the abbreviation R, C, O or A to represent whether it is required, conditionally required, optional or required for ATSs only. This codification will appear in the last column of each table describing an event.
+
+ pubdate: February 28, 2019 effdate: N/A
+ 2.5. Linkage Overview
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Linkage Overview
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+
+ This section describes the linkage keys that are used to create lifecycles in CAT and explains how the linkage keys are constructed via different data elements in respective Reportable Events.
+pubdate: February 28, 2019 effdate: N/A
+ 2.5.1. CAT Linkage Keys
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Linkage Overview, CAT Linkage Keys
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ Industry Members,
+
+ All Reportable Events will be linked in CAT via the daisy chain approach. Below is the list of linkage keys that connect order events within an Industry Member and across Industry Members.
+• Order Key links together the events of the same order, within an Industry Member, e.g. linking an Order Route event to the Order Accepted event. The Order Key is constructed by date, reporter, symbol (or optionID) and orderID.
+• Prior Order Key links together the modified, cancel/replaced or internally routed order to the original order. For example, linking an Order Modified event to the Order Accepted event. Generally, the data elements to construct the Prior Order Key are date, reporter, symbol (or optionID), priorOrderID. However, the field names may vary depending on the order events. Please see each order events sections for more details.
+• Route Linkage Key links the order events by the Industry Member routing an order away and the Industry Member accepting the order. Please see Section 2.5.2 below for more detailed descriptions.
+• Trade Key: Each Trade event has a Trade Key (date, reporter, symbol (or optionID), tradeID), and each side of the trade has an Order Key that links to the order on side.
+• Fulfillment Key: date, reporter, symbol (or optionID), fulfillmentID
+• Prior Fulfillment Key: date, reporter, symbol (or optionID), priorFulfillmentID
+• Quote Key: date, reporter, symbol, quoteID
+Generally, the date used in the linkage key is the calendar date of the event (the date portion of the eventTimestamp). In the scenario when an order event needs to be linked to a prior event on a different date (e.g., modify a GTC order on a prior day), an additional field priorOrderDate is reported on the event and will be used in linking.
+pubdate: February 28, 2019 effdate: N/A
+ 2.5.2. Reporting Responsibilities of Sender/Receiver in Order Route
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Linkage Overview, Reporting Responsibilities of Sender/Receiver in Order Route
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ Industry Members,
+ OATS,
+
+ In Phase 2a, Industry Members are responsible for reporting routes, modifications, and cancellations in line with OATS guidance. Below are a list of sample scenarios and the reporting responsibilities of the sender (Broker A) and the receiver (Broker B).
+
+ 
+ pubdate: February 28, 2019 effdate: N/A
+ 2.5.3. Summary of Route Linkage Keys
+Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Linkage Overview, Summary of Route Linkage Keys
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ Industry Members,
+
+ The table below summarizes the required data elements to construct the route key for linking Route and Order Accepted events reported by different entities in CAT. The combination of the data elements must be unique. Data elements in the same row must always be equal values. Note that only the data elements used to create linkage are listed here.
+For Participant related event details, please refer to the CAT Reporting Technical Specifications for Participants.
+
+ 
+ * Not required for manual order route/receipt.
+• session - The session field contains an ID string for the specific session used to route the order. Note that this differs from the trading session (e.g., pre-market, regular, post-market, etc.) Session can constitute an actual protocol session name, IP/port combination, unique login account, or some other means of identifying a particular API session. It must be reported as the same value by both the sending and receiving entities. When routing between two Industry Members, the session must be left blank by both the sending and receiving entities.
+• routedOrderID - When an order is routed away, it may be assigned another ID on the route - this is noted in the Order Route event as the routedOrderID (e.g., the ClOrdID in FIX, ClientOrderID for NYSE UTP direct users, etc). This ID must match the routedOrderID reported by the receiving entity in its Order Accepted event.
+Routing Between Industry Members
+For orders routed between Industry Members, the linkage between sender and receiver is established via a combination of:
+- Date, symbol (or optionID), session (must be blank), destination, senderIMID, and routedOrderID on the Order Route events reported by the sender; and
+- Date, symbol (or optionID), session (must be blank), receiverIMID, routingOrigin, and routedOrderID on Order Accepted event reporter by the receiver.
+• destination - The IMID of the destination receiving this routed order. It must equal the receiverIMID field on the Order Accepted event reported by the destination Industry Member. The sending and receiving firms must mutually agree on the IMID to be used if they have multiple SRO-assigned IMIDs.
+• senderIMID - The IMID of the sender that is routing out the order, known also by the destination. The destination has to report the same value on the routingOrigin field of the Order Accepted event.
+• receiverIMID - The IMID of the Industry Member receiving the routed order. It must match the destination field on the Order Route event reported by the sender.
+• routingOrigin - The IMID of the Industry Member from which the order is routed. It must match senderIMIDin the Order Route event reported by the routing entity.
+Routing to Exchanges
+When routing to exchanges, the destination must be the Exchange ID to which the order is routed. Hence, the linkage will be created by:
+- Date, symbol (or optionID), session, destination (ExchangeID), senderIMID, and routedOrderID on the Order Route event; and
+- Date, symbol (or optionID), session, exchange, routingParty, and routedOrderID on the Participant Order Accepted event to create linkages. See CAT Reporting Technical Specifications for Participants for more details.
+Note that, when using Order Route event to report a modification to an order that was previously routed to an exchange, the linkage key is created via the same set of data elements.2
+Routing to Foreign Destinations
+If the order is routed to a foreign non-CAT-reporting entity, the destinationType must be marked as N (Foreign). However, there is no requirement to report destination or routedOrderID, thus there is no subsequent linkage in CAT.
+Routing from an Exchange to the Exchange's Routing Broker
+When an Industry Member, that is an exchange routing broker, receives an order routed from the exchange, the routingOrigin field must be the Exchange ID from which the order is routed. Hence the linkage will be created by:
+- Date, symbol (or optionID), exchange, routedOrderID, session, routingParty on the Participant Order Route event (See CAT Reporting Technical Specifications for Participants for more details);
+- Date, symbol (or optionID), routingOrigin (Exchange ID), routedOrderID, session, receiverIMID on the Industry Member Order Accepted event.
+pubdate: N/A effdate: March 15, 2017
- 6850. Industry Member Information Reporting
-Topic: FINRA Manual, Rules, 6800, Industry Member Information Reporting
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Reporting,
-
- Each Industry Member shall submit to the Central Repository information sufficient to identify such Industry Member, including CRD number and LEI, if such LEI has been obtained, prior to such Industry Member's commencement of reporting to the Central Repository and in accordance with the deadlines set forth in Rule 6880, and keep such information up to date as necessary.
-Adopted by SR-FINRA-2017-003 eff. March 15, 2017.
-pubdate: N/A effdate: March 15, 2017
- 6860. Time Stamps
-Topic: FINRA Manual, Rules, 6800, Time Stamps
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
- Keywords:
- Record,
- Report,
- Time Stamps,
-
- (a) Millisecond Time Stamps
-(1) Subject to paragraphs (a)(2) and (b), each Industry Member shall record and report Industry Member Data to the Central Repository with time stamps in milliseconds.
-(2) Subject to paragraph (b), to the extent that any Industry Member's order handling or execution systems utilize time stamps in increments finer than milliseconds, such Industry Member shall record and report Industry Member Data to the Central Repository with time stamps in such finer increment.
-(b) One Second Time Stamps/Electronic Order Capture
-(1) Each Industry Member may record and report Manual Order Events to the Central Repository in increments up to and including one second, provided that each Industry Member shall record and report the time when a Manual Order Event has been captured electronically in an order handling and execution system of such Industry Member ("Electronic Capture Time") in milliseconds; and
-(2) Each Industry Member may record and report the time of Allocation Reports in increments up to and including one second.
-Adopted by SR-FINRA-2017-003 eff. March 15, 2017.
+pubdate: February 28, 2019 effdate: N/A
+ 3. Special Reporting Requirements
+Topic: CAT Reporting Technical Specifications for Industry Members, Special Reporting Requirements
+ Compliance User: Industry Members
+ Keywords:
+ pubdate: February 28, 2019 effdate: N/A
+ 3.1. Alternative Trading Systems (“ATSs”) Reporting
+Topic: CAT Reporting Technical Specifications for Industry Members, Special Reporting Requirements, Alternative Trading Systems (“ATSs”) Reporting
+ Compliance User: Industry Members
+ Keywords:
+ ATSs,
+
+ ATSs are required to submit additional information in applicable order events.
+pubdate: February 28, 2019 effdate: N/A
+ 3.1.1. National Best Bid and Offer (NBBO)
+Topic: CAT Reporting Technical Specifications for Industry Members, Special Reporting Requirements, Alternative Trading Systems (“ATSs”) Reporting, National Best Bid and Offer (NBBO)
+ Compliance User: Industry Members
+ Keywords:
+ ATSs,
+ Industry Members,
+ CAT,
+ NBBO,
+ BBO,
+
+ ATSs are required to report to CAT NBBO prices, though such information is optional for other Industry Members. The quantities being bid or offered for the NBBO are optional for all Industry Members.
+The NBBO should be reported to CAT from the perspective of the Industry Member. An ATS is required to report, for orders, the NBBO (or relevant reference price) in effect at the time of the order event, and the timestamp of when the ATS captured the effective NBBO (or relevant reference price). In addition, the ATS must identify the market data feed (NBBO Source) it used to obtain the NBBO (or relevant reference price).
+If another reference price, such as the primary market's BBO, is used by the ATS, then the applicable reference price should be reported instead of the NBBO.
+pubdate: February 28, 2019 effdate: N/A
+ 3.1.2. ATS Order Types
+Topic: CAT Reporting Technical Specifications for Industry Members, Special Reporting Requirements, Alternative Trading Systems (“ATSs”) Reporting, ATS Order Types
+ Compliance User: Industry Members
+ Keywords:
+ ATSs,
+ CAT,
+
+ For events reported by ATSs, an additional field (in addition to orderType) - atsOrderType - is used to report ATS-specific order types. Note that orderType and atsOrderType are not mutually exclusive; ATSs must populate both of these fields with a value where they are present on Reportable Events.
+The field atsOrderType is defined as Name/Value Pairs where "name" must be equal to a unique code that has been provided to CAT by the ATS through the CAT web interface. All codes must be registered before any relevant order events are submitted. Specific instructions for registering atsOrderTypes will be published in a CAT Alert available on catnmsplan.com. All atsOrderTypes must be registered with CAT 20 business days prior to the order type becoming effective.
+pubdate: February 28, 2019 effdate: N/A
+ 3.1.3. Sequence Number
+Topic: CAT Reporting Technical Specifications for Industry Members, Special Reporting Requirements, Alternative Trading Systems (“ATSs”) Reporting, Sequence Number
+ Compliance User: Industry Members
+ Keywords:
+ ATSs,
+
+ Alternative Trading Systems (ATSs) must also provide a sequence number assigned by the ATS’s matching engine on all reportable events.
+pubdate: February 28, 2019 effdate: N/A
+ 3.2. Manual Orders
+Topic: CAT Reporting Technical Specifications for Industry Members, Special Reporting Requirements, Manual Orders
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ NMS Plan,
+
+ The CAT NMS Plan defines a Manual Order Event as “non-electronic communication of order-related information for which CAT Reporters must record and report the time of the event.” This version of the Technical Specifications addresses manual equity orders, which are reportable in Phase 2a, while manual option orders will be addressed in the Phase 2d Technical Specifications.
+pubdate: February 28, 2019 effdate: N/A
+ 3.2.1. Manually Received Order Events Immediately Systematized
+Topic: CAT Reporting Technical Specifications for Industry Members, Special Reporting Requirements, Manual Orders, Manually Received Order Events Immediately Systematized
+ Compliance User: Industry Members
+ Keywords:
+ Industry Members,
+
+ Orders which are non-electronically communicated but immediately systematized (e.g., a broker received a call and directly enters the order into the order management system) must be marked as a manual event using the manualFlag. In this scenario, 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.3
+pubdate: February 28, 2019 effdate: N/A
+ 3.2.2. Manual Order Events Followed by Separate Electronic Messages
+Topic: CAT Reporting Technical Specifications for Industry Members, Special Reporting Requirements, Manual Orders, Manual Order Events Followed by Separate Electronic Messages
+ Compliance User: Industry Members
+ Keywords:
+ Manual order event,
+ CAT,
+ Industry Members,
+
+ Manual order events must be reported to CAT marked as a manual event using the manualFlag and must include an electronic capture time if the manual event is captured in an order management or execution system.
+If an Industry Member routes or receives an order manually and then subsequently sends or receives an electronic message to represent the manual instruction, the following reporting requirements apply:
+• All material terms and conditions of a manually received or routed order, including time of route and receipt, must be reported to CAT on the required manual event, with all relevant timestamps representing when the manual order event occurred.
+• Additional electronic messages related to a manual order or route that do not change any material term or condition of the original order are not required to be reported to CAT as they represent a duplicate of the original order.
+• If the duplicate electronic message includes a routed order identifier that could be used to link the sender's route report to the receiver's new order, and the member has the ability to include this electronic information on the manual event (referred to as a "merged" event), the Industry Member should do so.
+• If the Industry Member is not able to merge the manual and electronic information in a single manual event and elects to report the duplicate electronic message independently, such messages must be reported with the electronicDupFlag = true. Further, the manualOrderID may be populated with the Order ID of the original manual order. This is optional in Phase 2a, but will be mandatory in Phase 2c.
+No linkage will be attempted for electronic duplicate events in Phase 2a.
+pubdate: N/A effdate: March 15, 2017
- 6865. Time Stamp and Clock Synchronization Rule Violations
-Topic: FINRA Manual, Rules, 6800, Time Stamps and Clock Synchronization Rule Violations
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: February 28, 2019 effdate: N/A
+ 4. Equity Events
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events
+ Compliance User: Industry Members
Keywords:
- Reporting,
- Business Clocks,
- Violation,
+ Equity Events,
+ SROs,
+ Industry Members,
+ ATS,
+ Agency Order Crosses,
- An Industry Member that engages in a pattern or practice of reporting Reportable Events with time stamps generated by Business Clocks that are not synchronized according the requirements set forth in this Rule Series without reasonable justification or exceptional circumstances may be considered in violation of this Rule.
-Adopted by SR-FINRA-2017-003 eff. March 15, 2017.
+This section describes Reportable Events for equities that are Eligible Securities. The following table lists each equity event type with its corresponding Message Type code.
+Events and data elements that are greyed out do not apply to Phase 2a.
+Equity Events
+
+ 
+ pubdate: February 28, 2019 effdate: N/A
+ 4.1. New Order Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, New Order Event
+ Compliance User: Industry Members
+ Keywords:
+ Industry Members,
+ CAT,
+ New customer orders,
+ Representative orders,
+ Proprietary orders,
+ non-reporting foreign broker-dealer,
+ ATS,
+
+ An Industry Member must report a New Order event to CAT when an order is received or originated. This includes:
+• New customer orders4
+• Representative orders5
+• Proprietary orders
+• Order(s) received from a non-reporting foreign broker-dealer or affiliate.
+Note that an order received from another CAT Reporter (US broker-dealer, ATS or an exchange) must be reported as an Order Accepted event.
+Phase 2a Representative Orders
+In Phase 2a, linkage is required between the representative street-side order and the customer order or client order being represented when the representative order was originated specifically to represent a single order and there is:
+• An existing direct electronic link in the Industry Member’s system between the order being represented and the representative order, and
+• Any resulting executions are immediately and automatically applied to the represented order in the Industry Member’s system.
+Phase 2c Representative Orders
+Any scenario that does not meet the definition of Phase 2a representative order will fall into this category. The Industry Member must report a New Order event for the creation of the representative order in Phase 2a and flag the New Order event properly to indicate that it is a representative order. It is not mandatory to report the linkage to the underlying orders (the aggregatedOrders field) until Phase 2c.
+Appendix C contains detailed descriptions of representative order scenarios and illustrates when marking of the representative order, linkage between the represented order and the representative order, and Order Fulfillment linkage is required in each phase.
+The representativeInd is used to show whether an order is originated to represent a customer/client order and whether the linkage is present. It is required for all New Order events.
+Note that all fields and values necessary to support Phase 2c linkages are included in this version of the specification and Industry Member Reporters may voluntarily report these linkages prior to the start of Phase 2c.
+New Order Event Field Specifications
+
+ 
+ 
+ Linkage keys for this Reportable Event:
+• Order Key: date, reporter, symbol, orderID
+• Quote Key: date, reporter, symbol, quoteID (if applicable)
+• Order Key: date, reporter, symbol, aggregatedOrders.Name
+pubdate: February 28, 2019 effdate: N/A
+ 4.2. New Order Supplemental Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, New Order Supplemental Event
+ Compliance User: Industry Members
+ Keywords:
+ Supplement Event,
+ Name/Value Pairs,
+ CAT,
+
+ The Supplement Event serves as a supplement to the New Order event. This event accommodates reporting in two scenarios:
+1) When the number of Name/Value pairs included under the aggregatedOrders field causes the New Order event to exceed the maximum allowed message length. Generally, this includes scenarios where so many orders are being aggregated together in a New Order that the number of Name/Value Pairs included in the field aggregatedOrders causes the message to exceed the allowed length.
+2) When there is no explicit linkage to disparate orders when a representative order is generated. This supplement event can be used to capture the relationship of representative and disparate orders and submitted to CAT separately as an addition to the original New Order event.
+This event can be submitted in the same file as the original New Order event or in a separate file, so long as it is submitted on the same date as the New Order event. One New Order event can have multiple New Order Supplement events. Multiple New Order Supplement events are considered as additions (not replacements or modifications). The aggregatedOrders field in the New Order Supplement event should only contain the additional Name/Value Pairs that have not been captured in the original New Order event (or another Supplement event for the same New Order).
+New Order Supplement Event Field Specifications
+
+ Linkage keys for this Reportable Event:
+• Order Key: date, reporter, symbol, orderID
+• Order Key: date, reporter, symbol, aggregatedOrders.Name
+pubdate: February 28, 2019 effdate: N/A
+ 4.3. Order Route
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Route
+ Compliance User: Industry Members
+ Keywords:
+ Industry Member,
+ foreign broker-dealer,
+ Exchanges,
+ FINRA,
+ SEC Rule 201,
+ ATS,
+
+ An Industry Member must report to CAT an Order Route event when:
+• Routing to another Industry Member
+• Routing to foreign broker-dealers
+• Routing to exchanges
+• Routing between two IMIDs (e.g. two different FINRA MPIDs) attributed to the same legal entity (i.e. the same CRD)
+• Routing partial quantities of an order (assigned using routedOrderID in routing message)
+In order to maintain order lifecycle linkage, the orderID populated in the Order Route event must reflect any changes made to the orderID internally by the broker before routing the order. If, for example, an order was subject to a Cancel/Replace that changed the Order ID, then the value used for orderID in an Order Route event must reflect those changes - in other words, the most recent orderIDis used to reference the order.
+Handling Instructions on the Order Route
+The handling instructions included in this event should represent those on the routed order. If the handling instructions do not change from the Order Accepted or New Order associated with the order, Industry Members may use the handling instruction code "RAR" - routed as received, instead of repeating each individual handling instruction.
+Notes
+• Please note that internal routes to another desk or department within an Industry Member are not reported using the Order Route event; instead an Order Internal Route event is used. See the Order Internal Route section for more details.
+Order Route Event Field Specifications
+
+ 
+ 
+ Linkage keys for this Reportable Event:
+• Order Key: date (from eventTimestamp if priorOrderDate is not present), reporter, symbol, orderID
+• Order Key: priorOrderDate (when present), reporter, symbol, orderID
+• Route Link Key: date, senderIMID, destination, symbol, session, routedOrderID
+pubdate: February 28, 2019 effdate: N/A
+ 4.3.1. Order Modify Route (Potential Phase 2c Event)
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Route, Order Modify Route (Potential Phase 2c Event)
+ Compliance User: Industry Members
+ Keywords:
+ SRO,
+
+ <Deferred – event not required for Phase 2a or Phase 2b. SROs will evaluate need for a modified route event after reviewing Phase 2a/2b data and include event in Phase 2c, if necessary.>
+pubdate: February 28, 2019 effdate: N/A
+ 4.3.2. Order Cancel Route (Potential Phase 2c Event)
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Route, Order Cancel Route (Potential Phase 2c Event)
+ Compliance User: Industry Members
+ Keywords:
+ SRO,
+
+ <Deferred – event not required for Phase 2a or Phase 2b. SROs will evaluate need for a canceled route event after reviewing Phase 2a/2b data and include event in Phase 2c, if necessary.>
+pubdate: February 28, 2019 effdate: N/A
+ 4.4. Order Accepted
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Accepted
+ Compliance User: Industry Members
+ Keywords:
+ CAT Reporter,
+ Industry Member,
+ ATS,
+ CAT,
+ foreign broker-dealer,
+ FINRA,
+ Equity Securities,
+ FINRA Rule 5320.02,
+ NBBO,
+
+ When an Industry Member receives a routed order from another CAT Reporter (i.e., Industry Member, ATS or exchange), then an Order Accepted event must be reported to CAT by the Industry Member receiving the routed order. As described in Order Route event, if an Industry Member accepts a routed order from another IMID belonging to the same Industry Member, i.e., the same CRD, an Order Accepted event must be reported.
+Once all Industry Members are reporting to CAT, in all cases, the order reported with this event should have already been originated by another broker and reported upon origination with a New Order event. A New Order event represents the beginning of the order lifecycle in CAT, therefore a new customer order is represented with a New Order event - not an Order Accepted event. Similarly, orders received by an Industry Member from its non-broker-dealer affiliates or from a non-reporting foreign broker-dealer should be reported as a New Order event - NOT an Order Accepted event. (Note: At the start of Phases 2a and 2b, there will be some lifecycles beginning at Order Accepted event, as small Industry Members will not be required to report until a later phase).
+Order Accepted Field Specifications
+
+ 
+ 
+ Linkage keys for this Reportable Event:
+• Order Key: date, reporter, symbol, orderID
+• Route Link Key: date, senderIMID, destination, symbol, session, routedOrderID
+pubdate: February 28, 2019 effdate: N/A
+ 4.5. Order Internal Route
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Internal Route
+ Compliance User: Industry Members
+ Keywords:
+ Industry Member,
+ Order Accepted Event,
+ New Order event,
+ Child Order event,
+ CAT,
+
+ An Order Internal Route event must be reported when an order is passed to different departments or desks within the reporterIMID.
+Although multiple reporterIMIDs may be attributed to a single Industry Member, routes between different IMIDs attributed to the same Industry Member are not considered internal routes.
+Note that an Order Internal Route event does not follow the logic of sending / receiving two-sided reporting followed throughout the rest of these Industry M ember Technical Specifications. It is required to be reported from the perspective of the recipient desk. The Order Internal Route merely shows that an order was received by an internal destination and if a new orderID has been assigned to the order as a result of this Order Internal Route.
+• Order Internal Route may also represent the routing of partial quantities of an order internally, and the practice of assigning those slices new orderIDs. In this case, multiple internal routes may occur on the same original orderID reported in an Order Accepted event or New Order event. Similarly, if an order is routed internally and then subsequently multiple slices are routed to yet another destination internally, this event should represent the receiving desk, quantities, and new orderIDs of those routed slices as received by the subsequent internal destination. This approach will allow CAT to track changes in orderID within an Industry Member as an order is passed between internal entities or partial quantities are routed to internal entities as slices of another order.
+• The major difference between Order Internal Route and Child Order events is that Child Order event can only be used when no desk change or desk route happens. For example, some Industry Members may choose to first generate child orders using the Child Order event to represent slices of a parent order, then to route those slices internally to another desk (Order Internal Route event). This approach is also acceptable for CAT reporting and will not result in unlinked events.
+Order Internal Route Modified and Order Internal Route Canceled are not required to be reported until Phase 2c.
+pubdate: February 28, 2019 effdate: N/A
+ 4.5.1. Order Internal Route
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Internal Route, Order Internal Route
+ Compliance User: Industry Members
+ Keywords:
+ FINRA,
+ OTC Equity Securities,
+ FINRA Rule 5320.02,
+
+ Order Internal Route event is used to report routing within a reporterIMID as described above.
+Internal Route Field Specifications
+
+ 
+ 
+ Linkage keys for this Reportable Event:
+• Order Key: date, reporter, symbol, orderID
+• Prior Order Key: date, reporter, symbol, priorOrderID
+pubdate: February 28, 2019 effdate: N/A
+ 4.5.2. Order Internal Route Modified (Phase 2c)
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Internal Route, Order Internal Route Modified (Phase 2c)
+ Compliance User: Industry Members
+ Keywords:
+ <Deferred - Not Required Until Phase 2c>
+pubdate: February 28, 2019 effdate: N/A
+ 4.5.3. Order Internal Route Canceled (Phase 2c)
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Internal Route, Order Internal Route Canceled (Phase 2c)
+ Compliance User: Industry Members
+ Keywords:
+ <Deferred - Not Required Until Phase 2c>
+pubdate: February 28, 2019 effdate: N/A
+ 4.6. Child Order
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Child Order
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ Industry Members,
+ Child Order event,
+ FDID,
+
+ CAT provides several ways to report parent/child order activity. The Child Order event is provided solely for the convenience of Industry Members to help model scenarios in which an order is split or sliced into smaller "child" orders that are handled independently of their parent order - in a way that best reflects each individual Industry Member’s system(s).
+For example, in the scenario when Industry Members create independent child orders with new orderIDs, if the Child Order event is reported, then the changes of order IDs are captured. Afterwards, the Industry Member can reference each individual child order in any subsequent event by the new order ID. However, if no Child Order event is reported, then the Industry Member can only reference the order at the parent level by the order ID of the parent. There is no scenario in which the use of Child Order event is mandatory.
+Notes:
+• Child Order event can only be used when an order is sliced and assigned new order IDs within the same desk. An Order Internal Route event must be reported when routed to another desk.
+• There is no limit to how many "generations" can be created through Child Order events. The parentOrderID will be the orderID of the most recent order, whether that was a New Order/Order Accepted or a previous Child Order.
+• Child Orders must belong to the same FDID as the parent orders. Child Orders should not be used to create representative orders. If the FDID changes, a representative New Order event must be used and not a Child Order.
+• Child Orders should not be used for equity legs of a multi-leg option order.
+• This event only includes the key data elements and fields that may be changed from the parent order or that are required for linkage, i.e., certain key data elements from the parent order may not be changed when creating Child Orders.
+pubdate: February 28, 2019 effdate: N/A
+ 4.6.1. Child Order Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Child Order, Child Order Event
+ Compliance User: Industry Members
+ Keywords:
+ FINRA,
+ OTC Equity Securities,
+ NBBO,
+
+ Child Order Event
+
+ 
+ Linakge keys for this Reportable Event:
+• Order Key: date, reporter, symbol, orderID
+• Prior Order Key: date, reporter, symbol, parentOrderID
+pubdate: February 28, 2019 effdate: N/A
+ 4.6.2. Child Order Modified
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Child Order, Child Order Modified
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ FINRA,
+ OTC Equity Securities,
+ Industry Members,
+
+ When the price, quantity or any Material Terms of the child order has been changed, a Child Order Modified event must be reported to CAT. This modification event is only used when the child order creation is reported to CAT in a Child Order event. As such, modifying a partial quantity internal route can not be reported in this event.
+All attributes and Material Terms of the Order of a modified child order listed on this event should be reported when applicable, including the fields that remain unchanged.
+Child Order Modified Event Field Specifications
+
+ 
+ Linkage keys for this Reportable Event:
+• Order Key: date, reporter, symbol, orderID
+• Prior Order Key: date, reporter, symbol, priorOrderID
+pubdate: February 28, 2019 effdate: N/A
+ 4.6.3. Child Order Canceled
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Child Order, Child Order Canceled
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ Industry Members,
+
+ If a child order is canceled, a Child Order Canceled event must be reported to CAT by the Industry Member.
+Note that a partial cancellation can be reported either with a Child Order Modified event or Child Order Canceled event with leavesQty, depending on how it is handled by the Industry Member. If an actual Cancel message was used, the Industry Member should report a Child Order Canceled event to CAT. If a modify or cancel/replace message was used, a Child Order Modified event should be reported to CAT. This keeps the reported event in line with the action taken by the Industry Member.
+Child Order Canceled Event Field Specifications
+
+ Linkage keys for this Reportable Event:
+• Order Key: date, reporter, symbol, orderID
+pubdate: February 28, 2019 effdate: N/A
+ 4.7. Order Modified and Cancel/Replace Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Modified and Cancel/Replace Event
+ Compliance User: Industry Members
+ Keywords:
+ Material Term,
+ NBBO,
+ ATS,
+
+ When the price, quantity or any other Material Term of an order has been changed or when an order is cancel/replaced, an Industry Member must report an Order Modified event to CAT. This Order Modified event concerns both of the following scenarios:
+1) A new order is generated (with a new Order ID) during the modification and completely replaces the prior order. In this case, the orderID field must capture the identifier for the new order. Additionally, the new order must be linked to the prior one through priorOrderID.
+2) If the order ID remains the same during the modification, the priorOrderID must match orderID.
+Note that in the first scenario, if the order has been modified several times, the priorOrderID must refer to the most recent order ID prior to this modification, which may not always be the original order ID.
+Side is required to be reported, but side adjustments are only allowed for same-side changes (e.g., changes between short and long sell).
+All attributes and Material Terms of the modified order listed on this event should be reported when applicable, including the fields that remain unchanged.
+Order Modified and Cancel/Replace Event Field Specifications
+
+ 
+ 
+ 
+ Linkage keys for this Reportable Event:
+• Order Key: date (from eventTimestamp), reporter, symbol, orderID
+• Prior Order Key: date (from eventTimestamp if priorOrderDate is not present), reporter, symbol, priorOrderID
+• Prior Order Key: priorOrderDate (when present), reporter, symbol, priorOrderID
+• Route Link Key: date, symbol, receiverIMID, routingOrigin, session, routedOrderID
+• Quote Key: date, reporter, symbol, quoteID
+pubdate: February 28, 2019 effdate: N/A
+ 4.8. Order Modified (Cancel/Replace) Supplement Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Modified (Cancel/Replace) Supplement Event
+ Compliance User: Industry Members
+ Keywords:
+ Order Modified event,
+
+ The Order Modified Supplement event serves as a supplement to the Order Modified event, just as the Supplement Event serves as a supplement to the New Order event.
+Order Modified Supplement Event Field Specifications
+
+ Linkage keys for this Reportable Event:
+• Order Key: date, reporter, symbol, orderID
+• Order Key: date, reporter, symbol, aggregatedOrders.Name
+pubdate: February 28, 2019 effdate: N/A
+ 4.9. Order Adjusted Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Adjusted Event
+ Compliance User: Industry Members
+ Keywords:
+ Order Modified event,
+ Industry Member,
+ FINRA,
+ OTC Equity Securities,
+ NBBO,
+
+ The Order Modified event requires the full state of the order be reported to CAT for each modify. However, there are some common cases where only the price or quantity are modified. If such changes are initiated by the Industry Member, which can occur frequently, the Order Adjusted event can be used in these situations. However, Order Adjusted events may not be used if a price or quantity change is initiated by a routing Industry Member.
+The only types of modifications that are allowed to be reported with this event are changes to the side, price or quantity of the order.
+• Side adjustments are only allowed for same-side changes (e.g., changes between short and long sell). The side only needs to be reported if it changes.
+• If a price change is reported, then all three price fields (price, displayPrice, and workingPrice) must represent the current state of the order relative to price. The quantity fields can be omitted.
+• Likewise, if a quantity change is reported, then all three quantity fields must represent the current state of the order relative to quantity. The price fields can be omitted.
+When the display price or quantity changes as the result of a display ATS matching engine action and not from a customer instruction, an Order Adjusted event must be used (the Order Modified event cannot be used in this scenario).
+Any modification that cannot be fully represented in this Reportable Event must be reported via the Order Modified event.
+Order Adjusted Event Field Specifications
+
+ 
+ 
+ Linkage keys for this Reportable Event:
+• Order Key: date, reporter, symbol, orderID
+• Prior Order Key: date, reporter, symbol, priorOrderID
+pubdate: February 28, 2019 effdate: N/A
+ 4.10. Order Canceled
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Canceled
+ Compliance User: Industry Members
+ Keywords:
+ Broker,
+ Order Canceled Event,
+ FINRA,
+ OTC Equity Securities,
+
+ The Order Canceled event is used in specific situations when an order is fully or partially canceled. Note:
+• Partial cancellation of an order may be reported to CAT using either an Order Canceled event or an Order Modified event.
+• This Order Canceled Event is only reported by the entity that performs the cancellation. Cancellations by away venues are not required to be reported. For example, if Broker B accepts an order from Broker A, and Broker B initiated a cancel on the order, then B is responsible for reporting the order canceled (not Broker A).
+• Implicit order cancellations are not required to be reported to CAT (e.g., cancellation due to expiration of Time in Force.)
+Order Canceled Event Field Specifications
+
+ Linkage keys for this Reportable Event:
+• Order Key: date (from eventTimestamp if priorOrderDate is not present), reporter, symbol, orderID
+• Order Key: priorOrderDate (when present), reporter, symbol, orderID
+pubdate: February 28, 2019 effdate: N/A
+ 4.11. New Quote
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, New Quote
+ Compliance User: Industry Members
+ Keywords:
+ NMS Securities,
+ OTC Equity Securities,
+ Industry Member,
+ NMS Plan,
+ New Quote Event,
+ Quote Modify event,
+ FINRA,
+ Symbol,
+
+ In Phase 2a, the following quotations must be reported:
+• Quotes in NMS Securities sent to an exchange or the ADF
+• Quotes in OTC Equity Securities received by an Industry Member CAT Reporter operating an inter-dealer quotation system.
+• Quotes in OTC Equity Securities that meet the definition of bid or offer under the CAT NMS Plan sent by a broker-dealer to a quotation venue not operated by a CAT Reporter.
+Quotes in OTC equity securities sent to an inter-dealer quotation system operated by an Industry Member CAT Reporter must be reported in Phase 2c.
+The New Quote Event is used to report quotes in OTC equity securities. Quotes in NMS Securities sent to an exchange must be reported using the New Order and Route Events.
+For two-sided quotes - bidPrice, bidQty, askPrice, and askQty must all be populated. For one-sided quotes both a quantity and a price field must be populated for either the bid or the ask.
+Note that there is no Quote Modify event. The field priorQuoteID is used to report modifications to a previously reported New Quote. If the field priorQuoteID is populated with a value in the New Quote event, then this New Quote is considered to replace the quote described in the priorQuoteID field. In the case when quote ID does not change for a modified quote, the priorQuoteID and the quoteID (new) will have the same value.
+Otherwise, if the field onlyOneQuoteFlag = true, any New Quote event offered by the same reporterIMID to the same destination in the same symbol will be considered canceled by CAT.
+New Quote Event Field Specifications
+
+ 
+ 
+ pubdate: February 28, 2019 effdate: N/A
+ 4.11.1. Quote Received
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, New Quote, Quote Received
+ Compliance User: Industry Members
+ Keywords:
+ Industry Member,
+ Order Accepted Event,
+
+ When Quotes are sent to another Industry Member, that receiving Industry Member must report their receipt of the quote. Note that Industry Members do not have to report the quotes that they do not accept.
+Quote Received Event Field Specifications
+
+ 
+ pubdate: February 28, 2019 effdate: N/A
+ 4.11.2. Quote Canceled
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, New Quote, Quote Canceled
+ Compliance User: Industry Members
+ Keywords:
+ Industry Member,
+ ATS,
+ Quote Canceled events,
+ FINRA,
+ OTC Equity Securities,
+
+ 
+ Quote Canceled Event Field Specifications
+
+ 
+ pubdate: February 28, 2019 effdate: N/A
+ 4.12. Trade
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Trade
+ Compliance User: Industry Members
+ Keywords:
+ Trade Event,
+ Industry Member,
+ Reporting Exception Code,
+ Trade Side Details,
+ Internalized Trade,
+ Negotiated Trade,
+
+ Trade A Trade Event is used when the Industry Member acts as the executing broker and is required to report the trade for public dissemination purposes. When an Industry Member is not required to report the execution of a customer order for public dissemination purposes, an Order Fulfillment event must be used. See Section 4.13 Order Fulfillment for more details.
+Note there are two circumstances where a Reporting Exception Code (REC) will be required on a Trade Event. The first is when an Industry Member executes a trade between two desks or departments involving two proprietary accounts of the firm, but because there is no change in beneficial ownership, no trade is reported for public dissemination. In this instance a REC of “P” should be used on the Trade Event. The second is when an Industry Member executes a trade and must report the trade via Form T. In this instance a REC of “F” should be used on the Trade Event.
+Trade Side Details
+Trade events are generally two-sided, containing information on both sides of the trade (with the exception of negotiated trades and internalized trades). The details of each side are reported in buyDetails and sellDetails respectively. The buyDetails must contain the orderID of the buy side of the trade and the sellDetails must contain the orderIDof the sell side of the trade. Side Details may contain only one orderID per side. If a single order is crossed against multiple orders, a separate Trade Event must be reported for the execution of each individual order.
+Note that the data type Trade Side Details is described as a list of fields in the table immediately following the Trade event table. These are data elements such as an orderID associated with a side of the trade.
+Internalized Trade
+In the scenario where the Industry Member internalizes an order by filling it from a proprietary account, the Industry Member must report the orderID on the customer side and the FDID and the account type of the proprietary account on the firm side. No order ID is required on the firmSideDetails.
+Negotiated Trade
+If an execution occurs as the result of a negotiated trade between two Industry Members, both of the Industry Members, for CAT purposes, are considered to have executed the trade and must submit a Trade event with the negotiatedTradeSide marked appropriately. The negotiatedTradeSide indicates whether the Industry Member is performing a negotiated buy or negotiated sell in this execution. The Industry Member must capture the full details for its own side, while only the IMID of the contra-side.
+Trades that are executed by a market maker as the result of a displayed quotation must be reported using the Trade as Result of Quote Event. See Section 4.12.2 for the reporting requirements for trades executed by a market maker as the result of a quote.
+pubdate: February 28, 2019 effdate: N/A
+ 4.12.1. Trade Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Trade, Trade Event
+ Compliance User: Industry Members
+ Keywords:
+ Data Elements,
+ FINRA,
+ OTC Equity Securities,
+ National Securities Exchange,
+ NBBO,
+ Order Accepted Event,
+ New Order event,
+
+ The tables below describe the data elements to report agency cross or internalized orders by filling them from a proprietary account.
+Trade Event Field Specifications
+
+ 
+ Trade Side Details
+
+ 
+ Linkage Keys for this Reportable Event:
+• Order Key: date, reporter, symbol, buyDetails.orderID
+• Order Key: date, reporter, symbol, sellDetails.orderID
+• Trade Key: date reporter symbol tradeID
+• TRF Key: date, reporter, symbol, tapeTradeID
+pubdate: February 28, 2019 effdate: N/A
+ 4.12.2. Trade as the Result of a Quote
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Trade, Trade as the Result of a Quote
+ Compliance User: Industry Members
+ Keywords:
+ FINRA,
+ Quote event,
+ OTC Equity Securities,
+ National Securities Exchange,
+
+ If a trade is the result of a quote displayed by a market maker on an inter-dealer quotation system where the market maker is the executing broker under FINRA trade reporting rules and required to report the trade to the FINRA ORF, the Trade as the Result of a Quote event must be used to report the trade. The market maker is required to report the Quote ID of the quote from the inter-dealer quotation in order to link the quote to the trade.
+Trade on a Quote Event Field Specifications
+
+ Trade on a Quote Side Details
+
+ 
+ Linkage Keys for this Reportable Event:
+• Order Key: date, reporter, symbol, buyDetails.orderID
+• Order Key: date, reporter, symbol, sellDetails.orderID
+• Order Key: date, reporter, symbol, buyDetails.quoteID
+• Order Key: date reporter symbol sellDetails.quoteID
+• Trade Key: date reporter symbol tradeID
+• TRF Key: date, reporter, symbol, tapeTradeID
+pubdate: February 28, 2019 effdate: N/A
+ 4.13. Order Fulfillment
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Fulfillment
+ Compliance User: Industry Members
+ Keywords:
+ Industry Member,
+ CAT,
+ Order Fulfillment event,
+
+ The Order Fulfillment event is used to report the execution of a customer/client order that is not required to be reported for public dissemination purposes. Order Fulfillment reports are required for scenarios where a representative order was used to facilitate the execution of the customer/client order. Examples include orders executed on a riskless principal basis and orders executed on an agency basis via a representative agency order, such as in aggregation scenarios. An Order Fulfillment is also required when an order is routed to a foreign market and the resulting foreign execution is not captured by CAT. In this scenario, the Order Fulfillment is used to obtain the execution information for the customer order since such information is not otherwise available in CAT.
+The Order Fulfillment event is designed to capture the customer/client details and the firm side details, which reflect the representative order details for the order used to execute the customer/client order. In Phase 2a, not all scenarios require the firm side details to be populated.
+The field fulfillmentLinkType is used to indicate if the Industry Member (firm) side details are required. Below are the values allowed:
+• Y – Representative Order; linkage required
+• YF – Representative order; linkage required in future phase
+• YP – Fill from pre-existing Principal order; linkage required
+• FOR – No linkage required; Fulfillment on an order routed to a foreign destination
+• O - Options Order Fulfillment
+Appendix C contains detailed descriptions of representative order scenarios and illustrates when marking of the representative order, linkage between the represented order and the representative order, and Order Fulfillment linkage is required in each phase.
+pubdate: February 28, 2019 effdate: N/A
+ 4.13.1. Order Fulfillment Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Fulfillment, Order Fulfillment Event
+ Compliance User: Industry Members
+ Keywords:
+ Order Fulfillment event,
+ FINRA,
+ OTC Equity Securities,
+ Industry Member,
+ Order Accepted Event,
+
+ Order Fulfillment Event Field Specifications
+
+ 
+ Fulfillment Side Details
+
+ Linkage Keys for this Reportable Event:
+• Order Key: date (from eventTimestamp if firmDetails.priorOrderDate is not present), reporter, symbol, firmDetails.orderID
+• Order Key: date (from eventTimestamp if clientDetails.priorOrderDate is not present), reporter, symbol, clientDetails.orderID
+• Order Key: firmDetails.priorOrderDate (when present), reporter, symbol, firmDetails.orderID
+• Order Key: clientDetails.priorOrderDate (when present), reporter, symbol, clientDetails.orderID
+• Fulfillment: date, reporter, symbol, fulfillmentID
+pubdate: February 28, 2019 effdate: N/A
+ 4.14. Order Fulfillment Amendment
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Fulfillment Amendment
+ Compliance User: Industry Members
+ Keywords:
+ Industry Member,
+ Order Fulfillment,
+ debit/credit,
+ FINRA,
+ OTC Equity Securities,
+
+ If the order fulfillment is amended, an amendment event must be reported to CAT with required details. This Reportable Event must capture the entire state of the fulfillment after it has been amended, even though some of the data elements may remain unchanged.
+For example, an Industry Member has a trade correction from the exchange after the customer order has already been fulfilled. Subsequently, the Industry Member decided to amend the executed shares given back to the customer. In this scenario, both the original Order Fulfillment and Order Fulfillment Amendment events must be reported to CAT, even though they may happen on the same day. However, if the trade correction comes before any initial fulfillment has been made, and the Industry Member directly gives the corrected shares to the customer, then only one Order Fulfillment event is necessary to be reported.
+If an Industry Member makes a correction via a debit/credit to the customer's account instead of modifying the executed shares given back to the customer, then the Industry Member does not need to report an Order Fulfillment Amendment event.
+Note that the amendment reporting is only applicable to Order Fulfillment events, not the events reported to the TRF for media dissemination (which would have originally been reported as Trade events).
+Order Fulfillment Amendment Event
+
+ 
+ Linkage Keys for this Reportable Event:
+• Order Key: date (from eventTimestamp if firmDetails.priorOrderDate is not present), reporter symbol firmDetails.orderID
+, , . • Order Key: date (from eventTimestamp if clientDetails.priorOrderDate is not present), reporter symbol clientDetails.orderID
+• Order Key: firmDetails.priorOrderDate (when present), reporter, symbol, firmDetails.orderID
+• Order Key: clientDetails.priorOrderDate (when present), reporter, symbol, clientDetails.orderID
+• Fulfillment Key: date, reporter, symbol, fulfillmentID
+• Prior Fulfillment Key: date, reporter, symbol, priorFulfillmentID
+pubdate: February 28, 2019 effdate: N/A
+ 4.15. Post-trade Allocation (Phase 2c)
+Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Post-trade Allocation (Phase 2c)
+ Compliance User: Industry Members
+ Keywords:
+ <Deferred - Not Required Until Phase 2c>
+pubdate: N/A effdate: March 15, 2017
- 6870. Connectivity and Data Transmission
-Topic: FINRA Manual, Rules, 6800, Connectivity and Data Transmission
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: February 28, 2019 effdate: N/A
+ 5. Single Leg Option Events
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events
+ Compliance User: Industry Members
Keywords:
- Data Transmission,
- Connectivity,
- CAT Reporting,
- Agents,
+ Reportable Event,
+ Industry Members,
+ CAT,
+ SROs,
- (a) Data Transmission
-Each Industry Member shall transmit data as required under the CAT NMS Plan to the Central Repository utilizing such format(s) as may be provided by the Plan Processor and approved by the Operating Committee.
-(b) Connectivity
-Each Industry Member shall connect to the Central Repository using a secure method(s), including but not limited to private line(s) and virtual private network connection(s).
-(c) CAT Reporting Agents
-(1) Any 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 this Rule 6800 Series. Any such agreement shall be evidenced in writing, which shall specify the respective functions and responsibilities of each party to the agreement that are required to effect full compliance with the requirements of this Rule Series.
-(2) All written documents evidencing an agreement described in paragraph (a)(1) shall be maintained by each party to the agreement.
-(3) Each Industry Member remains primarily responsible for compliance with the requirements of this Rule 6800 Series, notwithstanding the existence of an agreement described in this paragraph (c).
-Adopted by SR-FINRA-2017-003 eff. March 15, 2017.
+This section describes Reportable Events for single leg option transactions. The following table lists each option Reportable Event type with its corresponding Message Type code.
+Notes
+•In Phase 2b, Industry Members are required to report CAT Industry Member Data related to Eligible Securities that are options and meet the definition of Simple Electronic Option Orders6, excluding Electronic Paired Option Orders.
+Events and data elements that are greyed out do not apply to Phase 2b.
+• The greyed out order events will not be supported in Phase 2b; any submission on unsupported event types will generate an error.
+• If data elements are greyed out for Phase 2b on a supported order event, the fields will be supported7 though not required. The Industry Member may voluntarily report the elements in Phase 2b.
+Linkages in Phase 2b
+In Phase 2b, the definition of an electronic single option order will result in unlinked events within a single CAT Reporter. To address these expected unlinked events, two fields (priorUnlinked and nextUnlinked) are used as described below. The purpose of these fields is to identify that the immediately preceding or following event is not reportable in Phase 2b and is not present for linkage. An immediately preceding or following event may be a manual event, complex order event, or a paired order. The priorUnlinked and nextUnlinked fields have values to indicate why the immediately preceding or following event is not present.
+
+ One or both of these fields will be on all options event types as conditional. If an event does not have this field populated, linkage will be attempted.
+Special circumstances of a complex order being represented as individual legs in Phase 2b
+In the special circumstance of an Industry Member sending (receiving) a complex order electronically as individual legs of the complex orders, the preferred method of reporting is to suppress the events associated with these messages. If an Industry Member cannot do this, the Industry Member must populate the handlingInstructions field with 'CMPX' to indicate that the order (route) is part of a complex option order in Phase 2b. In addition, such voluntarily reported single leg orders must include a priorUnlinked or nextUnlinked flag of 'C', as applicable, to indicate they will not link to a related order at the sending (receiving) firm.
+Summary of Option Order Events
+
+ 
+ pubdate: February 28, 2019 effdate: N/A
+ 5.1. New Option Order Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, New Option Order Event
+ Compliance User: Industry Members
+ Keywords:
+ Industry Members,
+ CAT,
+ non-reporting foreign broker-dealer,
+ CMTA trades,
+
+ An Industry Member must report a New Option Order event to CAT when an order is received or originated. This includes:
+• New customer orders8
+• Representative orders
+• Proprietary orders
+• Order(s) received from a non-reporting foreign broker-dealer or affiliate.
+Note that an order received from another CAT Reporter (US broker-dealer, ATS, or an exchange) must be reported as an Option Order Accepted event.
+Representative Orders
+Phase 2b Representative Orders
+While there are fewer representative order scenarios for options than equities, to the extent they are used, representative orders will be treated the same as equity representative orders, including the phased reporting approach for such orders.
+Specifically, in Phase 2b, representative orders and linkage to the represented order is required for simple, electronic orders between the representative street-side order and the customer or client order being represented, when the representative order was originated specifically to represent a single customer/client order and there is:
+• An existing, direct electronic link in the Industry Member's system between the order being represented and the representative order, and
+• Any resulting executions are immediately and automatically applied to the represented order in the Industry Member's system.
+Any portion of a specific order handling scenario that involves a complex or paired order is not reportable until Phase 2d.
+See Appendix C for a detailed description of representative order reporting.
+Phase 2d Representative Orders
+Any scenario that does not meet the definition of Phase 2b representative order will fall into this category, including any scenario involving a manual or complex order.
+See the CAT Industry Member Reporting Scenarios document for detailed examples of how representative order scenarios for options are reported in Phase 2b.
+New Option Order Event
+
+ 
+ Linkage keys for this Reportable Event:
+• Order Key: date, reporter, optionID, orderID
+• ComplexOrderKey: date, reporter, (complexOptionID), complexOrderID (Not applicable in Phase 2b)
+pubdate: February 28, 2019 effdate: N/A
+ 5.2. Option Order Supplement Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Supplement Event
+ Compliance User: Industry Members
+ Keywords:
+ <Deferred - Not Required Until Phase 2d>
+pubdate: February 28, 2019 effdate: N/A
+ 5.3. Paired Option Order (Phase 2d)
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Paired Option Order (Phase 2d)
+ Compliance User: Industry Members
+ Keywords:
+ <Deferred - Not Required Until Phase 2d>
+pubdate: February 28, 2019 effdate: N/A
+ 5.4. Option Order Route
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Route
+ Compliance User: Industry Members
+ Keywords:
+ Industry Members,
+ CAT,
+
+ Industry Members must report Option Order Route events to CAT when reporting the routing of option orders.
+pubdate: February 28, 2019 effdate: N/A
+ 5.4.1. Option Order Route Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Route, Option Order Route Event
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ Industry Members,
+ foreign broker-dealers,
+ Exchanges,
+ FINRA,
+ Order Accepted Event,
+ foreign broker-dealer,
+
+ An Industry Member must report to CAT an Option Order Route Event when:
+• Routing to other Industry Members
+• Routing to foreign broker-dealers
+• Routing to exchanges
+• Routing between two IMIDs (e.g. two different FINRA MPIDs) attributed to the same legal entity (i.e. the same CRD)
+• Routing partial quantities of an order (assigned using routedOrderId in routing message)
+In order for CAT to maintain order lifecycle linkage, the orderID populated in the Option Order Route event must reference the most recent internal ID of the order. For example, if an order was modified before routing out, the Route Event must use the ID assigned on the order modification.
+Internal routes to another desk or department within an Industry Member are not reported using the Option Order Route event; instead an Option Order Internal Route event is used. See the Option Order Internal Route section for more details.
+Handling Instructions on the Option Order Route
+The handling instructions included in this event should represent those on the routed order. If the handling instructions do not change from the Option Order Accepted or New Option Order associated with the order, Industry Members may use the handling instruction code "RAR" - routed as received, instead of repeating each individual handling instruction.
+Option Order Route Event Field Specifications
+
+ 
+ 
+ Linkage keys for this Reportable Event:
+• Order Key: date (from eventTimestamp if priorOrderDate is not present), reporter, optionID, orderID
+• Order Key: priorOrderDate (when present), reporter, optionID, orderID
+• Route Link Key: date, senderIMID, destination, optionID, session, routedOrderID
+pubdate: February 28, 2019 effdate: N/A
+ 5.4.2. Option Order Modify Route Event (Potential Phase 2d)
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Route, Option Order Modify Route Event (Potential Phase 2d)
+ Compliance User: Industry Members
+ Keywords:
+ SROs,
+
+ <Deferred – event not required for Phase 2a or Phase 2b. SROs will evaluate need for a modified route event after reviewing Phase 2a/2b data and include event in Phase 2d, if necessary.>
+pubdate: February 28, 2019 effdate: N/A
+ 5.4.3. Option Order Cancel Route Event (Potential Phase 2d)
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Route, Option Order Cancel Route Event (Potential Phase 2d)
+ Compliance User: Industry Members
+ Keywords:
+ SROs,
+
+ <Deferred – event not required for Phase 2a or Phase 2b. SROs will evaluate need for a canceled route event after reviewing Phase 2a/2b data and include event in Phase 2d, if necessary.>
+pubdate: February 28, 2019 effdate: N/A
+ 5.5. Option Order Accepted
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Accepted
+ Compliance User: Industry Members
+ Keywords:
+ Industry Members,
+ CAT,
+ non-reporting foreign entity,
+ CMTA trades,
+
+ When an Industry Member receives a routed option order from another Industry Member or an exchange, then an Option Order Accepted event must be reported to CAT. As described in Options Order Route event, if an Industry Member accepts a routed order from another Industry Member, even though that IMID may attribute to the same Industry Member, i.e., the same CRD, an Order Accepted event must be reported.
+Once all Industry Member are reporting, in all cases, the order reported with this event should have already been originated by another Industry Member and reported upon origination with a New Option Order event. A New Option Order event represents the beginning of the order lifecycle in CAT, therefore a new customer order is represented with a New Option Order event - not an Option Order Accepted event. At the start of Phase 2b, there will be some lifecycles beginning at Option Order Accepted event, as Small Industry Members are not required to report until a later phase.
+Orders received from a non-reporting foreign entity or affiliate should be reported as a New Option event instead of an Option Order Accepted event.
+Option Order Accepted Field Specifications
+
+ 
+ 
+ Linkage keys for this Reportable Event:
+• Order Key: date, reporter, optionID, orderID
+• Route Link Key: date, senderIMID, destination, optionID, session, routedOrderID
+pubdate: February 28, 2019 effdate: N/A
+ 5.6. Option Order Internal Route
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Internal Route
+ Compliance User: Industry Members
+ Keywords:
+ Industry Members,
+ CAT,
+ Child Option Order event,
+
+ An Option Order Internal Route events must be reported when an order is passed internally to a different department or desk within a reporterIMID.
+Although multiple reporterIMIDs may be attributed to a single Industry Member, routes between different IMIDs attributed to the same Industry Member are not considered internal routes.
+Note that an Optional Order Internal Route event does not follow the logic of sending/receiving two-sided reporting followed throughout the rest of these Industry Member Technical Specifications. It is required to be reported from the perspective of the recipient desk. The Option Order Internal Route merely shows that an order was received by an internal destination and if a new orderID has been assigned to the order as a result of the Option Order Internal Route.
+• An Option Order Internal Route may also represent the routing of partial quantities of an option order internally, and the practice of assigning those slices new orderIDs. In this case, multiple slices are routed to yet another destination internally - this event should represent the receiving desk, quantities, and new orderIDs of those routed slices as received by the subsequent internal destination. This approach will allow CAT to track changes in orderID within an Industry Member as an order is passed between internal entities or partial quantities are routed to internal entities as slices of another order.
+• The major difference between Option Order Internal Route and Child Option Order events is that the Child Option Order event can only be used when no desk change or desk route happens. For example, some Industry Members may first choose to generate child orders using the Child Option Order event to represent slices of a parent order, then route those slices internally to another desk (Option Order Internal Route event). This approach is also acceptable for CAT reporting and will not result in unlinked events.
+Option Order Internal Route Modified and Option Order Internal Route Canceled are not required to be reported until Phase 2d.
+pubdate: February 28, 2019 effdate: N/A
+ 5.6.1. Option Order Internal Route Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Internal Route, Option Order Internal Route Event
+ Compliance User: Industry Members
+ Keywords:
+ Symbol,
+
+ Option Order Internal Route event is used to report an order sent internally to another desk.
+Option Order Internal Route Field Specifications
+ +Linkage keys for this Reportable Event:
+• Order Key: date, reporter, optionID, orderID
+pubdate: February 28, 2019 effdate: N/A
+ 5.6.2. Option Order Internal Route Modify Event (Phase 2d)
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Internal Route, Option Order Internal Route Modify Event (Phase 2d)
+ Compliance User: Industry Members
+ Keywords:
+ <Deferred - Not Required Until Phase 2d>
+pubdate: February 28, 2019 effdate: N/A
+ 5.6.3. Option Order Internal Route Canceled Event (Phase 2d)
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Internal Route, Option Order Internal Route Canceled Event (Phase 2d)
+ Compliance User: Industry Members
+ Keywords:
+ <Deferred - Not Required Until Phase 2d>
+pubdate: February 28, 2019 effdate: N/A
+ 5.7. Child Option Order
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Child Option Order
+ Compliance User: Industry Members
+ Keywords:
+ Industry Members,
+
+ The Child Option Order event is provided solely for the convenience of Industry Members to help model scenarios in which an order is split or sliced into smaller "child" orders that are handled independently of their parent order - in a way that best reflects each individual Industry Member's system(s).
+For example, in the scenario when Industry Members create independent child orders with new orderIDs, if the Child Option Order event is reported, then the changes of order IDs are captured. Afterwards, the Industry Member can reference each individual child option order in subsequent events by the new order ID. However, if no Child Option Order event is reported, then the Industry Member can only reference the order at the parent level by the order ID of the parent. There is no scenario in which the use of a Child Option Order event is absolutely mandatory.
+Notes:
+• Child Option Order events can only be used when an order is sliced and assigned new order IDs within the same desk. An Option Order Internal Route event must be reported when routed to another desk.
+• There is no limit to how many "generations" can be created using Child Option Order events. The parentOrderID will be the orderID of the most recent order, whether that was a New Option Order/Option Order Accepted or a previous Child Option Order.
+• Child Option Orders must belong to the same FDID as the parent order.
+• Child Option Orders should not be used for single legs of a multi-leg option order.
+• This event only includes the key data elements and fields that may be changed from the parent order or that are required for linkage, i.e., certain key data elements from the parent order may not be changed when creating Child Option Orders.
+pubdate: February 28, 2019 effdate: N/A
+ 5.7.1. Child Option Order Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Child Option Order, Child Option Order Event
+ Compliance User: Industry Members
+ Keywords:
+ Industry Members,
+ contracts,
+ Reportable Event,
+
+ Child Option Order Event Field Specifications
+ +Linkage keys for this Reportable Event:
+• Order Key: date, reporter, optionID, orderID
+• Prior Order Key: date, reporter, optionID, parentOrderID
+pubdate: February 28, 2019 effdate: N/A
+ 5.7.2. Child Option Order Modified Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Child Option Order, Child Option Order Modified Event
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ Material Terms of the Order,
+
+ When the price, quantity, or any Material Term of the child option order has been changed, a Child Option Order Modified event must be reported to CAT. This modification event is only used when the child option order creation is reported to CAT in a Child Option Order event. As such, modifying a partial quantity internal route cannot be reported in this event.
+All attributes and Material Terms of the Order of a modified child option order listed on this event should be reported when applicable, including the fields that remain unchanged.
+Child Option Order Modified Event Field Specifications
+ +Linkage keys for this Reportable Event:
+• Order Key: date, reporter, optionID, orderID
+• Prior Order Key: date, reporter, optionID, priorOrderID
+pubdate: February 28, 2019 effdate: N/A
+ 5.7.3. Child Option Order Canceled
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Child Option Order, Child Option Order Canceled
+ Compliance User: Industry Members
+ Keywords:
+ Canceled event,
+ Industry Member,
+
+ If a child option order is canceled, a Child Option Order Canceled event must be reported to CAT by the Industry Member.
+Note that a partial cancellation can be reported either with a Child Option Order Modified event or Child Option Order Canceled event with leavesQty, depending on how it is handled by the Industry Member. If an actual cancel message was used, the Industry Member should report a Child Option Order Canceled event to CAT. If a modify or cancel/replace message was used, a Child Option Order Modified event should be reported to CAT. This keeps the reported event in line with the action taken by the Industry Member.
+Child Option Order Canceled Event Field Specifications
+ +Linkage Keys for this Reportable Event:
+• Order Key: date, reporter, optionID, orderID
+pubdate: February 28, 2019 effdate: N/A
+ 5.8. Option Order Modified and Cancel/Replace Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Modified and Cancel/Replace Event
+ Compliance User: Industry Members
+ Keywords:
+ Material Terms of the Order,
+ Industry Member,
+ contracts,
+ CMTA trades,
+
+ When the price, quantity or any other Material Terms of the Order has been changed or when an order is cancel/replaced, an Industry Member must report an Option Order Modified event to CAT. This Option Order Modified event concerns both of the following scenarios:
+1) A new order is generated (with a new Order ID) during the modification and completely replaces the prior order. In this case, the orderID field must capture the identifier for the the order. Additionally, the new order must be linked to the prior order through priorOrderID.
+2) If the Order ID remains the same during the modification, the priorOrderIDmust match the event orderID.
+Note that in the first scenario, if the order has been modified several times, the priorOrderID must refer to the most recent orderID prior to this modification, which may not always be the original order ID.
+Side is required to be reported, but side adjustments are only allowed for same-side changes (e.g., changes between short and long sell).
+All attributes and Material Terms of the modified order listed on this event should be reported when applicable, including the fields that remain unchanged.
+Option Order Modified and Cancel/Replace Event
+ +Linkage keys for this Reportable Event:
+• Order Key: date (from eventTimestamp), reporter, optionID, orderID
+• Prior Order Key: date (from eventTimestamp if priorOrderDate is not present), reporter, optionID, priorOrderID
+• Prior Order Key: priorOrderDate (when present), reporter, optionID, priorOrderID
+• Route Link Key: date, optionID, receiverIMID, routingOrigin, session, routedOrderID
+pubdate: February 28, 2019 effdate: N/A
+ 5.8.1. Option Order Modified Supplement Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Modified and Cancel/Replace Event, Option Order Modified Supplement Event
+ Compliance User: Industry Members
+ Keywords:
+ <Deferred - Not Required Until Phase 2d>
+pubdate: February 28, 2019 effdate: N/A
+ 5.9. Option Order Adjusted Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Adjusted Event
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ Option Order Modified event,
+ Reportable Event,
+
+ Industry Members must report to CAT the Option Order Modified event, which records the full state of the order reported to CAT on each modification. However, there are some common scenarios where only the order price and/or quantity of an order are modified. If such changes are initiated by the Industry member, the Option Order Adjusted event can be used. However, Option Order Adjusted events may not be used if a price or quantity change is initiated by a routing Industry Member.
+• Price change only - the price field and leavesQty must be reported to represent the current state of the order with respect to price. The two conditionally-required quantity fields (quantity, minQty) can be omitted.
+• Quantity change only - both conditionally-required quantity fields (quantity, minQty) and leavesQty must be reported. The price field can be omitted.
+• Both price and quantity change - If both price and quantity change, all fields must be reported.
+Any modification that cannot be fully represented in this Reportable Event must be reported via the Option Order Modified event.
+Option Order Adjusted Event Field Specifications
+ +Linkage keys for this Reportable Event:
+• Order Key: date, reporter, optionID, orderID
+• Prior Order Key: date, reporter, optionID, priorOrderID
+pubdate: February 28, 2019 effdate: N/A
+ 5.10. Option Order Canceled Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Canceled Event
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ Broker,
+ Industry Member,
+
+ The Option Order Canceled event is used in specific situations when an options order is fully or partially canceled. Note:
+• Partial cancellation of an order may be reported to CAT using either an Option Order Canceled event or an Option Order Modified event.
+• This Option Order Canceled Event is only reported by the Industry Member that performs the cancellation. Cancellations by away venues are not required to be reported. For example, if Industry Member Broker B accepts an order from Industry Member Broker A, and Broker B initiated a cancel on the order, then B is responsible for reporting the order canceled (not Broker A).
+• Implicit order cancellations are not required to be reported to CAT (e.g., cancellation due to expiration of Time in Force).
+Option Order Canceled Field Specifications
+ +Linkage keys for this Reportable Event:
+• Order Key: date (from eventTimestamp if priorOrderDate is not present), reporter, optionID, orderID
+• Order Key: priorOrderDate (when present), reporter, optionID, orderID
+pubdate: February 28, 2019 effdate: N/A
+ 5.11. Option Order Fulfillment
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Fulfillment
+ Compliance User: Industry Members
+ Keywords:
+ Industry Member,
+ contracts,
+ foreign non-reporting entity,
+
+ The Option Order Fulfillment event is designed to show an execution given back to the original option order(s), informing its customer/client of the number of contracts executed and at what price, that is not required to be reported for public dissemination purposes.
+An Order Fulfillment event must be reported in the following scenarios:
+• When an aggregated order executes, and the Industry Member gives back executed contracts to each order that was part of the aggregated order. An Option Order Fulfillment event will be reported for each order that was part of an aggregated order.
+• When an Industry Member creates a “representative" multi-leg complex option order. If the representative order is executed, the Industry Member must report an Option Order Fulfillment event for each of the orders being represented.
+• When an order is routed to a foreign non-reporting entity, the Industry Member must report an Option Order Fulfillment to represent the outcome of the order.
+For the first two scenarios above, Phase 2b does not require explicit order linkage between the bunched or representative order and the "underlying" order. Prior to Phase 2d, the Order Fulfillment events only contain the clientDetails. The fulfillmentLinkType must be marked as "YF".
+In the scenario of routing to a foreign non-reporting destination, the fulfillment event is always one sided (customer order only) and the fulfillmentLinkType must be marked as "FOR".
+pubdate: February 28, 2019 effdate: N/A
+ 5.11.1. Option Order Fulfillment Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Fulfillment, Option Order Fulfillment Event
+ Compliance User: Industry Members
+ Keywords:
+ Industry Member,
+ Option Order Accepted event,
+
+ Option Order Fulfillment Event Field Specifications
+ +Options Fulfillment Side Details
+ +Linkage Keys for this Reportable Event:
+• Order Key: date (from eventTimestamp if firmDetails.priorOrderDate is not present), reporter optionID firmDetails.orderID
+• Order Key: date (from eventTimestamp if clientDetails.priorOrderDate is not present), reporter optionID clientDetails.orderID
+• Order Key: firmDetails.priorOrderDate (when present), reporter, optionID, firmDetails.orderID
+• Order Key: clientDetails.priorOrderDate (when present), reporter, optionID, clientDetails.orderID
+• Fulfillment: date, reporter, optionID, fulfillmentID
+pubdate: February 28, 2019 effdate: N/A
+ 5.11.2. Option Order Fulfillment Amendment Event
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Fulfillment, Option Order Fulfillment Amendment Event
+ Compliance User: Industry Members
+ Keywords:
+ Industry Member,
+ CAT,
+ Option Order Fulfillment event,
+
+ If an order fulfillment is amended by an Industry Member on or after the trade date, an Option Order Fulfillment Amendment event is used. This Reportable Event must capture the entire state of the fulfillment after it has been amended, even though some of the data elements may remain unchanged.
+For example, if an Industry Member fulfills its customer's/client's order on an average price basis or work the order through representative or bunched orders. Afterwards, when a trade correction or trade break comes from the exchange and subsequently changes the price or quantity of the fulfilled contracts, both the original Option Order Fulfillment event and the Option Order Fulfillment Amendment event would be reported to CAT.
+The Option Order Fulfillment Amendment is not used in the following scenarios.
+• If a customer order is worked directly in an Agency capacity (without any representing or bunching) and filled print-for-print, when a trade break or trade correction occurs, the Industry Member does not need to report a Fulfillment Amendment event.
+• When a trade correction occurred same-day before the client order was fulfilled, only the Order Fulfillment event would be necessary to report to CAT, presuming it contained the updated (post-correction) average price.
+• When an Industry Member fulfills an order and receives a trade break from the exchange, it is possible that the Industry Member may choose to take the delta (e.g. using an error account) without amending the manner by which the order was fulfilled.
+Options Order Fulfillment Amendment Event Field Specifications
+ +Linkage Keys for this Reportable Event:
+• Order Key: date (from eventTimestamp if firmDetails.priorOrderDate is not present), reporter optionID firmDetails.orderID
+• Order Key: date (from eventTimestamp if clientDetails.priorOrderDate is not present), reporter, optionID, clientDetails.orderID
+• Order Key: firmDetails.priorOrderDate (when present), reporter, optionID, firmDetails.orderID
+• Order Key: clientDetails.priorOrderDate (when present), reporter, optionID, clientDetails.orderID
+• Fulfillment Key: date reporter optionID, fulfillmentID
+• Prior Fulfillment Key: date, reporter, optionID, priorFulfillmentID
+pubdate: February 28, 2019 effdate: N/A
+ 5.12. Linked Multi-Leg Option Order Events (Phase 2d)
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Linked Multi-Leg Option Order Events (Phase 2d)
+ Compliance User: Industry Members
+ Keywords:
+ <Deferred - Not Required Until Phase 2d>
+pubdate: February 28, 2019 effdate: N/A
+ 5.13. Option Post-Trade Allocations (Phase 2d)
+Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Post-Trade Allocations (Phase 2d)
+ Compliance User: Industry Members
+ Keywords:
+ <Deferred - Not Required Until Phase 2d>
+pubdate: N/A effdate: March 15, 2017
- 6880. Development and Testing
-Topic: FINRA Manual, Rules, 6800, Development and Testing
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: February 28, 2019 effdate: N/A
+ 6. Submission Process
+Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process
+ Compliance User: Industry Members
Keywords:
- Connectivity,
- Reporting,
- Member Information,
- Submission,
- Order Data,
- Testing,
+ CAT,
- (a) Development
-(1) Connectivity and Acceptance Testing
-(A) Industry Members (other than Small Industry Members) shall begin connectivity and acceptance testing with the Central Repository no later than August 15, 2018.
-(B) Small Industry Members shall begin connectivity and acceptance testing with the Central Repository no later than August 15, 2019.
-(2) Reporting Customer and Industry Member Information
-(A) Industry Members (other than Small Industry Members) shall begin reporting Customer and Industry Member information, as required by Rules 6840(a) and 6850, respectively, to the Central Repository for processing no later than October 15, 2018.
-(B) Small Industry Members shall begin reporting Customer and Industry Member information, as required by Rules 6840(a) and 6850, respectively, to the Central Repository for processing no later than October 15, 2019.
-(3) Submission of Order Data
-(A) Industry Members (other than Small Industry Members)
-(i) Industry Members (other than Small Industry Members) are permitted, but not required, to submit order data for testing purposes beginning no later than May 15, 2018.
-(ii) Industry Members (other than Small Industry Members) shall participate in the coordinated and structured testing of order submission, which will begin no later than August 15, 2018.
-(B) Small Industry Members
-(i) Small Industry Members are permitted, but not required, to submit order data for testing purposes beginning no later than May 15, 2019.
-(ii) Small Industry Members shall participate in the coordinated and structured testing of order submission, which will begin no later than August 15, 2019.
-(4) Submission of Options Market Maker Quote. Industry Members are permitted, but not required, to submit Quote Sent Time on Options Market Maker quotes, beginning no later than October 15, 2018.
-(b) Testing
-Each Industry Member shall participate in testing related to the Central Repository, including any industry-wide disaster recovery testing, pursuant to the schedule established pursuant to the CAT NMS Plan.
-Adopted by SR-FINRA-2017-003 eff. March 15, 2017.
+In this section, information is provided regarding how to format submission files, submit to CAT (including a general data flow overview), the registration process, network and transport options, and CAT access and reporting hours.
+pubdate: February 28, 2019 effdate: N/A
+ 6.1. File and Data Formats
+Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, File and Data Formats
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ ISO-8859-1,
+
+ All files sent from the CAT Reporter (or the third-party CAT Reporting Agent for the CAT Reporter) must be compressed, encrypted, and signed. However, the information in this section assumes, for the most part, that the file being described is the raw, unencrypted data (after being verified, decrypted, and uncompressed).
+All files submitted on a given date must have a unique file name, as defined in 6.1.1. The mechanism used for uploading files will prevent duplicate file names from being accepted into the CAT system.
+Archive files are not allowed to be submitted into the CAT System. Each set of records must be submitted as an individually compressed, encrypted, and signed file. For example: Do NOT zip, tar, or 7z all of the submitted files into one consolidated file. The files must be individually compressed, encrypted, and submitted.
+All data elements are submitted using ISO-8859-1 encoding. This is a one-byte-per-character encoding, with possible values in the range of [0, 255]. This encoding has the characteristic that the encoding character definitions are the same as the first 256 code points of UTF-8. However, only fully defined values will be accepted.
+According to the encoding specification, byte values in the ranges [0, 31] and [127, 159] are undefined. As a result, any record submitted with character values in those ranges will be rejected as invalid. In cases where data is echoed back in feedback files, invalid characters will be translated to a 3-character octal value, preceded by a backslash.
+pubdate: February 28, 2019 effdate: N/A
+ 6.1.1. File Names
+Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, File and Data Formats, File Names
+ Compliance User: Industry Members
+ Keywords:
+ CAT Reported ID,
+ Encryption Extension,
+
+ Files are to be named in the following manner:
+<CAT Reporter ID>_<Date>_[<Group>_]<File Kind>_<File Number>.<Extension>[.<Compression Extension>].<Encryption Extension>
+• CAT Reporter ID is the unique ID assigned to the reporter by CAT
+• Date is the calendar date for all events in the file in YYYYMMDD format - not the date the file was generated or reported
+• Group is an optional reporter-defined string. It must either be missing, or composed of up to 20 alphanumeric characters. The field exists solely for reporters’ convenience. Other than file name validation, it is ignored by the CAT processor
+• File Kind is “OrderEvents” for Industry Members
+• File Number is the sequence number of this file, 6-digits long, left-padded with zeros The tuple (CAT Reporter ID, Date, File Kind, File Number) must be unique. The File Number determines the order that a file will be processed within a File Kind.
+• Extension is the extension, representing the format of the data inside: json, csv
+• Compression Extension is the extension representing the compression used to compress the data file: gz, bz2, xz, zip. It is only needed if compression is done outside of the encryption process. If your OpenPGP tool handles compression, Compression Extension should be left off
+• Encryption Extension is the extension indicating that the file is encrypted and must be either .gpg or .pgp.
+pubdate: February 28, 2019 effdate: N/A
+ 6.1.2. Metadata Files
+Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, File and Data Formats, Metadata Files
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ Reported ID,
+
+ For each data file that is uploaded to CAT, associated metadata must also be uploaded. Submitters may pair the metadata file one-to-one with the data file, so that when the "pair" is ready, both files can be moved and processed in a timely manner, or the submitter may choose to package multiple metadata "blocks" for multiple data files into one metadata file. But they must be for the same calendar date, reporter, on the same file version and by the same submitter. Each metadata "block" contains checksum and signing of the files that are submitted, which are needed to verify integrity and track provenance of the submissions.
+The metadata file must be named in the following manner:
+<CAT Reporter ID>_<Date>_[<Group>_]<File Kind>_<Metadata File Number>.<Extension>[.<Compression Extension>].<Encryption Extension>
+• CAT Reporter ID, Date (and Group) must be consistent with the data file(s)
+• Metadata file number is the sequence number of the metadata file, 6-digits long, left-padded with zeros The combination (CAT Reporter ID, Date, Metadata File Number) must be unique.
+• Extension is .meta
+• The metadata file must be first signed in cleartext, then compressed and then encrypted.
+An Industry Member may use multiple metadata files for a day. If an Industry Member is uploading multiple metadata files, the Industry Member should set the doneForDay flag as false until the last metadata file is submitted for the date with doneForDay = true. Once a metadata file with doneForDay = true is received, this signals that the files submitted by the Industry Member are ready for the linkage discovery processing stage. However, this will not "close" the submission process. If an Industry Member discovers it needs to make additional data submissions, the Industry Member may continue to submit the additional data files with a new metadata file. If no metadata files for a trading day are flagged doneForDay = true, the doneForDay flag(s) those files will be automatically set to true upon submission deadline at 8:00AM.
+The metadata file does not need to be compressed, but must still be encrypted and signed like the data file. The metadata file is in JSON format, and contains:
+Metadata Files
+ +The hashes are to be submitted as 64-character hexadecimal string encodings of the hash value.
+
+ If a metadata block in the file has an error, the erroneous block will be dropped, and proper corresponding feedback will be returned (see Section 7 for File Acknowledgment Feedback or Basic File Integrity Feedback). The rest of the "blocks" of the metadata file will continue to be processed. The reporter can resubmit the corrected metadata block in another metadata file.
+Reporters can include the metadata for original data files and for correction files into one metadata file, as long as they are for the same reporter, submitter and calendar day.
+pubdate: February 28, 2019 effdate: N/A
+ 6.1.3. Data Files
+Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, File and Data Formats, Data Files
+ Compliance User: Industry Members
+ Keywords:
+ JSON,
+ CSV Records,
+
+ All data files are either new-line delimited JSON objects, or new-line delimited CSV records. This means that for JSON, there is no top level object. Instead, the file acts as the top level container for each object. Each object is a normal JSON object, separated with a new-line (ASCII decimal 10, hex 0A). For CSV files, each record’s fields are separated with a comma (ASCII decimal 44, hex 2C).
+Each JSON object is terminated by a new-line, but the data in the object itself must not include new-lines. Specifically, each line in the file must contain exactly one complete record, no matter whether the submission format is JSON or CSV. In either case, the total maximum length of any line is 4095 bytes. The examples in the document include new-lines between elements for readability.
+pubdate: February 28, 2019 effdate: N/A
+ 6.1.3.1. JSON Schema
+Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, File and Data Formats, Data Files, JSON Schema
+ Compliance User: Industry Members
+ Keywords:
+ JSON,
+ CAT,
+
+ JSON schema files for each record type will be provided on the CAT public website. Industry Members will be able to download and use these schemas to format and validate their CSV and JSON data files prior to submission. These schemas will also allow Industry Members to translate their data files from JSON to CSV or from CSV to JSON formats, as desired.
+The schema files will be maintained by the Plan Processor and will be versioned as the message specifications change. The meta files submitted to CAT will contain a version identifier specifying which version of the schema the associated reference or order data was formatted in accordance with. This will allow the CAT System to perform a basic initial formatting validation of all submitted data.
+Provided here is an abbreviated example of a JSON schema containing only part of the equity New Order event and a couple definitions for Choice fields:
+
+ 
+ Note that the file is not a typical "JSON schema" but a schema describing the Reportable Events in JSON.
+The field "JSONDataType" indicates the underlying JSON data type.
+The field "dataType" is the actual type, as indicated in this specification, with some further restrictions over the underlying JSON data type.
+The field "name" is the JSON field name. The "name" is also used as a lookup key to find valid values for a field of dataType "Choice."
+Each field of dataType "Choice" will contain a corresponding entry in the "choices" object, which contains the list of valid choices. The key is the value in the name field. If the name field contains a '.' (period), then the value is part of a nested JSON object and the key will be the trailing name. For example, if the field has a Choice field with the name "buyDetails.side" then the field "buyDetails" contains a JSON object with a member named "side" and "side" would be used as the key to lookup the valid choices for the element.
+The field "position" is the 0-based index where this field would be expected in a CSV version of the data.
+The field "required" indicates whether the field is "Required," "Conditional," or "Optional." If submitting in JSON, any conditional or optional field that is not provided must be omitted. If submitting in CSV, and conditional or optional field that it not provided must be an empty column (i.e., in the following example position 2 is considered to be omitted: zero,1,,three).
+Note that the Timestamp data type has two possible representations, so the JSONDataType is an array of choices: String for a formatted string and Number for nanoseconds since the epoch.
+pubdate: February 28, 2019 effdate: N/A
+ 6.1.3.2. CSV Conversion
+Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, File and Data Formats, Data Files, CSV Conversion
+ Compliance User: Industry Members
+ Keywords:
+ JSON Schema,
+ CAT,
+
+ The JSON schema defines valid data types, and mappings between JSON and CSV. Note that schemas can change with each specification version, and the authoritative schemas will be available on the CAT website. For this discussion, assume the following schema for an Equity Order Adjusted event. Provided here is an abbreviated example of a JSON schema containing only part of the Order Adjusted event and a couple definitions for Choice fields:
+
+ 
+ The corresponding CSV would be:
+MEOJ,20170901T120201.123456,E,false,,,XYZ,T12346,T12345,Customer,Buy,,,,1100, 100,100,,,,,,,,
+pubdate: February 28, 2019 effdate: N/A
+ 6.2. Connectivity and Registration
+Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, Connectivity and Registration
+ Compliance User: Industry Members
+ Keywords:
+ Network Access,
+ Industry Member Onboarding User Guide,
+
+ CAT supports network access for reporting order events via VPN or direct connections (i.e., cross connects).
+More detailed information on connectivity and the registration process will be provided in the Industry Member Onboarding User Guide.
+pubdate: February 28, 2019 effdate: N/A
+ 6.3. Transport Options
+Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, Transport Options
+ Compliance User: Industry Members
+ Keywords:
+ Industry Member,
+ Administrative Information,
+
+ Industry Members may use different mechanisms (SFTP or the Reporter Web Portal) to send/obtain different types of information to/from CAT.
+Basic types of CAT information:
+1) Submissions (e.g. initial submission of files of order events, resubmission of files that were previously rejected, and corrections or deletions to previously accepted records;
+2) Feedback (e.g. upload status, rejections, and reporting statistics); and
+3) Administrative information.
+ +SFTP submission allows file(s) only. If the submission is via the Reporter Web Portal, it may be sent by typing the information directly into the Web page or by submitting small files. The file size allowed via Reporter Web Portal is limited to 1GB before compression.
+pubdate: February 28, 2019 effdate: N/A
+ 6.3.1. File Size, Encryption, and Compression
+Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, Transport Options, File Size, Encryption, and Compression
+ Compliance User: Industry Members
+ Keywords:
+ File Compression,
+ Encrypting,
+ Metadata File,
+
+ Any files transmitted via SFTP or Reporter Web Portal must be 1) compressed AND 2) encrypted AND 3) signed, for the purpose of security and efficient network usage. The following compression algorithms will be allowed:
+• ZIP (extension: zip)
+• Gzip (extension: gz)
+• BZip2 (extension: bz2)
+• LZMA2 (extension: xz)
+The size of files uploaded via SFTP is limited to 100GB per file, before compression and encryption. Resumable file upload is enabled for SFTP. The size limit for the Reporter Web Portal is 1GB per file, before compression and encryption.
+Submission of data to CAT requires a number of supporting requirements that include security, confidentiality, authentication, and provenance of the data submitted. To achieve this the standard capabilities of PGP will be utilized and will require encrypting, signing, and secure hashing of data. While these steps must be followed, Submitters have a choice of compression algorithms, passphrase selection and length, as well as what tools they use on their platform. When encrypting a metadata file, the CAT public encryption key must be used. This public key will be made available to reporters. The file may also be encrypted with the public key of the submitter and the public key of the reporter. Encrypted files can only be decrypted by the private key corresponding with the public key used to encrypt the file; including the optional public keys of Submitter and Reporter ensures that private key holders of CAT, Reporter, and Submitter can decrypt the encrypted file.
+Public/Private keys should be RSA with a bit length of at least 2048 (minimum and recommended), and up to 4096. Interested parties can read more at https://www.gnupg.org/faq/gnupg-faq.html Sections 13.3-4 are directly relevant. The cipher algorithm must be AES-256(recommended) or higher. When encrypting data files, the submitter may also sign the file with their private key. Metadata files must always be signed in cleartext, and then encrypted. All files must be compressed before, or with the encryption process. The digest algorithm used to sign the file must be SHA256. The signature should also be part of the encrypted file (i.e. no detached signatures). Once a file has been encrypted and/or signed, the extensions .pgp, .gpg, or .asc must be appended to the end of the filename; OpenPGP compliant tools will do this for you.
+pubdate: February 28, 2019 effdate: N/A
+ 6.3.2. SFTP Upload Process
+Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, Transport Options, SFTP Upload Process
+ Compliance User: Industry Members
+ Keywords:
+ STFP Upload,
+
+ Each file that is uploaded must follow these basic steps.
+1. Upload the data file and the metadata file into the upload/transit directory, which will be at the base of the home directory for each sftp account.
+2. Upon successful upload of both file types (the metadata file as well as all the data files covered by the metadata file), move all files into the upload/complete directory. Note that all files should be uploaded before moving either to the complete directory.
+A file should never be directly uploaded into the upload/complete directory, as once a file has appeared there it is assumed to be the desired complete file submission. Only files that have a .pgp or .gpg extension will be processed.
+The Plan Processor will remove files from the upload/complete directory. The Submitter should never attempt to delete files from the upload/complete directory.
+pubdate: February 28, 2019 effdate: N/A
+ 6.4. Accessing Feedback Information
+Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, Accessing Feedback Information
+ Compliance User: Industry Members
+ Keywords:
+ CAT Feedback,
+
+ pubdate: February 28, 2019 effdate: N/A
+ 6.4.1. CAT Feedback
+Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, Accessing Feedback Information, CAT Feedback
+ Compliance User: Industry Members
+ Keywords:
+ Receipts,
+ Failure Reports,
+ File Submission Status,
+ Reporting Statistics,
+
+ Multiple types of feedback will be provided to Industry Members through various mechanisms, dependent upon the type of feedback provided.
+• Receipts - receipt of a file or the arrival of a file at the next stage of processing is provided in a feedback file. A File Acknowledgement Feedback File will be provided when each file is first received. A separate file will be generated when the file reaches each stage of processing. Processing stages (and thus feedback file types) vary based on the type of file being processed. Feedback files will be available via sftp. Receipt and feedback information will also be available via the Reporter Web Portal.
+• Failure Reports - if records in a file are rejected, if an entire file is rejected, or if there are warnings generated by a file, the feedback file will detail which records were rejected, why they were rejected, and at which stage of processing they were rejected. Note that CAT will not completely reject a file at the INGESTION stage. (Please refer to Section 7 for more details on various processing stages and feedbacks.)
+• File submission status - current processing status (whether a file has been received, which stage of processing a file is in, etc.) will be made available via the Reporter Web Portal.
+• Reporting Statistics - reporting statistics will be made available via the CAT Reporter Web Portal on a daily basis, and are posted when processing for all files has completed. The daily statistics will include, at a minimum, the following information for order events and reference data:
+• CAT Reporter ID
+• Date of Submission
+• Number of files received
+• Number of files accepted
+• Number of files rejected
+• Number of total order events received
+• Number of order events accepted
+• Number of order events rejected
+• Number of each type of report received
+• Number of each type of report accepted
+• Number of each type of report rejected
+• Number of unknown accounts
+• Number of late submissions
+• Order-IDs rejected
+• Reasons(s) for rejection
+• Number of records attempted to be matched
+• Number of records matched
+• Percentage of records matched
+pubdate: February 28, 2019 effdate: N/A
+ 6.5. CAT Reporting Hours
+Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, CAT Reporting Hours
+ Compliance User: Industry Members
+ Keywords:
+ Sec Rule 613,
+ CAT NMS plan,
+
+ Submission of Order Events
+Pursuant to SEC Rule 613, the CAT NMS Plan requires Industry Members to record order events contemporaneously with the actual transactions themselves. Realtime reporting to CAT is not required. Data may be bulk uploaded at the end of the Trading Day, or may be broken into multiple batches and uploaded in pieces throughout the day. However, all Reportable Events for one Trading Day must be reported to CAT by 8:00 AM Eastern Time on the next Trading Day.
+Trading Day for Industry Members is defined as:
+• Start: immediately after 4:15:00PM and no fractions of a second Eastern Time on one trade date
+• End: exactly 4:15:00PM and no fraction of a second Eastern Time on the next trade date (T=Trading Day, a defined term)9
+Note that the Trading Day is only used to determine the reporting deadline of order events. It does not impact the date on the file name (calendar day) or the date used to create linkages (date on eventTimestamp). Additional details on reporting dates and deadlines are included in Appendix D.
+CAT accepts submissions (via SFTP and Reporter Web Portal) 24 hours per day, 7 days per week, other than during announced scheduled maintenance. Events that occurred during a particular Trading Day may be reported anytime between the time the event occurred and the reporting deadline, which is 8:00 AM Eastern Time on the following Trading day. Reports received after the deadline will be marked late by CAT.
+The table below gives some examples of the reporting deadline.
+ +Deadline of Rejection Repair
+Rejections willbe provided to Industry Members in the following order:
+• File Format Validation Error
+• Syntax and Semantics Error
+• Context Issues
+Once rejections are available, repairs can be made immediately.
+In order to comply with the rule, all rejections that require repair should be repaired before 8AM Eastern Time on T+3 (transaction date + three Trading Days). Repairs received after the standard repair window will be classified as late.
+If corrections are not received by 8AM Eastern Time T+5 (transaction date + five Trading Days), Participants’ regulatory staff and the SEC will be notified. The Plan Processor shall notify the Participants’ regulatory staff and the SEC as to how corrections submitted after T+5 will be re-processed. The Operating Committee will be involved with decisions on how to re-process the data.
+ +Deadline for Corrections and Deletions
+Sometimes an Industry Member will have occasion to correct a report that may have passed all data validation and integrity checks. All such corrections must be submitted within the same three day timeframe as provided for record repairs. Specifically, Industry Members will be provided the same T+3 window for submitting timely corrections to data.
+pubdate: February 28, 2019 effdate: N/A
+ 6.6. Security
+Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, Security
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ Industry Member,
+ Submission or Correction,
+
+ In recognition of the importance of security, CAT has strict mechanisms for security controls. This section describes the CAT security overview and data security standards, to make sure the data is secured both during in transit and while stored in CAT.
+Submission to CAT requires a valid user ID and password. Industry Members must obtain a master user ID and password combination during the CAT registration process.
+Industry Members will also be assigned a multi-factor authentication (MFA) token during the registration process. An MFA token is required for authentication when accessing SFTP and Reporter Web Portal.
+Order Submission or Correction via SFTP or Reporter Web Portal must be compressed and encrypted. All communication with the web portal is done through secure HTTPS, and all such activity is captured in system logs.
+Industry Members are not allowed to view or download the actual data files from SFTP or Reporter Web Portal after submission. Data will be deleted from SFTP in a predefined time window, after it has been successfully processed and loaded into CAT data store.
+pubdate: February 28, 2019 effdate: N/A
+ 6.6.1. Data Security Standard
+Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, Security, Data Security Standard
+ Compliance User: Industry Members
+ Keywords:
+ CAT,
+ CAT Private Key,
+
+ In addition to data transport security provided by TLS and SSH, CAT requires that the data be secure at rest. To achieve this, CAT recommends one of the supported, industry standard tools for encryption to be used. PGP, OpenPGP, and GPG (GNU Privacy Guard), in addition to OpenSSL may be used for both symmetric and asymmetric encryption and decryption.
+Asymmetric encryption will be accomplished by the Industry Member using the Industry Member's private key and the CAT public key. Upon retrieval by CAT, the CAT private key will be used to decrypt the files. Should the Industry Member desire to be able to decrypt the data at another time, the Industry Member should encrypt with both the Industry Member's public key, as well as the CAT public key.
+Automated systems are an anticipated component of CAT submission, error retrieval, and status monitoring, and automated access is permitted in limited roles.
+CAT provides restricted automated (role based) sub-accounts with restricted access. Please note that automated access accounts must be associated with a person. These accounts will be permitted to use public security keys from their registered location. Public security keys will be registered via the Web portal, and associated with the restricted functional account. Should a Participant desire HSM support, most HSM devices allow public key extraction using commonly available tools from OpenSSL and OpenSSH, utilizing the pkcs12, ssh-keygen modules.
+pubdate: N/A effdate: March 15, 2017
- 6890. Recordkeeping
-Topic: FINRA Manual, Rules, 6800, Recordkeeping
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: February 28, 2019 effdate: N/A
+ 7. Feedback and Corrections
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections
+ Compliance User: Industry Members
Keywords:
- Recordkeeping,
- Records,
- SEA Rule 17a-4(f)(1)(i),
- SEA Rule 17a-4(f)(1)(ii),
+ CAT,
+ Obtaining Feedback,
- Each Industry Member shall maintain and preserve records of the information required to be recorded under this Rule 6800 Series for the period of time and accessibility specified in SEA Rule 17a-4(b). The records required to be maintained and preserved under this Rule may be immediately produced or reproduced on "micrographic media" as defined in SEA Rule 17a-4(f)(1)(i) or by means of "electronic storage media" as defined in SEA Rule 17a-4(f)(1)(ii) that meet the conditions set forth in SEA Rule 17a-4(f) and be maintained and preserved for the required time in that form.
-Adopted by SR-FINRA-2017-003 eff. March 15, 2017.
+This section describes the procedures for obtaining feedback and how to submit corrections, including different types of feedback messages, data elements, and formats of the correction reports. After data submission, CAT will conduct data validations, provide feedback to CAT Reporting Agents and Industry Members, and allow corrections to be submitted.
+Feedback will be made available via the Reporter Web Portal, both in the form of a user-centric webpage and a programmable API.
+For descriptions in this section, the CAT will consider a file to be successfully decrypted if and only if all of the decryption, decompression, and signature validation steps succeed.
+pubdate: February 28, 2019 effdate: N/A
+ 7.1. Feedback Files
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Feedback Files
+ Compliance User: Industry Members
+ Keywords:
+ Data file,
+ JSON,
+ CSV,
+ Feedback File,
+ Reject File,
+
+ For each data file, there are two types of files generated at different stage of processing and returned to the Industry Member and CAT Reporting Agent as feedback - the feedback file and the reject file.
+The format of the files will match the format of the original file submission in JSON or CSV.
+These files will be available as soon as they are generated, and accessible under the corresponding directory on the feedback sftp server for both the CAT Reporting Agent and Industry Member. They will also be made available via the Reporter Web Portal. Note that the IP address of the sftp server where files are uploaded may differ from the IP address of the sftp server where receipts and rejects are placed.
+• Feedback File
+Receipts will be available as soon as they are generated in the form of a feedback file, accessible under a subdirectory of download/feedback in both the CAT Reporting Agent’s and Industry Member’s home directory on the feedback sftp server.
+The exact subdirectory on the sftp server where feedback files may be found is:
+download/feedback/<YYYYMMDD>/<CATReporterId>/
+Where YYYYMMDD is the calendar date of the events in the submitted file.
+Feedback from different stages of processing will have different file extensions. See the following sections for more details.
+If there are failures or warnings, they will be available in the feedback file. It is possible for a record to have multiple failures, which will be represented by multiple JSON objects or new-line delimited CSV records within the failures array with the same record indexes.
+• Reject File
+If any of the ingestion failures correspond to specific records, a reject file (with extension .reject) will also be generated in the download/failures directory in the home directory of both the submitter and reporter. The reject filename will be included with the feedback record under the field rejectFile. The reject file will be populated with Correction Records containing the original rejected records and record index, to make corrections easier to submit (as described in the Corrections section). The record index is the offset from the beginning of the file to the first byte of the record.
+Feedback files will have the same base name as the submitted file. The file name will be appended with an extension describing the feedback type and .pgp. It will be compressed, encrypted, and signed. Compression will be based on the compression preferences associated with the public keys used to encrypt the feedback file. The keys used will be the CAT Reporting Agent's key, Industry Member’s key (if different), and the CAT public key. It will be signed with the CAT private key. For example, if a file was submitted from CAT Reporter “MYID”, with the following name:
+MYID_20170101_OrderEvents_000123.csv.gz.pgp
+The following would be the filename for the acknowledgement feedback file:
+MYID_20170101_OrderEvents_000123.ack.pgp
+Filenames are considered unique using the base name of the file (i.e., after removing all suffixes). Thus, trying to upload files that differ only in extension would be considered an error for uploading files with duplicate filenames.
+ +If multiple files are submitted with the same base name, but with different format or compression extensions, then a _<N> will be applied to the base name of the second and subsequent feedback file names, where N will be the iteration of the feedback file.
+If multiple files are submitted with the same base name or CAT needs to provide feedback when reprocessing a file feedback, an _<N> will be applied to the base name of the feedback files to avoid overwrite of any feedback files contained at that time in the download directories.
+Feedback files will be generated as each data file goes through various stages of processing. CAT will have four main processing stages, as described below:
+1. File Acknowledgement
+2. Basic File Integrity Check
+3. Order Events - Ingestion
+4. Order Events - Linkage Discovery
+Please see the following sections for details of each stage.
+Some stages will complete almost immediately, generating feedback shortly after the file has been uploaded (e.g. File Acknowledgement stage); other stages may take significant time, meaning that feedback could be delayed (either due to queuing behind other jobs, or because certain data elements are required to advance). For file acknowledgement, basic file integrity or ingestion stages, feedback will be provided as soon as the processing of each stage is completed. However, the feedback from linkage discovery phase, due to the dependency on other reporters' order events, will not be provided prior to noon on T+1, when all feedback is required to be returned.
+The minimum retention time for feedback files on the sftp server is 10 business days; after that time they may be removed from the server. Feedback will continue to be available after that time via the Reporter Web Portal.
+Failure codes are listed in Appendix E.
+pubdate: February 28, 2019 effdate: N/A
+ 7.2. File Acknowledgement
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, File Acknowledgement
+ Compliance User: Industry Members
+ Keywords:
+ Receipt of Acknowledgment,
+
+ A receipt of acknowledgement will be generated for each file and metadata pair that appears in the upload/complete directory or uploaded via the Reporter Web Portal.
+The data and metadata file should be moved into the upload/complete directory within a reasonable timeframe of each other. If a file is rejected (e.g., because the filename is not in the correct format or there is a timeout without seeing the associated data/metadata file), the receipt will contain a status of Failure and one or more failure codes with descriptions.
+Files will be removed from the upload/complete directory after they are processed, though they may not be removed immediately after processing.
+pubdate: February 28, 2019 effdate: N/A
+ 7.2.1. File Acknowledgement Feedback
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, File Acknowledgement, File Acknowledgement Feedback
+ Compliance User: Industry Members
+ Keywords:
+ CAT SUbmtter ID,
+ CAT Reporter ID,
+ Timestamp of Receipt,
+
+ An acknowledgement feedback file will have a .ack extension and will contain the following fields:
+• CAT Submitter ID (as determined from sftp or web portal username)
+• CAT Reporter ID (as determined from filename, if available)
+• Timestamp of Receipt - timestamp file is received and receipt is generated
+• Date (calendar date as submitted from filename, if available)
+• File Name
+• Feedback Version - the version of feedback file schema
+• Status - Success or Failure
+• Failures - a repeating group of failure codes and descriptions
+• Severity - WARNING or ERROR
+• Failure Code
+• Failure Description
+The following is an example JSON object for a successful file acknowledgement:
+
+ CSV presentation of a successful file acknowledgement:
+Line 0 SUBID,MYID,20170307T153552.000001089,20170307, MYID_20170307_OrderEvents_000123.json.gz.pgp,0.1,Success
+The following is an example JSON object for an unsuccessful file acknowledgement:
+
+ CSV presentation:
+Line 0 SUBID,MYID,20170307T153552.000001089, 20170307,MYID_20170307_OrderEvents_000123.json.gz.pgp,0.1,Failure
+Line 1 ERROR, FILE.TIMEOUT.001, Time out waiting for meta file
+pubdate: February 28, 2019 effdate: N/A
+ 7.3. Basic File Integrity
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Basic File Integrity
+ Compliance User: Industry Members
+ Keywords:
+ Metadata File,
+
+ When all the data file(s) and associated metadata file have been received, basic validation will begin. If the metadata file cannot be decrypted, a failure will be generated, and no further attempt will be made to process the file until a valid metadata file is uploaded. If there is an error for one 'block' of metadata within the file, the 'block' with the failure is dropped from processing but the remaining metadata 'blocks' and associated files will still be processed. The Industry Member can submit another metadata file with the corrected 'block' to complete processing.
+pubdate: February 28, 2019 effdate: N/A
+ 7.3.1. Basic File Integrity Checks
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Basic File Integrity, Basic File Integrity Checks
+ Compliance User: Industry Members
+ Keywords:
+ Matching Date,
+ Submitter,
+ Reporter,
+ Encrypted Size,
+ Encrypted Hash,
+ Decryption,
+ Compressed Hash,
+ Data Hash,
+
+ The values contained in the metadata file will be checked against properties of the corresponding data file. The following properties will be checked:
+• Matching Date - the date part of the filename must match the metadata Date
+• Submitter - metadata CAT Submitter ID must be the same as actual submitter (as determined from sftp or web portal username)
+• Reporter - the CAT Reporter ID part of the filename must match the metadata CAT Reporter ID
+• Encrypted Size - metadata Encrypted Byte Count must equal size of encrypted, received file
+• Encrypted Hash - metadata Encrypted Hash must equal computed SHA256 of encrypted, received file
+• Decryption - the data file must be successfully decrypted
+• Compressed Hash - computed SHA256 must equal metadata Compressed Hash, if provided
+• Data Hash - computed SHA256 must equal metadata Raw Hash, if provided
+One or both of the Compressed Hash and Data Hash must be provided. If neither are provided, then the file will be rejected.
+Note that all data elements in the metadata file are validated during this stage except Record Count, which will be validated when the file is actually processed.
+pubdate: February 28, 2019 effdate: N/A
+ 7.3.2. Basic File Integrity Feedback
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Basic File Integrity, Basic File Integrity Feedback
+ Compliance User: Industry Members
+ Keywords:
+ CAT SUbmtter ID,
+ CAT Reporter ID,
+ Timestamp of Receipt,
+ Feedback Version,
+ Status,
+
+ A basic file integrity feedback file will have a .integrity extension and will contain the following fields:
+• CAT Submitter ID (as determined from sftp or web portal username)
+• CAT Reporter ID (as determined from filename)
+• Timestamp of Receipt - timestamp when receipt was generated
+• Date
+• Feedback Version - the version of feedback file schema
+• Status - Success or Failure
+• Failures - a repeating group of failure codes and descriptions
+• Severity - WARNING or ERROR
+• Failure Code
+• Failure Description
+The following is an example JSON object for a successful integrity check:
+
+ CSV conversion
+Line 0 SUBID,MYID,20170307T153552.000001089,20170307,0.1,Success
+The following is an example JSON object for an unsuccessful integrity check:
+
+ CSV conversion
+Line 0 SUBID,MYID,20170307T153552.000001089,20170307,Failure
+Line 1 ERROR,INT.META.001,Encrypted SHA does not match SHA in meta file.
+pubdate: February 28, 2019 effdate: N/A
+ 7.4. Order Event Files
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Order Event Files
+ Compliance User: Industry Members
+ Keywords:
+ Records,
+ Order Event File,
+
+ Order Event files are composed of many different types of records. Any record determined to be malformed or otherwise invalid will be rejected as a failure.
+• If the number of records in the file does not match the Record Count in the metadata file or metadata block, the entire file will be rejected.
+• If an Order Event file contains anything other than expected order event messages, the entire file will be rejected.
+Each field of the order event will be checked and validated, resulting in one of three states for the record: success, error, or warning. An error will prevent the record from being processed. A warning will not prevent the record from being processed, but may indicate that a record will be subject to errors during a later stage or processing. Depending on the type of warning, the record may be processed and ignored, or processed and applied to the data set. A record with only warning(s) but without error(s) do not require corrective action from the Industry Member.
+For example, there are occasions where symbols are “delisted” late and may already have been referenced by some Industry Members (most likely in stage two). CAT allows incremental uploads throughout the day. Thus, their order event reports may contain opens and/or cancels for those symbols. Instead of rejecting these records, CAT will generate warnings for benign order actions and silently ignore them. Execution events for such symbols, however, will generate errors.
+The system is backward compatible when there is a change or transition to a new version of reporting specifications. In such cases where the latest/preferred method is detectable, but not detrimental, a warning may be generated to inform the reporter on the details, but the record will still be accepted and processed by the system.
+pubdate: February 28, 2019 effdate: N/A
+ 7.4.1. Order Event Feedback
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Order Event Files, Order Event Feedback
+ Compliance User: Industry Members
+ Keywords:
+ Ingestion,
+ Linkage Discovery,
+
+ The act of processing order events has multiple stages: ingestion and linkage discovery.
+During the ingestion phase, each record will be checked for proper formatting (JSON field names and values, CSV values in proper columns, etc) and data contents. The defined JSON schemas for each record type will be used to validate every field of each record. The schema defines the format of each record and the data types and acceptable ranges of each value. In addition, it defines which fields are mandatory.
+Fields whose value depends on context (and are not defined in the schema) will be validated by explicit rules to make sure that all requirements for their processing are followed.
+Order events will be checked for both internal consistencies and valid relationships when referencing other orders or events from the same reporter.
+The full lifecycle will be generated from the full set of order events, and any order that is not fully linked will be flagged as an error.
+CAT will not completely reject a file at the ingestion or linkage discovery stage (once it passes the record count validation). Any file that passes the basic file integrity check will be fully scanned, and feedback will be provided for each of the records in the file.
+Receipts will be generated for each phase. The feedback files will have the following extensions for each stage:
+• INGESTION - .ingestion
+• LINKAGE DISCOVERY - .linkage
+The feedback files will contain the following fields:
+• CAT Submitter ID
+• CAT Reporter ID
+• Timestamp of Receipt
+• Date - Calendar date of the events/file
+• Stage - INGESTION or LINKAGE_DISCOVERY
+• Status - Success if all records in the file were accepted, Failure if some or all records were rejected, or Warning if some or all records have warnings
+• Number of Accepted Records - this stage only
+• Number of Rejected Records - this stage only
+• Reject Filename - if present, contains the relative name of the file in the downloads/failures directory containing records that were rejected.
+• Feedback Version - the version of feedback file schema
+• Failures - a repeating group, each containing:
+• Severity - WARNING or ERROR
+• Failure Code
+• Failure Description
+• Original Record Index - if applicable, the 0-based byte index of the record in the submitted file
+• Reject Record Index - if applicable, the 0-based byte index of the record in the Reject Report
+• Firm ROEID - the value reported in the firmROEID field in the original Order Event if populated (otherwise blank)
+The following is an example JSON object for a successful OrderEvents ingestion:
+
+ CSV presentation:
+Line 0 SUBID,MYID,20170307T153552.000001089,20170307,INGESTION,Success,21 4513134,0,0.1
+The following is an example JSON object for an unsuccessful OrderEvents normalization:
+
+ CSV presentation:
+Line 0 SUBID,MYID,20170307T153552.000001089,20170307,INGESTION,Failure,21 4513132,2,MYID_20170307_OrderEvents_000002.rejects.pgp,0.1
+Line 1 ERROR, OE.INGEST.014,Invalid value for TIF,123456,DESKP123456
+Line 2 WARNING,OE.INGEST.009,Symbol has been delisted,654321,1234, DESKC56789
+pubdate: February 28, 2019 effdate: N/A
+ 7.5. Co rrectio ns
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections
+ Compliance User: Industry Members
+ Keywords:
+ correction data files,
+
+ Corrections may be made manually via the web portal or uploading correction data files. If the entire file was rejected, then corrections should be submitted as repair records.
+Corrections are due by T+3 at 8AM, where T is the CAT Trading Day. However, corrections may be made at any time, even if beyond the error correction timeframe.
+pubdate: February 28, 2019 effdate: N/A
+ 7.5.1. Repair Records
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections, Repair Records
+ Compliance User: Industry Members
+ Keywords:
+ correction data files,
+ Repair of Data Files,
+ Reject Files,
+
+ Repair records may be submitted to correct or delete a previously submitted record. Both records that have been previously rejected and records that have already been accepted may be repaired.
+Repair records should be submitted in a repair file in the same format (JSON or CSV) as the original file requiring corrections. (Reporters will not be allowed to submit a JSON repair file if the original file was submitted in CSV and vice versa.) The repair file may contain repair records from multiple original files, as long as all repair records for the same calendar date. The repair filename must contain the same Reporter ID, date (calendar date) and marked as "OrderEvents"', with the string "Corrections" appended, as well as the sequence number of the correction file. For example, if the original filenames with errors were MYID_20170101_OrderEvents_000123.[json|csv]and MYID_20170101_OrderEvents_000130.[json|csv] then the repair filename may be MYID_20170101_OrderEvents_Corrections_000001.[json|csv].
+Metadata for the repair file may be submitted as its own meta file or as a metadata 'block' within a combined metadata file.
+Metadata for the repair record should be valid for the repair record file, not the original files being repaired. For example, the Encrypted Hash and Encrypted Size should be the hash and size of the repair record file.
+Each repair record will uniquely identify a record to repair using the 0-based index of the original record, combined with the original file number. If the record to be repaired cannot be identified, the repair record will be rejected. If a feedback file has a failure file associated with it, then the index will be pre-populated on Correction Records in the failure file to ease repair submissions. Otherwise, if correcting or deleting non-rejected records, the submitter will need to populate these fields itself.
+Reject files (as indicated by the rejectFile field on some feedback records) can be used to submit corrections. Since the files are pre-populated with Correction Records, a file only needs to be downloaded, the appropriate changes to the contents of the record(s) made, and the file submitted with the appropriate file name.
+Repair record files may contain delete and correction records only. If an invalid record type is detected in the file, then the entire file will be rejected.
+pubdate: February 28, 2019 effdate: N/A
+ 7.5.2. Submitter Created Repair File Structure
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections, Submitter Created Repair File Structure
+ Compliance User: Industry Members
+ Keywords:
+ Original Data File,
+
+ In order to locate the original data file(s) to be corrected, the Reporter must list the original file numbers (of the original data file being corrected) in the metadata of the correction files. For example, if the correction file (correction file name: MYID_20170307_OrderEvents_Corrections_000001.JSON) contains the corrections or deletions for the following original data files:
+• origFileName:"MYID_20170307_OrderEvents_000123.json"(origFileNumber=000123)
+• origFileName:"MYID_20170307_OrderEvents_000130.json"(origFileNumber=000124)
+Then metadata for this correction file must include "origFileNumber": [000123,000124]
+For example:
+
+ The repairs records in the correction file are organized in a record change list. The repairs should be grouped by original file number.
+
+ In the CSV presentation, origFileNumber will be flattened into the first column of each line, and the repairRecords will be starting from the next columns. For the examples above, the CSV presentation will look like below.
+Line 0 000123,DEL,456
+Line 1 000123,DEL,5098
+Line 2 000124,DEL,9005
+Line 3 000124,DEL,12345
+pubdate: February 28, 2019 effdate: N/A
+ 7.5.2.1. Delete Record
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections, Submitter Created Repair File Structure, Delete Record
+ Compliance User: Industry Members
+ Keywords:
+ Record Type,
+ Original Record Index,
+
+ A delete record must contain the following fields:
+• Record Type - DEL
+• Original Record Index - the 0-based index of the record in the original file
+The following is an example delete record:
+
+ pubdate: February 28, 2019 effdate: N/A
+ 7.5.2.2. Correction Record
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections, Submitter Created Repair File Structure, Correction Record
+ Compliance User: Industry Members
+ Keywords:
+ Record Type,
+ Original Record Index,
+ Replacement Record,
+
+ A correction record must contain the following fields:
+• Record Type - COR
+• Original Record Index - the 0-based index of the record in the original file
+• Replacement record - the corrected record
+The following is an example correction record:
+
+ pubdate: February 28, 2019 effdate: N/A
+ 7.5.2.3. Repair File Sample
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections, Submitter Created Repair File Structure, Repair File Sample
+ Compliance User: Industry Members
+ Keywords:
+ JSON,
+
+ Please see a sample of a repair file in JSON below:
+
+ CSV presentation:
+Line 0 000123,DEL,456
+Line 1 000123,DEL,457
+Line 2 000124,COR,567,MENO,CORO98765,20170801T143031.123456,false,,, XYZ,O12345,N,O,,Buy,10.01,500,,LMT,DAY,REG,,false,PROP456,O,,, false,N,,,,,,,,,,,
+pubdate: February 28, 2019 effdate: N/A
+ 7.5.3. rejectFile (CAT Provided) Format
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections, rejectFile (CAT Provided) Format
+ Compliance User: Industry Members
+ Keywords:
+ CAT Provided Format,
+
+ The rejectFile that can be accessed in downloads/failures will be pre-populated with Correction Records. Below is an example of the rejectFile:
+
+ In the example above, two correction records are included and pre-populated with the original records as they were submitted. The submitter or reporter may simply modify the erroneous data elements, rename the file and submit it to CAT as the correction file.
+Below is the CSV format presentation.
+Line 0 COR,567,MENO,DESK98765,20170801T143031.123456,false,,,XYZ,O12345, N,O,,Buy,10.01,500,,LMT,DAY,REG,,false,PROP456,O,,,false, N,,,,,,,,,,,
+Line 1 COR,8965,MENO,DESK12345,20170801T143035.123456,false,,,ABC,O56789, N,O,,Buy,100.01,200,,LMT,DAY,REG,,false,PROP456,O,,,false, N,,,,,,,,,,,
+pubdate: February 28, 2019 effdate: N/A
+ 7.5.4. Repair Record Feedback
+Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections, Repair Record Feedback
+ Compliance User: Industry Members
+ Keywords:
+ Record Files,
+
+ Repair record files will receive the same types of feedback as the file being repaired. Feedback for the repair records will be provided no later than noon T+3.
+Note that if one record needs to be corrected more than once, all corrections must refer to the original record by the original file number (origFileNumber) and record index (recordIdx). If multiple corrections are submitted for one original record, the most recent correction - the correction file with the highest file number - will be treated as the valid version.
+For example, if the Reporter submits a correction for original file MYID_20170307_OrderEvents_000123 (fileNumber = 000123, recordInd = 456) in a correction file MYID_20170307_OrderEvents_Corrections_000001. And later the Reporter desires to correct the same record again that overwrites the previous correction. Then the second correction (correction file name: MYID_20170307_OrderEvents_Corrections_000009) must still reference to the original file number and record index - fileNumber 000123 and recordInd 456. Between the two correction files, the one with larger file number (000009) will be treated as the most recent valid version of the record.
+pubdate: N/A effdate: March 15, 2017
- 6893. Timely, Accurate and Complete Data
-Topic: FINRA Manual, Rules, 6800, Timely, Accurate and Complete Data
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: February 28, 2019 effdate: N/A
+ 8. Testing
+Topic: CAT Reporting Technical Specifications for Industry Members, Testing
+ Compliance User: Industry Members
Keywords:
- Report,
- LEIs,
- Error Rate,
- Compliance Thresholds,
+ CAT,
+ Industry Member,
+ CAT System,
- (a) General
-Industry Members are required to record and report data to the Central Repository as required by this Rule Series in a manner that ensures the timeliness, accuracy, integrity and completeness of such data.
-(b) LEIs
-Without limiting the requirement set forth in paragraph (a), Industry Members are required to accurately provide the LEIs in their records as required by this Rule Series and may not knowingly submit inaccurate LEIs to the Central Repository; provided, however, that this requirement does not impose any additional due diligence obligations on Industry Members with regard to LEIs for CAT purposes.
-(c) Compliance with Error Rate
-If an Industry Member reports data to the Central Repository with errors such that the error percentage exceeds the maximum Error Rate established by the Operating Committee pursuant to the CAT NMS Plan, then such Industry Member would not be in compliance with the Rule 6800 Series.
-(d) Compliance Thresholds
-Each Industry Member shall be required to meet a separate compliance threshold which will be an Industry Member-specific rate that may be used as the basis for further review or investigation into the Industry Member's performance with regard to the CAT ("Compliance Thresholds"). Compliance Thresholds will compare an Industry Member's error rate to the aggregate Error Rate over a period of time to be defined by the Operating Committee. An Industry Member's performance with respect to its Compliance Threshold will not signify, as a matter of law, that such Industry Member has violated this Rule Series.
-Adopted by SR-FINRA-2017-003 eff. March 15, 2017.
+CAT will provide an environment for testing that mirrors the current functionality of the CAT production environment, as well as including functionality for the next release version of the CAT environment when available. The CAT testing environment will automatically determine which specification version Industry Members and CAT Reporting Agents are using for submissions. If error reporting formats change, Industry Members and CAT Reporting Agents will receive feedback in the current and new specification via ftp, as well as have access to current/new web portal urls for specification changes that impact the web portal. Current/new connectivity changes will also be supported concurrently.
+The testing environment performs lifecycle linkage, and Industry Members and CAT Reporting Agents are encouraged to coordinate testing with their counterparties so as to test lifecycle linkage with their counterparties. Without simultaneous contra-party reporting in the test environment, Industry Members and CAT Reporting Agents will not be able to test linkage with their counterparties.
+Industry Members and CAT Reporting Agents should test their submissions using the testing environment before they begin submitting to the production environment.
+The test environment is available 24 hours a day, 6 days a week. Refer to the CAT website for contact information and hours of operation for support.
+Industry Members and CAT Reporting Agents connect to the test environment in the same manner they would connect to the production environment. However, for the connection to the test environment, one or more alternate IP/domains may be used.
+Testing does not relieve an Industry Member of its responsibilities to submit production data to the CAT System.
pubdate: N/A effdate: March 15, 2017
- 6895. Compliance Dates
-Topic: FINRA Manual, Rules, 6800, Timely, Compliance Dates
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: February 28, 2019 effdate: N/A
+ 9. Additional Information
+Topic: CAT Reporting Technical Specifications for Industry Members, Additional Information
+ Compliance User: Industry Members
Keywords:
- Clock Synchronization,
- CAT Data,
- Reporting,
+ Public Website,
- (a) General
-Except as set forth in paragraphs (b) and (c) of this Rule or otherwise set forth in this Rule Series, the compliance date for this Rule Series is the date of Commission approval.
-(b) Clock Synchronization
-(1) Each Industry Member shall comply with Rule 6820 with regard to Business Clocks that capture time in milliseconds commencing on or before March 15, 2017.
-(2) Each Industry Member shall comply with Rule 6820 with regard to Business Clocks that do not capture time in milliseconds commencing on or before February 19, 2018.
-(c) CAT Data Reporting
-(1) Each Industry Member (other than a Small Industry Member) shall record and report the Industry Member Data to the Central Repository by November 15, 2018.
-(2) Each Industry Member that is a Small Industry Member shall record and report the Industry Member Data to the Central Repository by November 15, 2019.
-Adopted by SR-FINRA-2017-003 eff. March 15, 2017.
+pubdate: February 28, 2019 effdate: N/A
+ 9.1. Public Website
+Topic: CAT Reporting Technical Specifications for Industry Members, Additional Information, Public Website
+ Compliance User: Industry Members
+ Keywords:
+ www.catnmsplan.com,
+
+ The CAT Public Website, www.catnmsplan.com, is available via the public internet, and is hosted outside the CAT secure network. The CAT Public Website provides information about the CAT, such as a link to SEC Rule 613, Technical Specifications, FAQs, training materials, and CAT Help Desk contact information.
+Web announcements will be made available on the public website (www.catnmsplan.com). You can also subscribe to receive email notifications regarding changes to the website. These announcements are used to post information related to the operation of CAT.
+Please contact CATNMSIO@deloitte.com for any questions and/or feedback regarding this document.
+pubdate: N/A effdate: Dec. 1, 2017
- 6898. Consolidated Audit Trail—Fee Dispute Resolution
-Topic: FINRA Manual, Rules, 6800, Fee Dispute Resolution
- Compliance User: bfe292cc-1912-4c19-8cf4-49c80731102b
+ pubdate: February 28, 2019 effdate: N/A
+ Appendix
+Topic: CAT Reporting Technical Specifications for Industry Members, Appendix
+ Compliance User: Industry Members
Keywords:
- Definitions,
- Dispute,
- Resolution,
- Fee,
- NMS Plan,
- Procedures,
- Submission of,
- Application,
- Hearing and Decision,
- Review,
- Petition,
- Payment,
+ Change Release Management Process,
+ Clock Synchronization Requirement,
+ Representative Order Linkages,
+ CAT Date Definitions and Reporting Guidelines,
+ Failure Codes,
- (a) Definitions
-(1) For purposes of this Rule, the terms "CAT NMS Plan", "Industry Member", "Operating Committee", and "Participant" are defined as set forth in Rule 6810 (Consolidated Audit Trail—Definitions).
-(2) "Subcommittee" means a subcommittee designated by the Operating Committee pursuant to the CAT NMS Plan.
-(3) "CAT Fee" means any fees contemplated by the CAT NMS Plan and imposed on Industry Members pursuant to FINRA Rules.
-(b) Fee Dispute Resolution
-Disputes initiated by an Industry Member with respect to CAT Fees charged to such Industry Member, including disputes related to the designated tier and the fee calculated pursuant to such tier, shall be resolved by the Operating Committee, or a Subcommittee designated by the Operating Committee, of the CAT NMS Plan, pursuant to the Fee Dispute Resolution Procedures adopted pursuant to the CAT NMS Plan and set forth in paragraph (c) of this Rule. Decisions on such matters shall be binding on Industry Members, without prejudice to the rights of any such Industry Member to seek redress from the SEC or in any other appropriate forum.
-(c) Fee Dispute Resolution Procedures under the CAT NMS Plan
-(1) Scope of Procedures
-These Fee Dispute Resolution Procedures provide the procedure for Industry Members that dispute CAT Fees charged to such Industry Member, including disputes related to the designated tier and the fee calculated pursuant to such tier, to apply for an opportunity to be heard and to have the CAT Fees charged to such Industry Member reviewed.
-(2) Submission and Time Limitation on Application to CAT NMS, LLC ("Company")
-An Industry Member that disputes CAT Fees charged to such Industry Member and that desires to have an opportunity to be heard with respect to such disputed CAT Fees shall file a written application with the Company within 15 business days after being notified of such disputed CAT Fees. The application shall identify the disputed CAT Fees, state the specific reasons why the applicant takes exception to such CAT Fees, and set forth the relief sought. In addition, if the applicant intends to submit any additional documents, statements, arguments or other material in support of the application, the same should be so stated and identified.
-(3) Procedure Following Applications for Hearing
-(A) Fee Review Subcommittee
-The Company will refer applications for hearing and review promptly to the Subcommittee designated by the Operating Committee pursuant to Section 4.12 of the CAT NMS Plan with responsibility for conducting the reviews of CAT Fee disputes pursuant to these Fee Dispute Resolution Procedures. This Subcommittee will be referred to as the Fee Review Subcommittee. The members of the Fee Review Subcommittee will be subject to the provisions of Section 4.3(d) of the CAT NMS Plan regarding recusal and Conflicts of Interest.
-(B) Record
-The Fee Review Subcommittee will keep a record of the proceedings.
-(C) Hearings and Documents
-The Fee Review Subcommittee will hold hearings promptly. The Fee Review Subcommittee will set a hearing date. The parties to the hearing (as described in paragraph (c)(4)(A) below) shall furnish the Fee Review Subcommittee with all materials relevant to the proceedings at least 72 hours prior to the date of the hearing. Each party shall have the right to inspect and copy the other party's materials prior to the hearing.
-(4) Hearing and Decision
-(A) Parties
-The parties to the hearing shall consist of the applicant and a representative of the Company who shall present the reasons for the action taken by the Company that allegedly aggrieved the applicant.
-(B) Counsel
-The applicant is entitled to be accompanied, represented and advised by counsel at all stages of the proceedings.
-(C) Conduct of Hearing
-The Fee Review Subcommittee shall determine all questions concerning the admissibility of evidence and shall otherwise regulate the conduct of the hearing. Each of the parties shall be permitted to make an opening statement, present witnesses and documentary evidence, cross examine opposing witnesses and present closing arguments orally or in writing as determined by the Fee Review Subcommittee. The Fee Review Subcommittee also shall have the right to question all parties and witnesses to the proceeding. The Fee Review Subcommittee shall keep a record of the hearing. The formal rules of evidence shall not apply.
-(D) Decision
-The Fee Review Subcommittee shall set forth its decision in writing and send the written decision to the parties to the proceeding. Such decisions shall contain the reasons supporting the conclusions of the Fee Review Subcommittee.
-(5) Review
-(A) Petition
-The decision of the Fee Review Subcommittee shall be subject to review by the Operating Committee either on its own motion within 20 business days after issuance of the decision or upon written request submitted by the applicant within 15 business days after issuance of the decision. The applicant's petition shall be in writing and specify the findings and conclusions to which the applicant objects, together with the reasons for such objections. Any objection to a decision not specified in writing shall be considered to have been abandoned and may be disregarded. Parties may petition to submit a written argument to the Operating Committee and may request an opportunity to make an oral argument before the Operating Committee. The Operating Committee shall have sole discretion to grant or deny either request.
-(B) Conduct of Review
-The Operating Committee shall conduct the review. The review shall be made upon the record and shall be made after such further proceedings, if any, as the Operating Committee may order. Based upon such record, the Operating Committee may affirm, reverse or modify, in whole or in part, the decision of the Fee Review Subcommittee. The decision of the Operating Committee shall be in writing, shall be sent to the parties to the proceeding and shall be final.
-(6) Time Limit for Review
-A final decision regarding the disputed CAT Fees by the Operating Committee, or the Fee Review Subcommittee (if there is no review by the Operating Committee), must be provided within 90 days of the date on which the Industry Member filed a written application regarding disputed CAT Fees with the Company pursuant to paragraph (c)(2) of these Fee Dispute Resolution Procedures. The Operating Committee may extend the 90-day time limit under this paragraph (c)(6) at its discretion.
-(7) Miscellaneous Provisions
-(A) Service of Notice
-Any notices or other documents may be served upon the applicant either personally or by leaving the same at its, his or her place of business or by deposit in the United States post office, postage prepaid, by registered or certified mail, addressed to the applicant at its, his or her last known business or residence address.
-(B) Extension of Certain Time Limits
-Any time limits imposed under these Fee Dispute Resolution Procedures for the submission of answers, petitions or other materials may be extended by permission of the Operating Committee. All papers and documents relating to review by the Fee Review Subcommittee or the Operating Committee must be submitted to the Fee Review Subcommittee or Operating Committee, as applicable.
-(8) Agency Review
-Decisions on such CAT Fee disputes made pursuant to these Fee Dispute Resolution Procedures shall be binding on Industry Members, without prejudice to the rights of any such Industry Member to seek redress from the SEC or in any other appropriate forum.
-(9) Payment of Disputed CAT Fees
-(A) Timing of Fee Payment
-An Industry Member that files a written application with the Company regarding disputed CAT Fees in accordance with these Fee Dispute Resolution Procedures is not required to pay such disputed CAT Fees until the dispute is resolved in accordance with these Fee Dispute Resolution Procedures, including any review pursuant to paragraph (c)(8). For the purposes of this paragraph (c)(9), the disputed CAT Fees means the amount of the invoiced CAT Fees that the Industry Member has asserted pursuant to these Fee Dispute Resolution Procedures that such Industry Member does not owe to the Company. The Industry Member must pay any invoiced CAT Fees that are not disputed CAT Fees when due as set forth in the original invoice.
-(B) Interest on Unpaid CAT Fees
-Once the dispute regarding CAT Fees is resolved pursuant to these Fee Dispute Resolution Procedures, if it is determined that the Industry Member owes any of the disputed CAT Fees, then the Industry Member must pay such disputed CAT Fees that are owed as well as interest on such disputed CAT Fees from the original due date (that is, 30 days after receipt of the original invoice of such CAT Fees) until such disputed CAT Fees are paid at a per annum rate equal to the lesser of (i) the Prime Rate plus 300 basis points, or (ii) the maximum rate permitted by applicable law.
-Adopted by SR-FINRA-2017-020 eff. Dec. 1, 2017.
-Selected Notice: 17-39.
+A. Change Release Management Process
+Following publication of version 1.0, changes to this Industry Member Technical Specification will be released as follows:
+• All proposed amendments to the Technical Specifications will be made in accordance with the CAT NMS Plan, including being approved or deemed approved (as applicable) by the CAT NMS, LLC Operating Committee.
+• Prior to the go-live date for any system changes set forth in the Technical Specifications:
+o A new Technical Specifications will be posted to the CAT Public Website, www.catnmsplan.com.
+o A notice will be posted on the CAT NMS Plan Public website with a summary of changes, the go-live date for the changes and links to relevant information.
+o One or more email alerts will be sent to CAT Reporters with a summary of changes set forth in the revised Technical Specifications, the go-live date for the changes and links to relevant information.
+o Industry Members will be permitted to perform testing of the revised Technical Specifications in advance of the go-live date for the changes. [Information on such testing will be set forth in the notices and alerts described above.]
+o As the go-live date approaches, Industry Members will be able to conduct testing and will receive support from the Plan Processor to prepare for production reporting using the revised Technical Specifications format. The revised Technical Specifications will include a summary list of changes as well as a table listing the specific areas of the document where the changes have been made.
+B. Clock Synchronization Requirement
+In previous sections, details are described regarding Order Events and data elements. Timestamp, as one of the required data elements for each order event, must be correctly reported by Industry Members at predefined granularity. This section provides an overview of the corresponding clock synchronization requirements applicable to Industry Members.
+In order to comply with applicable requirements of Clock Synchronization and correctly record the Timestamp fields for order events. Industry Members are required to synchronize Business Clocks at a minimum to within 50 milliseconds of the time maintained by the National Institute of Standards and Technology (NIST) and to maintain such synchronization. Business clocks that are solely used for Manual Order Events or for the time of allocation on Allocation Reports must be synchronized at a minimum to within a one second tolerance.
+The tolerance includes:
+• The difference between the NIST standard and a time provider’s clock;
+• Transmission delay from the source; and
+• The amount of drift in the Participant's clock.
+To ensure the accuracy of timestamps for Reportable Events, Industry Members must document and maintain their synchronization procedures for Business Clocks. Industry Members must keep a log of the time when they synchronize their Business Clocks and the results of the synchronization process. This log should include notice of any time a Business Clock drifts more than the applicable tolerances specified above. Such log must include results for a period of time 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 Rule if less than five years. Industry Members must also certify their compliance with these clock synchronization requirements and report violations according to requirements established by the Operating Committee.
+Any time provider and technology may be used for clock synchronization as long as the Business Clocks are in compliance with the accuracy requirement.
+If additional details are needed, please refer to the Clock Sync User Guide to be published, or to Participants' applicable rules.
+Note: The tolerance for clock synchronization does not impact the amount of time allowed for CAT reporting. CAT does NOT require Industry Members to report order information within 50 milliseconds of receiving an order.
+C. Representative Order Linkages
+The CAT NMS Plan requires that customer orders be linked to representative orders created in firm accounts for the purpose of facilitating the execution of a customer order. This Appendix outlines reporting requirements for creating linkages between customer and representative orders.
+Phase 2a Requirements
+1. Representative Order Reporting
+In Phase 2a, representative orders must be reported to CAT and marked as a representative order. Representative orders are identified using the representativeInd field on New Order events.
+Allowed values for this field include:
+Y Representative order, linkage required
+YS Representative order, linkage required; details in supplement event
+YF Representative order, linkage required in future phase
+YP Representative order, pricing guarantee, linkage not required
+N Not a representative order
+O Options Combined Order
+2. Representative Order Linkages
+In Phase 2a, linkage is required between the representative street side order and the order being represented when the representative order was originated specifically to represent a single order (received from a customer or another broker-dealer) and there is:
+1) an existing direct electronic link in the Industry Member's system between the order being represented and the representative order, and
+2) any resulting executions are immediately and automatically applied to the represented order in the Industry Member's system
+Linkages are required between the customer/clients order and the representative order for both executed and unexecuted orders. Executed orders must also have a link between the Order Fulfillment Event for the customer/client order and the representative order from which the fill came.
+The following fields are used in the linkage process:
+At the Order Level
+• representativeInd indicates if an order was originated to represent a customer/client order
+• aggregatedOrders specifies the original order IDs and quantities being consolidated in the representative order
+At the Order Fulfillment Level
+• orderID contains the firm side order that was used to fill the customer order
+• fulfillmentLinkType indicates whether there is order level and trade level linkage, only trade level linkage (e.g., fill from the pre-existing customer order), or why the firm side details are not present
+Representative Order Marking and Linkage Requirements by Phase
+Single Order Scenarios
+The table below details requirements for both linkage and marking of a Representative Order in Single Order scenarios. These requirements are NOT applicable in situations where an electronic link does not exist between the Industry Member's OMS and EMS. Please refer to Data Dictionary for relevant field values. Pease refer to the CAT Industry Member Reporting Scenarios document for further information on how the relevant field values should be populated for each scenario.
+
+ 
+ Aggregated Order Scenarios
+[Placeholder for Phase 2c. Aggregated Order Reporting will be finalized and included in future version of the specification.]
+D. CAT Date Definitions and Reporting Guidelines
+The following key date terms are used throughout the document for reporting instructions:
+• eventTimestamp: The time of the order handling or execution pursuant to Section 6.8 of the CAT NMS Plan (e.g. origination, receipt, etc., depending on the respective order event). The time is reported as per the calendar date of the order event.
+• date (Linkage Keys): The date used for linkage keys is the date portion of the eventTimestamp (calendar date)10.
+• date (File Name): The date used to create file names is the calendar date for all events in the file. The file must only contain records with the same calendar date as the file name.
+• CAT Trading Day: Trading Day for Industry Members is defined as beginning immediately after 4:15:00PM and no fractions of a second Eastern Time on one trade date and ending at exactly 4:15:00PM and no fractions of a second Eastern Time on the next trading date.
+• CAT Reporting Due By Date: All events that occurred by 4:15PM on one Trading Day must be reported by 8:00AM the following Trading Day.
+Order Event Times and Reporting Deadlines
+The table below illustrates the reporting deadlines for Order Events across multiple calendar days and CAT Trading Days.
+
+ Order IDs must be unique within the same calendar date. In the table above, the orderID in row 1 and 2 are distinct since both orders have a calendar date of 9/12. The Trading Day is not used for determining orderID uniqueness, as illustrated in rows 5 and 6.
+The Trading Day for Industry Members is defined as starting 1 millisecond after 4:15PM on one trade date and ending 4:15PM on the next trade date. As shown in rows 1 and 2, events with a timestamp after 4:15PM (row 2) are considered to be the following trading date and are not due until T+1 at 8:00AM. Alternatively, Industry Members may submit one file one file per calendar day (the orders on rows 1 and 2 can both be submitted on a 9/12 file). The Trading Day only exists to determine the reporting deadline of an event, it does not impact the date used to create linkage or the file name.
+Weekends are excluded from Trading Days. Events from 4:15PM on a Friday to 4:15PM the follow Monday are the same Trading day, but files must be separated by the calendar date (see rows 4, 5, and 6).
+Holidays are also excluded from Trading Days. Hypothetically, if Monday 9/17 were are holiday in the example, the next available Trading Day becomes Tuesday 9/18.
+
+ E. Failure Codes11
+The failure code is a machine-parseable string of why a file or record was rejected.
+Each failure code is divided into a failure category, sub-category and value, joined together by a period.
+<category>.<sub-category>.<value>
+• Category and sub-category are defined as the table below. Each category corresponds to the stage of processing at which a file or record was rejected.
+• Value will be an alphanumeric (12) code that represents a specific error or warning. The list of values will be refined and a complete list of codes and descriptions will be provided.
+
+ A failure code may be used for warnings or errors, distinguished by the severity field in the failure report. The failure code itself does not distinguish between a warning (in which a record is accepted but still shows up in the feedback report) and an error (which causes a record to be rejected).
+A failure description is a human readable field returned with a failure code that informs a user which field failed, the value which was submitted (if applicable to the error), and why it is incorrect. The failure descriptions are specific to the type of field that has a failure and the original value used by the reporter.
+For example, the following failure code tells the user the severity is an error, the failure was identified on an Order Event file during the ingestion stage, and the field originalOrderID is missing from the record.
+
+ The following failure code example was also identified on an Order Event file during the ingestion stage. The description informs the user that the value submitted is invalid as it was more than 40 characters in length.
+
+ Below is a sample of Failure Codes/Descriptions.
+Not that this is not the final list nor a complete list. The code values will be refined to lower granularities.
+
+ F. Glossary
+ +G. Data Dictionary
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
| fn |
+ 1 Customers are defined in SEC Rule 613(j)(3) as: (i) the account holder(s) of the account at a registered broker-dealer originating the order; and (ii) any person from whom the broker-dealer is authorized to accept trading instructions for such account, if different from the account holder(s). + |
| fn |
+ 2 In order to create the linkage key between Industry Member Order Route Event (potentially Order Modify Route Event in 2c) and Participant Order Modified event, a change is planned for future phases of the Participant reporting - adding routingParty, session and routedOrderID to Participant Order Modified event. + |
| fn |
+ 3 Please see FAQ G4 (https://www.catnmsplan.com/faq/#faqManOrd) for additional information. + |
| fn |
+ 4 Note - this document refers to orders received from CAT Reporters as "client orders," and orders received from non-CAT Reporters, including non-US broker-dealers, as "customer orders." + |
| fn |
+ 5 A representative order is an order originated in a firm owned or controlled account for the purpose of working a customer/client order. Please see FAQ F1 (https://www.catnmsplan.com/faq/#faqRepOrd) for additional information. + |
| fn |
+ 6 “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. “Electronic Paired Option Orders” mean electronic option orders that contain both the buy and sell side that is routed to another Industry Member or exchange for crossing and/or price improvement as a single transaction on an exchange. 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. +For more details, please refer to the CAT FAQ K2 (https://www.catnmsplan.com/faq/#faqOpt). + |
| fn |
+ 7 For Industry Members reporting in CSV, the greyed out data elements will take empty columns if not populated. + |
| fn |
+ 8 Note - this document refers to orders received from CAT Reporters as "client order," and orders received from non-CAT Reporters, including non-US broker-dealers, as "customer orders." + |
| fn |
+ 9 Note that the Trading Day definition for Participants is different. It starts on 1 millisecond from 12:00AM of T, and ends at 12:00AM of T+1. + |
| fn |
+ 10 In the scenario when an order event needs to be linked to a prior event on a different date - e.g. modify a GTC order on a prior day - an additional field “priorOrderDate” is reported on the event and will be used in linking. However, it doesn’t impact the eventTimestamp or date in file name of the event itself. + |
| fn |
+ 11 Note that this section provides the structure of how failure codes are generated and concatenated. A final list of specific values and descriptions will be published when finalized. + |
jurisdiction: US
regulatory_authority: US/SEC
content_type: periodic
- document_title: Industry Update on the Consolidated Audit Trail (CAT)
- source: Industry Update
- source_type: Notice
+ document_title: CAT NMS, LLC Advisory Committee
+ document_type: Advisory
+ source: US/SEC/Advisory/LLC Advisory Committee
+ source_type: LLC Advisory Committee
language: English
- pubdate: 2017 effdate: N/A
- Industry Update on the Consolidated Audit Trail (CAT)
-Topic: BATS BZX Industry Update, Consolidated Audit Trail (CAT)
- Compliance User: 9c3d20f0-eb09-4a1d-bdef-a2f9b7200102
+ citation: N/A
+ pubdate: February 28, 2019 effdate: N/A
+ CAT NMS, LLC Advisory Committee
+Topic: CAT NMS Plan, News, CAT NMS, LLC Advisory Committee
+ Compliance User: Broker-dealers
Keywords:
- NMS Plan,
- LLC,
- Rule 613,
+ SRO,
+ CAT NMS Plan -Section 4.3,
+ CAT NMS plan,
+ Role,
+ Member,
+ Organization,
- Overview
-With the approval of the Consolidated Audit Trail (CAT) National Market System (NMS) Plan in 2016, and the selection of Thesys Technologies as the Plan Processor in early 2017, industry timelines for compliance with the CAT are in effect. The CAT NMS Plan requires exchanges, national securities associations, alternative trading systems, and broker-dealers to submit information on order and trade events for listed and OTC equities and listed options to the CAT on a daily basis, in addition to customer data.
-On Thursday, September 7, 2017, at 4:15 PM EST, the CAT NMS, LLC Operating Committee will be hosting a Consolidated Audit Trail webcast to discuss current progress on the CAT. Representatives from the CAT NMS, LLC Operating Committee, as well as the CAT Plan Processor, Thesys CAT, will discuss upcoming milestones, requirements, and the timelines and process for development and delivery of the industry technical specifications for compliance with the CAT reporting requirements. The webcast will be recorded and playback will be available on the CAT NMS website (www.catnmsplan.com). Please see the below details for joining the webcast:
-Toll Free: +1-888-455-5069
-Passcode: 6495498
-- Click here to join the virtual webcast (WebEx) -
-We kindly ask that you share this alert with any interested parties.
-Additional Information
-For additional information on SEC Rule 613 and the CAT NMS Plan generally, please refer to www.catnmsplan.com. For additional information on the CAT compliance rules series applicable to Exchange Members, please refer to the following rule filings:
- - - - -Please also refer to joint BYX, BZX, EDGA and EDGX Regulatory Circular 2017-003. Any questions about the CAT compliance rule series may be referred to the Regulatory Interpretations team at RegInterps@bats.com or (312) 786-8775. Any further questions may be directed to:
-CBOE Bats Trade Desk
-913.815.7001
-tradedesk@bats.com
+The CAT NMS Plan requires the establishment of an Advisory Committee to advise the SROs on the implementation, operation, and administration of the CAT, including items such as technical specifications, reporting functionality, and the possible expansion of the CAT to other securities.
+The SROs have selected the following individuals, as per section 4.13 of the CAT NMS Plan, to serve on the Advisory Committee:
+jurisdiction: United States
- authority: United States Court of Appeals 8th Circuit
- content_type: Case
- document_title: Brown v. Sandals Resorts Intern
- source: Case Law
- pubdate: 2002-03-28T00:00:00 effdate: 2002-03-28T00:00:00
- Brown v. Sandals Resorts Intern
-Topic: Banking Financial Services Review, Record Retention, Legal Standards
- Compliance User: N/A
+
+ jurisdiction: US
+ regulatory_authority: US/SEC
+ content_type: periodic
+ document_title: CAT NMS PLAN Clock Synchronization
+ document_type: Assessment
+ source: US/SEC/Assessment/Clock Synchronization Assessment
+ source_type: Clock Synchronization Assessment
+ language: English
+ citation: N/A
+ pubdate: May 15, 2017 effdate: N/A
+ CAT NMS PLAN Clock Synchronization
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization
+ Compliance User: Broker-dealers
Keywords:
- Legal Standards,
- Retention Policies,
- Statutes of Limitations,
+ File Number 4-698,
+ Consolidated Audit trail,
- United States Court of Appeals, Eighth Circuit Mar 28, 2002
-284 F.3d 949 (8th Cir. 2002)
-McMILLIAN, Circuit Judge.
-Bill and Lynette Brown and Jan and Dorothy Anderson ("appellants") appeal from a final judgment entered in the United States District Court for the District of South Dakota upon a jury verdict in favor of Sandals Resorts International, Sandals Negril, Ltd., Unique Vacations, Inc., and Gorstew, Ltd. ("appellees") on appellants' claim of negligence. See Brown v. Sandals Resorts International, No. 99-4026-KES (D.S.D. Dec. 21, 2000) (denying appellants' motion for judgment as a matter of law or for a new trial) (hereinafter "slip op."). For reversal, appellants argue that the district court erred in submitting to the jury an instruction on appellees' act of God defense, and in refusing to instruct the jury about the adverse inference that could be drawn from appellees' alleged destruction of evidence. For the reasons discussed below, we affirm the judgment of the district court.
-The Honorable Karen E. Schreier, United States District Judge for the District of South Dakota.
-Jurisdiction
-Jurisdiction in the district court was proper based on 28 U.S.C. § 1332. Jurisdiction is proper in this Court based upon 28 U.S.C. § 1291.Appellants filed a timely notice of appeal under Fed.R.App.P. 4(a)(1) (A).
-I. Background
-On February 3, 1998, appellants were vacationing at a Jamaican resort owned and operated by appellees. Bill Brown and Jan Anderson were sitting in lounge chairs on the beach when a palm tree fell and struck them. As a result of the palm tree falling on them, Anderson suffered a disabling tibial plateau fracture, and Brown suffered at least four broken vertebrae, a broken rib, renal contusion, and deep bruising and a large hematoma on his back. Appellants subsequently brought this negligence action against appellees, alleging that appellees were negligent in failing to care for and inspect the tree, that the tree fell because its root system and base were rotten and inadequate to support its weight, and that appellees failed to warn of the tree's hazardous condition.
-On several occasions during the pretrial discovery phase, the district court sanctioned appellees for violations of the discovery rules. On July 21, 2000, appellants moved for Rule 37 sanctions against appellees because appellees failed to disclose photographs taken of the fallen tree and an incident report prepared immediately after the accident. On August 11, 2000, the district court granted in part appellants' motion for sanctions, finding that appellees had "engaged in a pattern of discovery abuse, such as failures to meet deadlines regarding discovery, evasive or nonresponsive answers to interrogatories, failure to answer interrogatories, and refusal to produce documents." The district court then prohibited appellees from introducing at trial any testimony or evidence that had not been previously disclosed.
-The trial was conducted during the week of August 14, 2000. At trial, appellants introduced weather reports suggesting that the wind was not particularly forceful on the day the tree fell, and Brown, Anderson, and their spouses testified that it was not unusually windy. Appellants presented expert testimony from arborist Walter Barrows, who opined that the tree fell because its vascular system was damaged, as evidenced by a large scar on its trunk, and because its root system was inadequate to bear its weight. Barrows concluded that any person using generally accepted inspection principles would have discovered the hazard posed by the tree. Barrows also testified that he was unable to inspect the actual tree because appellees removed and disposed of the tree shortly after it fell, so he relied instead on photographs of the tree taken immediately after it had fallen. Barrows admitted, however, that he did not believe it would have done "any good" for him to conduct an onsite inspection because he was not retained until more than six months after the incident.
-Appellees presented evidence to support their defense that the tree fell as the result of an act of God, and not due to any negligence on their part. The resort's general manager, Baldwin Powell, testified that it was "extremely windy" the night preceding the incident. Another resort guest, Matthew Bakalars, testified that it was very windy the day before the tree fell, and much windier than on previous days. Bakalars also testified that the tops of all of the trees on the beach were moving, causing debris to fall on the beach.
-Appellees introduced expert testimony from Diane Clarke, a landscape consultant from Barbados, who testified that, in her opinion, the incident was the result of an act of God. Clarke testified that she visited the site more than two years after the incident, and discovered the tree's root ball where the tree had fallen. Clarke testified that she conducted a series of tests which indicated that no disease or other biological phenomena caused the tree to fall, that her investigation revealed that the wind was gusting the day of the incident, and that she found no evidence that an act of negligence caused the tree to fall. After ruling out biological factors and negligence, and considering the extreme wind, Clarke testified that the tree's falling could only be attributed to an act of God.
-Clarke testified that she could not preserve the root ball because her business did not operate from Jamaica. She speculated that the resort staff probably would have disposed of it.
-At the close of evidence, appellants moved for judgment as a matter of law on appellees' defense that the tree fell due to an act of God. The district court denied the motion and subsequently instructed the jury on the act of God defense. Appellants proposed a jury instruction on the adverse inference the jury could draw from appellees' alleged destruction of the tree's root ball. The district court rejected this proposed instruction as well, ruling that its instruction on appellees' failure to produce the evidence was sufficient.
-With respect to the act of God defense, the district court instructed the jury, in part, that "The defendants have the burden of proving these issues: (1) [t]hat an act of God occurred; and (2) [t]hat such an act of God was the only legal cause of the palm tree's falling." The court also instructed the jury that "[a]n `Act of God' is defined as any accident, due directly and exclusively to natural causes without human intervention, which by no amount of foresight, pains, or care, reasonably to have been expected could have been prevented."
-Appellants' proposed destruction of evidence instruction stated as follows:
-If a party or its expert witness destroyed or failed to preserve evidence under its or her control, you may infer that that evidence would not have been favorable to such party if you find that the party or expert witness knew or reasonably should have known of the existence of a dispute between the party and another.
-With respect to the failure to produce evidence, the district court instructed the jury as follows:
-If a party has the power to produce a witness or evidence but fails or refuses to produce such a witness or evidence, you may infer that the evidence or the testimony of that witness would not have been favorable to such party. This rule applies if and only if you find the following facts: (1) [t]he relationship between the party and the witness was of a nature whereby with exercise of reasonable diligence such party could have produced such witness, or the party, with the exercise of reasonable diligence, could have produce such evidence; and (2) [a] reasonably prudent person in the same circumstances would have produced such witness or evidence if the party believed the evidence or the testimony of such witness would be favorable; and (3) [n]o reasonable excuse exists for the failure of such party to produce such witness or evidence; and (4) [t]he witness or evidence was not equally available to the adverse party or parties.
-On August 18, 2000, the jury returned a general verdict in favor of appellees, and the district court entered judgment on August 31, 2000. On September 14, 2000, appellants filed a renewed motion for judgment as a matter of law or for a new trial on the grounds that the district court erred in instructing the jury on the act of God defense and in refusing to instruct the jury on the adverse inference it could draw from appellees' alleged destruction of evidence. On December 21, 2000, the district court denied appellants' motion, holding that there was sufficient evidence to support the act of God instruction and that appellants had not been prejudiced by the instruction. See slip op. at 5-6. The district court also held that appellants' proposed destruction of the evidence instruction would have been repetitious and would have unduly emphasized this aspect of appellants' case, and that, in any event, appellants had not been prejudiced by the failure to give this instruction. See id. at 4-5. This appeal followed.
-II. Discussion
-A. Standard of Review
-We review the jury instructions given by a district court for an abuse of discretion. See, e.g., B B Hardware, Inc. v. Hargis Indus., 252 F.3d 1010, 1012-13 (8th Cir. 2001) (emphasizing that "district court has broad discretion in instructing the jury, and jury instructions do not need to be technically perfect or even a model of clarity").
-Our review is limited to whether the jury instructions, taken as a whole, "fairly and adequately represent the evidence and applicable law in light of the issues presented to the jury in a particular case." Ford v. GACS, Inc., 265 F.3d 670, 679 (8th Cir. 2001) (citation omitted) (affirming district court's refusal to submit defendant's proposed jury instructions on mitigation because defendant failed to meet initial burden). In a diversity case, the substance of the jury instructions must fairly and adequately represent the law of the forum state. See id. The jury should receive instructions on issues supported by competent evidence in the record; the trial court is not required to instruct on issues that do not find support in the record. See id. at 679-80. Moreover, even where a jury instruction is erroneously given to the jury, reversal is warranted only where the error affects the substantial rights of the parties. See Phillips v. Collings, 256 F.3d 843, 851-52 (8th Cir. 2001) (affirming ruling of district court, holding no reversible error because defendant "suffered no prejudice from the absence of more detailed instructions"); Burry v. Eustis Plumbing Heating, Inc., 243 F.3d 432, 434 (8th Cir. 2001) (Burry).
-As an initial matter, appellees argued that appellants had failed to preserve their instruction objections for appeal because appellants did not formally object to the instructions at trial. We disagree. Appellants sufficiently made the trial court aware of their position with respect the jury instructions when they moved for judgment as a matter of law at the close of evidence. As this Court has previously stated,
-[Rule 51 of the Federal Rules of Civil Procedure] does not require formality, and it is not important in what form an objection is made or even that a formal objection is made at all, as long as it is clear that the trial judge understood the party's position; the purpose of the rule is to inform the trial judge of possible errors so that he [or she] may have an opportunity to correct them.
-Meitz v. Garrison, 413 F.2d 895, 899 (8th Cir. 1969) (citation omitted) (holding that plaintiff did not waive opportunity to assert error in jury instructions where trial court was fully advised of plaintiff's objections to trial court's jury instructions and defendant was not prejudiced by plaintiff's failure to literally comply with Rule 51).
-B. Act of God Defense Instruction
-Appellants first argue that the district court erred in instructing the jury on the act of God defense. Under South Dakota law, an act of God is defined as "any accident, due directly and exclusively to natural causes without human intervention, which by no amount of foresight, pains, or care, reasonably to have been expected, could have been prevented." Northwestern Bell Telephone Co. v. Henry Carlson Co., 83 S.D. 664, 165 N.W.2d 346, 349 (S.D. 1969) (holding that whether damage was proximately caused by act of God is question of fact for jury to resolve, and that trial judge erred in taking issue away from jury). "An act of God must be the sole proximate cause of damages without concurrent negligent participation of the defendant before the defendant is entitled to a verdict." Id.
-Appellants argue that the evidence at trial was insufficient to establish that the wind was so unusual and extraordinary a manifestation of nature as could not under normal conditions have been reasonably anticipated or expected, as is required for an act of God defense. However, because there was conflicting evidence presented at trial with respect to the wind, this argument is actually a challenge to the weight of the evidence presented, and not to its sufficiency as a matter of law. See id.
-It is axiomatic that "[c]redibility determinations, the weighing of the evidence, and the drawing of legitimate inferences from the facts are jury functions, not those of a judge." See Reeves v. Sanderson Plumbing Prods., Inc., 530 U.S. 133, 150, 120 S.Ct. 2097, 147 L.Ed.2d 105 (2000) (holding that district court was correct to submit case to jury, and court of appeals erred in reversing jury verdict); see also City of Bridgewater v. Morris, Inc.,594 N.W.2d 712, 715 (S.D. 1999) ("It is the jury's responsibility to judge the credibility of the witnesses and the weight to give to the evidence."). It was within the province of the jury to determine the credibility of the evidence that the unusual wind, and not concurrent negligence on the part of appellees, caused the tree to fall. There was ample evidence in the record from which a jury could reasonably find that an act of God — that is, the unusually strong winds — caused the tree to fall. See slip op. at 952. Resort guest Bakalars testified that it was very windy the day before the tree fell, and much windier than it had been on previous days. Resort manager Powell testified that it had been very windy the night before the incident. Expert witness Clarke testified that her investigation led to her conclude that wind caused the tree to fall. Apparently, the jury believed this evidence, and found that appellees were not negligent. See id. at 953.
-Because there was sufficient evidence upon which the jury could determine that an act of God caused the tree to fall, we hold that the district court did not abuse its discretion in instructing the jury on the act of God defense.
-C. Destruction of Evidence Instruction
-Appellants next contend that the district court erred in refusing to give their proposed instruction on the adverse inference that could be drawn from appellees' alleged destruction of evidence by failing to preserve and produce the tree's root ball. Appellants insist that their proposed instruction would not have been repetitious of the failure to produce instruction, and point out that the most relevant South Dakota Pattern Jury Instruction refers to the failure to produce evidence as well as the destruction of evidence. Appellants also argue that they were entitled to such an adverse inference instruction as a sanction for the prejudicial destruction of evidence because they now cannot examine the root ball in order to refute the conclusions of appellees' expert witness.
-South Dakota Pattern Jury Instruction 5-01-02, pertaining to the failure of a party to introduce documentary evidence, suggests the following language:
-If a party has the power to produce evidence but fails or refuses to produce such evidence, you may infer that that evidence would not have been favorable to such party. This rule applies if and only if you find the following facts: (1) [t]he party, with exercise of reasonable diligence, could have produced such evidence; and (2) [a] reasonably prudent person in the same circumstances would have produced such evidence if the party believed that such evidence would be favorable; and (3) [n]o reasonable excuse exists for the failure of such party to produce such evidence; and (4) [t]he evidence was not equally available to the adverse party or parties.
-If documents were destroyed by Defendants pursuant to a formal document destruction policy, in considering whether this is a reasonable excuse for the failure to produce the destroyed documents, you may consider the following factors: (1) [w]hether the record retention policy is reasonable considering the facts and circumstances surrounding the documents; (2) [w]hether lawsuits concerning customer complaints have been filed, the frequency of customer complaints, and the magnitude of such complaints; and (3) [w]hether Defendant instituted its document retention policy in bad faith in an attempt to limit the availability of damaging evidence to potential plaintiffs.
-The district court instructed the jury that it could draw a negative inference from appellees' failure to produce the root ball. See op. at 951-52. When viewed in the light of the instructions as a whole, we cannot say that the district court abused its discretion in refusing to also give the proposed instruction regarding the adverse inference that could be drawn from appellees' alleged destruction of the evidence. The very inference that appellants sought to have the jury draw from their proposed instruction — that appellees' destruction of evidence indicated that the evidence was not favorable to appellees — could have been drawn from the failure to produce instruction that was given by the district court. We hold that the district court did not abuse its discretion in concluding that submitting the proposed instruction to the jury would have been overly repetitious and would have placed undue emphasis on this aspect of appellants' case. See id.at 952; see also Dupre v. Fru-Con Eng'g, Inc., 112 F.3d 329, 335 (8th Cir. 1997) ("Repetitious instructions that place undue emphasis on a certain aspect of a party's case so as to prejudice the jury require reversal.").
-III. Conclusion
-In sum, we hold that the district court did not abuse its discretion in submitting to the jury an instruction on the act of God defense or in refusing to instruct the jury about the adverse inference that could be drawn from appellees' alleged destruction of evidence. The judgment of the district court is affirmed.
-BEAM, Circuit Judge, dissenting.
-In my view, the evidence does not support the act of God affirmative defense instruction given by the district court. Thus, I would remand this case for a new trial. Upon remand, I would strike the answer of Sandals Resorts as a sanction for the contumacious conduct of its lawyer noted by the district court. Thus, I respectfully dissent.
-This is an issue we review de novo. On questions of fact, we defer to the fact-finder, but the sufficiency of the evidence to create an issue of fact is a question of law. Cox v. Miller County R-I Sch. Dist., 951 F.2d 927, 931 (8th Cir. 1991). Accordingly, the court is wrong when it makes the matter a "weight of the evidence" question.
-Reports that it was "very windy" the night before the incident, and that it was "very windy" the day before the tree fell, and "much windier than it had been on previous days" are simply insufficient as a matter of law to justify the act of God defense. Coastal resorts can "reasonably expect" very windy conditions on occasion, given the irregularity of coastal winds and weather, thus even the definition of "act of God" provided in the instant case was not satisfied by the evidence. Under South Dakota case law, an act of God is defined as "any accident, due directly and exclusively to natural causes without human intervention, which by no amount of foresight, pains, or care, reasonably to have been expected, could have been prevented." Northwestern Bell Tel. Co. v. Henry Carlson Co., 83 S.D. 664, 165 N.W.2d 346, 349 (S.D. 1969). Mulder v. Tague, 85 S.D. 544, 186 N.W.2d 884, 886 (S.D. 1971), in passing, deals with the sufficiency of unusualness required for an act of God defense by stating that even though rainfalls in excess of four inches in a twenty-four-hour period had occurred only twice before in South Dakota, the third occurrence at issue in that case was not so unprecedented as to constitute a so-called act of God. Id.
-Other jurisdictions note that "[t]he ordinary force of nature such as winds which are usual at the time and place are conditions which reasonably could have been anticipated and will not relieve from liability the person guilty of the original negligent act." Sky Aviation Corp. v. Colt,475 P.2d 301, 304 (Wyo. 1970). Courts consider whether the natural "occurrence and magnitude should or might have been anticipated, in view of the . . . history of the locality and the existing conditions affecting the likelihood of [the natural occurrence], by a person of reasonable prudence." Keystone Elec. Mfg. Co. v. City of Des Moines, 586 N.W.2d 340, 351 (Ia. 1998) (quotation omitted); see also McCutcheon v. TriCounty Group XV, Inc., 920 S.W.2d 627, 632 n. 2 (Mo.Ct.App. 1996) (holding that act of God defense "is only available where it is `an event in nature so extraordinary that the history of climatic variations in the locality affords no reasonable warning of their coming'" (citation omitted)). The Sandals Resorts, in this case, ought to have been held to a standard of proving that even though the winds were from natural causes, they were of such unusual and extraordinary manifestation of nature that they could not have been anticipated or expected. 1 AmJur 2d, Act of God §§ 2, 5 (1994); Sky Aviation, 475 P.2d at 304.
-It is the defendants' burden in raising the act of God as a defense, to prove that the plaintiffs' damage was caused solely by an act of God. Northwestern Bell, 165 N.W.2d at 350. "[W]here an act of God and the negligence of a defendant concur and proximately cause damage, the defendant is liable as though his negligence alone had caused the damage. . . ." Id.
-In their opening brief and in a motion to supplement the record, the appellants presented information supporting a finding that Sandals Resorts and its lawyer deliberately obstructed discovery in this case. It also appears, from affidavits and other filings in other cases, that this is standard operating procedure for Sandals' counsel in litigation involving the resorts. Based upon this additional information, it is clear to me that the sanctions imposed in this case were insufficient. The district court, as noted by the court's opinion today, found that Sandals' attorney had "engaged in a pattern of discovery abuse, such as failures to meet deadlines regarding discovery, evasive or nonresponsive answers to interrogatories, failure to answer interrogatories, and refusal to produce documents." These transgressions are all the more serious when the site of the incident and the location of evidence is several thousand miles away from the forum.
-At a time when the ethics, civility and professionalism of the bar are under intense scrutiny, the courts cannot permit a "slap on the wrist" to suffice. A more appropriate remedy for this type of conduct would have been to direct liability against the defendants or, at least, to strike the defendants' answer and require trial on a general denial of negligence, causation, liability and damages.
-I dissent.
+May 15, 2017
+Brent J. Fields
+Secretary
+Securities and Exchange Commission
+100 F Street, NE
+Washington, DC 20549-1090
+Re: File Number 4-698
+National Market System Plan Governing the Consolidated Audit Trail Clock Synchronization Assessment
+Dear Mr. Fields:
+In accordance with Section 6.6(a)(ii) of the National Market System Plan Governing the Consolidated Audit Trail (the “CAT NMS Plan” or “Plan”),1 the Operating Committee2 for CAT NMS, LLC respectfully provides the Securities and Exchange Commission (“SEC” or “Commission”) with this assessment of the clock synchronization standard for the Consolidated Audit Trail (“CAT”), including consideration of industry standards based on the type of CAT Reporter, Industry Member and type of system, and recommendation for appropriate amendments based on this assessment.3 This Assessment is divided into four sections: (1) executive summary; (2) description of current clock synchronization requirements under the CAT NMS Plan; (3) description of the CAT Clock Synchronization Survey (the “Survey”), including responses to the Survey; and (4) an assessment of the current clock synchronization requirements based on the analysis of the data collected in the Survey, including whether the current requirements should be amended.
+pubdate: May 15, 2017 effdate: N/A
+ I. Executive Summary
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, Executive Summary
+ Compliance User: Broker-dealers
+ Keywords:
+ CAT NMS Plan - Section 6.6,
+ Participants,
+ CAT Reporting,
+
+ As previously noted, Section 6.6(a)(ii) of the CAT NMS Plan requires that the Participants provide the SEC with an assessment of the clock synchronization standard, including consideration of industry standards based on the type of CAT Reporter, Industry Member and type of system, and a recommendation for appropriate amendments based on this assessment. To prepare this assessment, the Participants sought information regarding Industry Members’ clock synchronization practices through the Survey. This assessment provides a summary of the results of this Survey. Based on an analysis of the results of the Survey as well as information about Participant clock synchronization practices, the Participants do not believe that it is necessary or appropriate to amend the Business Clock synchronization requirements set forth in the Plan at this time. The Participants believe this assessment is consistent with the SEC’s finding that the current 50 milliseconds standard for Industry Members “is acceptable for the initial phase of CAT reporting.”4 The Participants will reassess whether the Business Clock synchronization requirements remain consistent with industry standards – or whether it may be necessary to amend such requirements – in the future as part of the annual assessment required by Section 6.8(c) of the Plan; however, the Participants note that the first annual assessment will occur before the initial phase of Industry Member CAT reporting.
+pubdate: May 15, 2017 effdate: N/A
+ II. Current Clock Synchronization Requirements
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, Current Clock Synchronization Requirements
+ Compliance User: Broker-dealers
+ Keywords:
+ CAT NMS Plan - Section 6.8,
+ Participants,
+ CAT Reporting,
+ Business Clocks,
+ Industry Member,
+ SEC,
+ Clock Synchronization,
+
+ Section 6.8 of the CAT NMS Plan sets forth the clock synchronization requirements related to the CAT for Participants and Industry Members. With regard to Participants, Section 6.8(a)(i) of the Plan requires each Participant to synchronize its Business Clocks at a minimum to within 100 microseconds of the time maintained by the National Institute of Standards and Technology (“NIST”), consistent with industry standards, except for Business Clocks used solely for Manual Order Events. Section 6.8(a)(iii) of the Plan requires each Participant to synchronize its Business Clocks used solely for Manual Order Events at a minimum to within one second of the time maintained by NIST, consistent with industry standards, and maintain such synchronization.
+With regard to Industry Members, Section 6.8(a)(ii) of the Plan requires each Participant to require its Industry Members to synchronize their Business Clocks at a minimum to within 50 milliseconds of the time maintained by NIST, except for Business Clocks used solely for Manual Order Events or the time of allocation on Allocation Reports, and maintain such a synchronization. Section 6.8(a)(iii) of the Plan requires each Participant to require its Industry Members to synchronize their Business Clocks used solely for Manual Order Events at a minimum to within one second of the time maintained by NIST, consistent with industry standards, and maintain such synchronization. Section 6.8(a)(iv) of the Plan requires each Participant to require its Industry Members to synchronize their Business Clocks used solely for the time of allocation on Allocation Reports at a minimum to within one second of the time maintained by NIST, consistent with industry standards, and maintain such synchronization. Each Participant has adopted rules requiring its Industry Members to comply with these clock synchronization requirements.5
+In approving the Plan, the SEC noted that the 50 milliseconds standard was reasonable for the initial implementation of the CAT.6 The SEC stated further that it “believes that a standard of 50 milliseconds for Industry Members will allow regulators to sequence orders and events with a level of accuracy that is acceptable for the initial phases of reporting.”7 Nevertheless, the SEC stated further that it:
+believes that it is appropriate for the Participants to consider the type of CAT Reporter (e.g., Participant, Industry Member), the type of Industry Member (e.g., ATS, small broker-dealer), and type of system (e.g., order handling, post-execution) when establishing appropriate industry standards. The Commission does not believe that one industry standard should apply across all CAT Reporters and systems.8
+Accordingly, the Commission amended Section 6.8(c) of the Plan to state that industry standards for purposes of clock synchronization should be determined based on the type of CAT Reporter, type of Industry Member and type of system. In recognition of the expectation that narrower clock synchronization thresholds may be appropriate for Industry Members, or certain categories or systems thereof, the Commission amended the Plan to require the Participants to provide this assessment of the clock synchronization standards set forth in the Plan.
+pubdate: May 15, 2017 effdate: N/A
+ III. CAT Clock Synchronization Survey
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey
+ Compliance User: Broker-dealers
+ Keywords:
+ Participant,
+ Business Clock Syncronization Practice,
+ CAT NMS plan,
+
+ The Participants determined that the use of a survey was an appropriate method for gaining additional data on Industry Members’ Business Clock synchronization practices to inform this assessment. On April 11, 2017, the Participants released the Survey, which was made available to the public on the CAT NMS Plan’s public website.9 Responses were collected through April 23, 2017. The Participants drafted the Survey in consultation with the Advisory Committee to help ensure that the Survey was designed to seek detailed and meaningful data regarding Business Clock synchronization practices and trends, and industry views regarding potential modifications to the Business Clock synchronization standards set forth in the Plan. When the Survey was posted, the Participants notified their respective members and the Advisory Committee and industry trade associations,10 to encourage a significant and diverse sample size.
+pubdate: May 15, 2017 effdate: N/A
+ A. Overview of CAT Clock Synchronization Survey
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Overview of CAT Clock Synchronization Survey
+ Compliance User: Broker-dealers
+ Keywords:
+ Syncronization Survey,
+ Business Clock,
+
+ The Survey was divided into five main sections: (1) demographic questions; (2) general questions; (3) current clock synchronization practices; (4) changes to Business Clock synchronization practices; and (5) costs. Each of these sections is discussed in greater detail below.
+pubdate: May 15, 2017 effdate: N/A
+ 1. Demographic Questions
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Overview of CAT Clock Synchronization Survey, Demographic Questions
+ Compliance User: Broker-dealers
+ Keywords:
+ CAT NMS plan,
+ Vendors,
+ CAT Reporters,
+ Broker-dealer,
+ Sec Rule 613,
+ Industry Members,
+ FINRA,
+ OATS,
+
+ The first section of the Survey asked that respondents provide their firm name and contact information. The section also asked that respondents, if applicable, identify themselves as a third-party vendor, technology services provider or other entity that is not subject to the CAT NMS Plan, but that provides services to CAT Reporters and maintains synchronized Business Clocks, and to explain their business and systems that contain Business Clocks. To the extent that a respondent was a small broker-dealer, as defined in Rule 613,11 they were asked to identify themselves as such.
+To help the Participants collect information from Industry Members that currently report to the Financial Industry Regulatory Authority’s (“FINRA”) Order Audit Trail System (“OATS”), the Survey asked respondents to identify whether they currently report to OATS and, if so, to identify approximately how many reportable order events they report each month. For firms that are not subject to OATS, the Survey asked that respondents provide a brief explanation of why they are excluded or exempt from OATS, as applicable. Respondents also were asked to provide estimates of the approximate number of orders for NMS Stocks and OTC Equity Securities, and listed options, that they handled in the past month (including orders given to, received by, or originated by, the respondent). Finally, respondents were asked to provide information concerning their business activities, including identifying the types of business activities in which they participate, identifying whether they are a market maker, identifying whether they are an alternative trading system (“ATS”), and identifying the instruments that they trade.
+pubdate: May 15, 2017 effdate: N/A
+ 2. General Questions
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Overview of CAT Clock Synchronization Survey, General Questions
+ Compliance User: Broker-dealers
+ Keywords:
+ CAT Reporter,
+ Business Clock Synchronization Requirements,
+ Survey questions,
+
+ The next section of the Survey included general questions requesting views on whether the Business Clock synchronization requirements set forth in the Plan should vary depending on the type of CAT Reporter, the type of Industry Member and/or the type of system. To the extent that a respondent believed that the requirements should vary, the Survey asked that they explain how and why. Next, the Survey asked if respondents believed that firms voluntarily seek to improve Business Clock synchronization requirements, or if they believed that firms typically avoid changing such standards or practices absent a regulatory requirement to do so. Finally, this section asked that the respondents describe the factors that primarily affect costs related to complying with the Business Clock synchronization requirements and whether such factors vary by system or Industry Member.
+pubdate: May 15, 2017 effdate: N/A
+ 3. Current Clock Synchronization Practices
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Overview of CAT Clock Synchronization Survey, Current Clock Synchronization Practices
+ Compliance User: Broker-dealers
+ Keywords:
+ Survey questions,
+ Survey Information,
+ Business Clock synchronization,
+
+ The next section asked that respondents provide information regarding their current Business Clock synchronization practices. To the extent that respondents currently maintain synchronized Business Clocks, they were asked to identify the types of systems in which such Business Clocks are maintained.12 To collect information on Business Clocks used in different systems, respondents also were asked to provide responses to various questions regarding the systems that they operate that contain Business Clocks. Respondents were asked whether they maintain different synchronization tolerances for Business Clocks used for different systems and, if so, for what types of systems the respondents maintain different tolerances and the tolerance of each respective system. The Survey requested information regarding the technologies that respondents use to maintain Business Clock synchronization, such as: PTP; NTP; PPS; GPS; CDMA; or other. Respondents also had the option of indicating that they “do not know” the technologies that they currently use to maintain Business Clock synchronization.
+Respondents were then asked to provide information regarding their current Business Clock drift tolerances by choosing from the following responses: more than 1 second; 500 milliseconds to 1 second; 50 milliseconds to 499 milliseconds; 1 millisecond to 49 milliseconds; 500 microseconds to 999 microseconds; 1 microsecond to 499 microseconds; and “do not know.” Respondents also were asked if tolerances vary by where a Business Clock is located (e.g., internal broker-dealer data center; third-party data center; exchange co-location). Next, respondents were asked to identify how often they check Business Clock synchronization by choosing from the following responses: once a day; more than once a day, but less than once an hour; once an hour or more, but less than once a minute; once a minute or more, but less than once a second; once a second or more, but less than once a hundredth of a second; more than once a hundredth of a second; or “do not know.” Next, respondents were asked to identify what source they currently use as a “master” clock by identifying: GPS; CDMA; NIST atomic clock; data center-provided time; other vendor or hardware provided time; or “do not know.” To the extent that respondents maintain Business Clock synchronization across geographically disparate systems, they were asked to identify this fact and explain any challenges encountered and costs incurred to maintain such synchronization.
+pubdate: May 15, 2017 effdate: N/A
+ 4. Changes to Business Clock Synchronization Practices
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Overview of CAT Clock Synchronization Survey, Current Clock Synchronization Practices, Changes to Business Clock Synchronization Practices
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ Business Clock Practices,
+
+ Respondents were asked to provide information on how often they assess Business Clock synchronization tolerance and whether this practice varies by the type of Business Clock or system being considered. To collect information regarding changes to synchronization practices, respondents also were asked how often they assess their Business Clock synchronization tolerances and how often they have changed tolerances in the past year. Next, respondents were asked, to the best of their knowledge, how often their Business Clock tolerances are exceeded.
+pubdate: May 15, 2017 effdate: N/A
+ 5. Costs
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Overview of CAT Clock Synchronization Survey, Costs
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ Projected Cost,
+
+ The final section of the Survey sought information regarding the costs to the industry of Business Clock synchronization. This section asked respondents to provide information regarding the initial costs that they incurred (or that they anticipate that they will incur) to comply with the Business Clock synchronization tolerance of 50 milliseconds or 1 second, as applicable. Respondents also were asked to explain any ongoing costs that they will incur to maintain applicable synchronization tolerance and to explain how this response varies by type of Business Clock or system. Respondents also were asked how long it took them (or how long they anticipate that it will take them) to comply with the Business Clock synchronization requirements, and to explain how this response varies by the type of Business Clock or system.
+The next set of questions sought information on the projected costs of further reducing the Business Clock synchronization tolerance. Respondents were asked to describe the costs (initial and ongoing), if any, that they expect to incur if the Business Clock synchronization tolerance is reduced and how these costs vary by type of Business Clock or system. Respondents also were asked how long they anticipate that it will take them to comply with any new Business Clock synchronization tolerances.
+pubdate: May 15, 2017 effdate: N/A
+ B. Assessment of Participants’ Business Clock Synchronization Standards
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Assessment of Participants’ Business Clock Synchronization Standards
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clocks,
+ Participant,
+ Industry Member,
+
+ Although the Participants did not participate in the Survey, which was designed for Industry Members and other firms in the securities industry, the Participants previously assessed their operations and use of Business Clocks to determine an appropriate synchronization threshold to apply to themselves. These assessments occurred in 2015 and 2016.13 Ultimately, the Participants determined that, collectively, they operate pursuant to a Business Clock synchronization of 100 microseconds or less with respect to their electronic systems. The Participants that are exchanges each measured average absolute matching engine clock drift across five business days. The average measured clock drift based on this analysis was approximately 36 microseconds. However, this result was an average and the Participants do not believe that it may be relied upon as a definitive statement that all Participants currently meet a threshold of 36 microseconds. In particular, Participants’ practices vary with respect to the implementation, use and measurement of synchronization. Moreover, Participants’ practices also vary with respect to the frequency with which they check the accuracy of synchronization, so it may be difficult to directly compare the synchronization of one Participant to another. Participants that operate non-electronic systems, such as manual systems operated on trading floors, manual order entry devices and certain other systems, found that they do not operate at a synchronization of 100 microseconds or less. Based on these findings, the Participants proposed, and the Commission adopted, that they be subject to a Business Clock synchronization standard of 100 microseconds of the time maintained by NIST, other than Business Clocks used solely for Manual Order Events (which must comply with a standard of 1 second of the time maintained by NIST). The Participants do not believe that their practices have changed materially since the Plan was adopted.
+pubdate: May 15, 2017 effdate: N/A
+ C. Analysis of Data from Clock Synchronization Survey14
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14
+ Compliance User: Broker-dealers
+ Keywords:
+ broker-dealers,
+ Business Clock Synchronization Practices,
+
+ pubdate: May 15, 2017 effdate: N/A
+ 1. Overview of Respondents and Demographics
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Overview of Respondents and Demographics
+ Compliance User: Broker-dealers
+ Keywords:
+ Participant,
+ Survey,
+ CAT Reporters,
+ OATS,
+ CAT NMS plan,
+ FINRA,
+
+ The Participants received 143 substantially complete responses to the Survey.15 The responses represent the views of a range of firms. Based on the responses, approximately 13% of respondents identified as small broker-dealers that expect to report to the CAT, approximately 60% of respondents identified as large broker-dealers that expect to be CAT reporters, and approximately 27% of respondents indicated that they do not expect to report to the CAT. Of the 143 responses, approximately 23% of respondents indicated that they are an equities market maker and approximately 13% of respondents indicated that they are an options market maker. Approximately 78% of respondents indicated that they currently report to OATS, and approximately 22% indicated that they currently do not report to OATS.16
+With respect to types of business activities, respondents indicated the following: approximately 20% operate an institutional business; approximately 17% operate a retail business; approximately 17% are introducing brokers; approximately 12% engage in proprietary trading; approximately 8% engage in clearing activities; approximately 7% engage in asset management activities; approximately 8% engage in investment banking; approximately 5% provide prime brokerage services; and approximately 6% indicated that they engage in other activities. Approximately 8% of respondents stated that they operate an ATS. Approximately 18% of respondents indicated that they are a third-party vendor, technology services provider or other entity that is not subject to the CAT NMS Plan, but that provides services to CAT Reporters and maintains synchronized Business Clocks (a “Service Provider”). The approximately 18% of respondents that identified as Service Providers indicated that they provide the following functions: back-office processing (approximately 3%); books and records (approximately 4%); clearing (approximately 1%); settlement (approximately 1%); trade order management systems (approximately 5%); trade reporting (approximately 3%); and other17 (approximately 2%).
+The approximately 78% of respondents that indicated that they currently report to OATS provided the following information regarding the approximate number of reportable events that they submit to OATS each month: 0 to 9,999 (approximately 30%); 10,000 to 99,999 (approximately 9%); 100,000 to 2,999,999 (approximately 15%); 3,000,000 to 99,999,999 (approximately 12%); and 100,000,000 or more (approximately 12%). As previously noted, approximately 12% of respondents reported that they are not FINRA members and approximately 10% of respondents indicated that they are excluded or exempt from OATS reporting.
+pubdate: May 15, 2017 effdate: N/A
+ 2. Responses to General Questions
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Responses to General Questions
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+
+ As discussed in greater detail in this section, generally, over half of respondents did not have a view on whether there should be different Business Clock synchronization requirements applicable to different types of businesses or systems. Focusing on the respondents that did have a view, approximately 64% did not believe that there should be different requirements for different types of businesses or systems, versus approximately 36% that believed that there should be different requirements for different types of businesses or systems. However, a majority of respondents that identified as small broker-dealers believed that there should be different Business Clock synchronization standards that apply to both (1) large broker-dealers vs. small broker-dealers (approximately 83% of small broker-dealer respondents), and (2) different types of systems (100% of small broker-dealer respondents). Large broker-dealers and small broker-dealers split on the question of whether firms voluntarily seek to improve their Business Clock synchronization standards or practices, or if firms only change such standards or practices when required to do so by regulation. Large broker-dealer respondents believed that they voluntarily seek to improve such standards or practices, while most small broker-dealer respondents indicated that they change such standards or practices when required to do so. Finally, there is no majority view with respect to how often respondents exceed applicable Business Clock synchronization thresholds, but most firms indicated that they did not know the answer to this question. These findings are discussed in greater detail below.
+pubdate: May 15, 2017 effdate: N/A
+ a. Execution Venues vs. Broker-Dealers
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Responses to General Questions, Execution Venues vs. Broker-Dealers
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ Execution Venues,
+ broker-dealers,
+
+ Approximately 50% of the respondents indicated that they did not have a view on whether there should be different Business Clock synchronization requirements applicable to Execution Venues and broker-dealers. Out of those respondents that did express a view, approximately 66% stated that they did not believe that there should be different Business Clock synchronization requirements applicable to Execution Venues and broker-dealers and approximately 34% stated that they believe that Execution Venues and broker-dealers should be subject to different requirements. Notably, of the respondents that indicated that they operate an ATS, approximately 50% did not believe that different requirements should apply to Execution Venues. Approximately 33% of respondents operating ATSs believed that there should be different requirements that apply to Execution Venues, and approximately 17% of respondents that operate ATSs did not have a view.18
+pubdate: May 15, 2017 effdate: N/A
+ b. Small Broker-Dealers vs. Large Broker-Dealers
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Responses to General Questions, Small Broker-Dealers vs. Large Broker-Dealers
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ broker-dealers,
+
+ A majority of respondents (approximately 52%) indicated that they did not have a view on whether there should be different Business Clock synchronization requirements for CAT Reporters that are small broker-dealers and large broker-dealers. Focusing on those respondents who did express a view, the majority (approximately 68%) did not believe that there should be different requirements applicable to small broker-dealers and large broker-dealers, and approximately 32% of respondents believed that small broker-dealers and large broker-dealers should be subject to different standards. Notably, the respondents that provided a response to this question mostly identified as large broker-dealers (approximately 60%), while approximately 12% identified as small broker-dealers and approximately 28% identified as non-CAT Reporters.
+pubdate: May 15, 2017 effdate: N/A
+ c. Varying Standards by Type of System
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Responses to General Questions, Varying Standards by Type of System
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ broker-dealers,
+
+ A majority of the respondents (approximately 54%) indicated that they did not have a view on whether there should be different Business Clock synchronization requirements for different types of systems. Focusing on the respondents that did express a view, approximately 60% do not believe that there should be different Business Clock synchronization requirements applicable to different types of systems versus approximately 40% of respondents that believed that different requirements should apply to different types of systems. All small broker-dealer respondents that responded to this question, as well as approximately 60% of respondents that operate a retail business and responded to this question, support there being different Business Clock synchronization requirements applicable to different types of systems.
+pubdate: May 15, 2017 effdate: N/A
+ d. Improvements to Business Clock Synchronization Practices
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Responses to General Questions, Improvements to Business Clock Synchronization Practices
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ broker-dealers,
+
+ Respondents split on whether firms voluntarily seek to improve their Business Clock synchronization standards or practices, or avoid changing such standards or practices absent a regulatory requirement to do so. Of the respondents that expressed a view, approximately 27% indicated that firms voluntarily19 seek to improve their Business Clock synchronization standards or practices, approximately 23% indicated that firms did not change their standards or practices absent a regulatory requirement to do so,20 and approximately 18% indicated that other factors cause them to update their Business Clock synchronization standards or practices.21 Approximately 31% of respondents indicated that they did not have a view on whether firms voluntarily seek to improve their Business Clock synchronization standards or practices, or avoid changing such standards or practices absent a regulatory requirement to do so.
+Of the respondents that identified as large broker-dealers, the largest number of responses (approximately 42%) indicated that respondents voluntarily seek to improve their Business Clock synchronization standards or practices. The opposite was true of small broker-dealer respondents, as the majority of such respondents (approximately 75%) indicated that they change their Business Clock synchronization standards or practices when a regulatory obligation requires them to do so.
+pubdate: May 15, 2017 effdate: N/A
+ e. Exceeding Required Synchronization Tolerances
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Responses to General Questions, Exceeding Required Synchronization Tolerances
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ broker-dealers,
+ Business Clock Tolerance,
+
+ Approximately 46% of respondents that expressed a view indicated that they did not know, on average, how often their Business Clock synchronization tolerances are exceeded. Approximately 3% of respondents stated that their response depends on the type of Business Clock or system being considered. Other respondents indicated that their Business Clock tolerances are exceeded: multiple times per day (approximately 5%); monthly (approximately 15%); semiannually (approximately 16%); and less than annually (approximately 15%).
+Respondents that identified as large broker-dealers reported that, on average, their Business Clock synchronization tolerances are exceeded: multiple times per day (approximately 8%); monthly (approximately 14%); semiannually (approximately 13%); and less than annually (approximately 27%). Approximately 3% of large broker-dealer respondents indicated that their response depends on the type of Business Clock or system considered and approximately 35% of large broker-dealer respondents did not know how often their synchronization tolerances are exceeded. Small broker-dealer respondents indicated that, on average, their synchronization tolerances are exceeded: monthly (approximately 27%); semiannually (approximately 33%); and less than annually (approximately 7%). No small broker-dealer respondents reported exceeding thresholds multiple times per day or at different times depending on the type of Business Clock or system being considered. Approximately 33% of small broker-dealer respondents did not know how often their synchronization tolerances are exceeded.
+pubdate: May 15, 2017 effdate: N/A
+ 3. Costs
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Costs
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ Costs Requirements,
+
+ Respondents generally identified software and/or hardware as the primary factors affecting costs for complying with the Business Clock synchronization requirements, with maintenance and compliance as the second and third greatest factors. The majority of respondents who expressed a view believed that such cost drivers vary by type of system. This view was generally consistent regardless of the type or size of respondents, except that small broker-dealer respondents were evenly split (i.e., 50% believed that cost drivers varied by system and 50% believed that cost drivers did not vary by system). Focusing on respondents who knew their initial costs of compliance (i.e., those that did not respond “do not know”), the majority (approximately 70%) stated that their initial costs of complying with the Business Clock synchronization requirements were less than $100,000. All small broker-dealer respondents who knew their initial compliance costs reported that such costs were below $100,000. Conversely, approximately 30% large broker-dealer respondents who knew their initial compliance costs indicated that such costs were over $100,000. Respondents provided a broad range of responses regarding the time it took to comply with the Business Clock synchronization requirements—responses ranged from less than one month to more than six months. These findings are discussed in greater detail below.
+pubdate: May 15, 2017 effdate: N/A
+ a. Factors Affecting Compliance Costs
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Costs, Factors Affecting Compliance Costs
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ Compliance Costs,
+
+ Approximately 35% of respondents who expressed a view indicated that software and hardware primarily affect costs related to complying with the Business Clock synchronization requirements. Maintenance and compliance were the second and third largest cost drivers, with approximately 21% and 20% of respondents indicating that these reflected their greatest costs, respectively. When asked whether factors affecting costs of complying with the Business Clock synchronization requirements vary by system, approximately 46% of respondents stated that they did not have a view, 36% of respondents indicated that they thought that such factors did vary by type of system, and approximately 18% of respondents indicated that they thought that such factors did not vary by system.
+pubdate: May 15, 2017 effdate: N/A
+ b. Initial Compliance Costs
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Costs, Initial Compliance Costs
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ Compliance Costs,
+ Business Clock Synchronization Threshold,
+ Large Broker-Dealers,
+ Service Providers,
+ OATS Reporters,
+
+ With respect to the costs incurred by respondents to comply with the initial Business Clock synchronization thresholds set forth in the Plan, approximately 35% of respondents did not know their initial compliance costs. Approximately 44% of respondents indicated that their initial compliance costs were less than $100,000, approximately 9% indicated that their initial compliance costs were between $100,000 and $500,000, and approximately 6% indicated that their initial compliance costs were more than $500,000. Approximately 5% of respondents indicated that they incurred other costs22 and approximately 1% indicated that costs depended on the type of Business Clock or system. Notably, no respondents that identified as small broker-dealers indicated that they incurred initial costs more than $100,000.
+Respondents that identified as large broker-dealers indicated that they incurred the following initial compliance costs: no costs (approximately 5%); less than $100,000 (approximately 45%); $100,000 to $500,000 (approximately 12%); and more than $500,000 (approximately 9%). Approximately 29% of large broker-dealer respondents did not know what costs they incurred. Approximately 53% of respondents that identified as small broker-dealers indicated that they incurred initial compliance costs of less than $100,000. Approximately 6% of small broker-dealer respondents reported that their costs varied depending on the specific Business Clock or system, approximately 6% indicated that they incurred other costs beyond what was listed in the Survey, and approximately 35% did not know what initial compliance costs they incurred.
+Respondents that identified themselves as Service Providers, OATS reporters and ATSs indicated that they incurred a range of different costs to comply with the initial Business Clock synchronization requirements. Respondents that identified as Service Providers indicated the following initial compliance costs: less than $100,000 (approximately 36%); $100,000 to $500,000 (approximately 9%); and more than $500,000 (approximately 9%). Approximately 45% of Service Providers did not know their initial compliance costs. Respondents that identified as OATS reporters indicated the following initial compliance costs: less than $100,000 (approximately 50%); $100,000 to $500,000 (approximately 10%); more than $500,000 (approximately 8%). Approximately 32% of respondents that identified as OATS reporters did not know what initial implementation costs they incurred (or would incur) to comply with the initial thresholds. Finally, respondents that indicated that they operate an ATS provided the following responses regarding initial implementation costs that they incurred (or would incur) to comply with the initial thresholds: less than $100,000 (approximately 25%); $100,000 to $500,000 (approximately 17%); and more than $500,000 (approximately 33%). Approximately 25% of respondents operating ATSs did not know their initial implementation costs.
+pubdate: May 15, 2017 effdate: N/A
+ c. Time to Comply with Initial Thresholds
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Costs, Time to Comply with Initial Thresholds
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ Time Estimate,
+ Large Broker-Dealers,
+
+ Respondents that provided a time estimate indicated that it took (or would take) them the following amount of time to comply with the initial Business Clock synchronization thresholds set forth in the Plan: less than 1 month (approximately 30%); 1 to 2 months (approximately 5%); 2 to 6 months (approximately 12%); and more than 6 months (approximately 9%). Approximately 11% of respondents indicated it would take them some “other” amount of time,23 and approximately 33% of respondents reported that they did not know how long it took (or would take) them to comply with the initial synchronization thresholds.
+Respondents that identified as large broker-dealers indicated that it took (or would take) them the following amount of time to comply with the initial thresholds: less than 1 month (approximately 34%); 1 to 2 months (approximately 6%); 2 to 6 months (approximately 18%); and more than 6 months (approximately 12%).24 Approximately 18% of large broker-dealer respondents could not provide a time estimate and approximately 11% stated it would take them some other amount of time. Respondents identifying as small broker-dealers provided the following time estimates: less than 1 month (approximately 29%); and 2 to 6 months (approximately 6%). Approximately 6% of small broker-dealer respondents indicated that it would take them some other amount of time. Most small broker-dealer respondents (approximately 59%) could not provide a time estimate.
+pubdate: May 15, 2017 effdate: N/A
+ 4. Changes to Business Clock Synchronization Threshold
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+
+ Respondents generally indicated that implementation time, initial costs and ongoing costs, all increased as the Business Clock synchronization threshold became narrower. Responses also indicated that the implementation time, initial costs and ongoing costs to comply with any new threshold would vary greatly across different types or sizes of firms, as well as within firms of the same size or type. These findings are discussed in greater detail below.
+pubdate: May 15, 2017 effdate: N/A
+ a. General Findings
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, General Findings
+ Compliance User: Broker-dealers
+ Keywords:
+ Implementation Time,
+ Business Clock Synchronization Threshold,
+ Initial Costs,
+ Ongoing Costs,
+ Voluntary Assessments,
+
+ Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, General Findings, Implementation Time
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Requirement,
+ Business Clock Synchronization Threshold,
+
+ Approximately 30% of respondents stated that they could not determine how much time it would take for them to comply with any new Business Clock synchronization requirement (e.g., 5 milliseconds, 1 millisecond, 100 microseconds or 500 microseconds). Approximately 20% of respondents indicated that it would take no time to comply with new thresholds of 5 milliseconds or 1 millisecond, and 13.5% of respondents indicated that it would take them no time to comply with new thresholds of 100 microseconds or 500 microseconds. However, approximately 35% of respondents stated that it would take them between 1 and 11 months to comply with any of the new tolerances noted in the Survey.
+Notably, the data did not reflect a substantial difference in implementation times if the Business Clock synchronization threshold was changed to 5 milliseconds or 1 millisecond. With respect to a threshold of 5 milliseconds, approximately 92% of respondents indicated that it would take them 1 year or less to implement the change, and approximately 7% indicated that it would take them 1 to 2 years to implement the change. With respect to a threshold of 1 millisecond, approximately 95% of respondents indicated that it would take them 1 year or less to implement the change, and approximately 5% indicated that it would take them 1 to 2 years to implement the change. Approximately 70% of respondents indicated that it would take them 1 year or less to implement a change to a threshold of 100 microseconds, approximately 25% indicated it would take them 1-2 years to implement such change, and approximately 5% indicated it would take them more than 2 years to implement such change.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, General Findings, Initial Costs
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+
+ The survey sought information concerning the initial costs that respondents would incur should they be required to comply with new Business Clock synchronization thresholds. Approximately 20% of respondents indicated that they would not incur any initial costs to comply with potential new thresholds of 5 milliseconds or 1 millisecond, and approximately 10% of respondents indicated that they would not incur any initial costs to comply with new thresholds of 100 microseconds or 500 microseconds. Approximately 20% of respondents stated that they would incur initial costs between $1,000 and $499,999 to comply with any new threshold (i.e., 5 milliseconds, 1 millisecond, 100 microseconds or 500 microseconds). Many respondents (approximately 35%) did not know what initial costs they would incur to comply with any new threshold.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, General Findings, Ongoing Costs
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+
+ With respect to estimated ongoing costs incurred by respondents to maintain new Business Clock synchronization thresholds (i.e., 5 milliseconds, 1 millisecond, 100 microseconds or 500 microseconds), respondents provided the following information. Approximately 15% of respondents stated that they would not incur any ongoing costs to comply with any new tolerance. Approximately 25% of respondents indicated that they would incur ongoing annual costs between $1,000 and $99,000 to comply with the new tolerances. Only approximately 2% of respondents indicated that their ongoing annual costs to comply with any of the new tolerances would be prohibitive. Approximately 40% of respondents did not know what ongoing annual costs they would incur to comply with any new tolerances.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, General Findings, Voluntary Assessments and Changes to Tolerances
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Requirement,
+ Business Clock Synchronization Threshold,
+ Business Clock Synchronization Practices,
+ broker-dealers,
+ Large Broker-Dealer,
+ Small Broker-Dealer,
+ Business Clock Synchronization Tolerance,
+
+ Nearly half of respondents (approximately 49%) reported that they assess their Business Clock synchronization practices daily. Other respondents indicated that they assess their synchronization practices: monthly (approximately 1%); weekly (approximately 4%); quarterly (approximately 4%); and yearly (approximately 6%). Approximately 16% of respondents indicated that they assess their synchronization practices at other intervals, and approximately 3% stated that the frequency of their assessments depends on the type of Business Clock or system being considered. Approximately 17% of respondents did not know how often they assess their synchronization practices.
+Respondents that identified as large broker-dealers stated that they assess their synchronization practices: daily (approximately 53%); weekly (approximately 4%); quarterly (approximately 6%); and annually (approximately 7%). No large broker-dealer respondents reported assessing their practices monthly. Approximately 18% of large broker-dealer respondents stated that they assess their synchronization practices at other intervals, and approximately 1% indicated that their practices depend on the Business Clock or system being considered. Approximately 11% of large broker-dealer respondents did not know how often they assess their synchronization practices. Respondents that identified as small broker-dealers reported that they assess their synchronization practices: daily (approximately 53%); monthly (approximately 12%); and annually (approximately 6%). No small broker-dealer respondents indicated that they assess their practices weekly, quarterly or at different intervals depending on the type of Business Clock or system considered. Approximately 12% of small broker-dealer respondents indicated that they assess their synchronization practices at other intervals. Approximately 18% of small broker-dealer respondents did not know how often they assess their synchronization practices.
+The Survey also asked respondents how often they changed their Business Clock synchronization tolerances in the past year. Overall, in the past year, approximately 38% of respondents changed their synchronization tolerances 1 time, approximately 7% changed their synchronization tolerances 2 to 5 times, and approximately 1% changed their synchronization tolerances 6 to 10 times. Approximately 19% of respondents stated that they changed their tolerances a different number of times not indicated in the Survey and approximately 1% stated that changes depended on the type of Business Clock or system being considered. Approximately 35% of respondents did not know how often they changed their tolerances in the past year.
+Trends with respect to changing synchronization tolerances were not consistent across large and small broker-dealers. Large broker-dealer respondents indicated that in the past year they changed tolerances: 1 time (approximately 49%); 2 to 5 times (approximately 6%); and 6 to 10 times (approximately 1%). Approximately 18% of large broker-dealers changed their tolerances a number of times not indicated in the Survey. No large broker-dealer respondents stated that changes to tolerances in the past year depended on the type of Business Clock or system being considered. Approximately 26% of large broker-dealer respondents did not know how often they changed their tolerances in the past year. Small broker-dealer respondents reported that in the past year they changed tolerances: 1 time (approximately 18%); and 2 to 5 times (approximately 18%). No small broker-dealer respondents reported changing their tolerances 6 to 10 times in the past year. Approximately 18% of small broker-dealer respondents stated that changes to tolerances in the past year depended on the type of Business Clock or system, and approximately 18% changed their tolerances a number of times not indicated in the survey. Approximately 41% of small broker-dealer respondents did not know how often they changed their tolerances in the past year.
+pubdate: May 15, 2017 effdate: N/A
+ b. Findings Related to Specific Thresholds
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, Findings Related to Specific Thresholds
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ 5 milliseconds,
+ 1 millisecond,
+ 500 microseconds,
+ 100 microseconds,
+
+ This section provides a more detailed discussion of the results described above in Section III.C.4.a. In particular, this section discusses the implementation time, initial cost and ongoing cost of each potential new threshold noted in the Survey (i.e., 5 milliseconds, 1 millisecond, 100 microseconds or 500 microseconds).
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, Findings Related to Specific Thresholds, 5 milliseconds
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ 5 milliseconds,
+ broker-dealers,
+ Large Broker-Dealer,
+ Small Broker-Dealer,
+
+ With respect to a possible 5 milliseconds Business Clock synchronization threshold, respondents provided the following information. In terms of the potential time to comply with a 5 milliseconds threshold, approximately 21% of respondents stated that it would take no time for them to comply with such threshold and approximately 5% of respondents stated it would take less than 1 month. Approximately 14% of respondents indicated that it would take between 1 and 2 months, approximately 4% of respondents indicated it would take between 3 and 5 months and approximately 21% of respondents indicated that it would take between 6 and 11 months, to comply with the lower threshold. Approximately 4% of respondents stated that it would take 1 to 1.5 years to comply with the lower threshold. Approximately 30% of respondents stated that they did not know how long it would take to comply with the threshold.
+Approximately 29% of large broker-dealers providing a response to this question stated that it would take them 6 to 11 months to comply with the lower threshold and approximately 23% stated that they could comply in no time. Approximately 23% of large broker-dealer respondents did not know how long it would take them to comply. Other large broker-dealer respondents provided responses that were spread across different time periods. With respect to small broker-dealer respondents, approximately 43% could not estimate how long it would take them to comply with a lower threshold. Approximately 29% of small broker-dealer respondents indicated that they could comply in no time, approximately 14% stated that they could comply in 1 to 2 months, and approximately 14% stated that they could comply in 6 to 11 months. Respondents that operate ATSs reported the following estimated initial implementation times: no time (approximately 18%); 3 to 5 months (approximately 17%); and 6 to 11 months (approximately 67%).
+In terms of initial costs to comply with a 5 milliseconds threshold, approximately 25% of respondents stated that they would incur no initial costs to comply with the threshold; however, the majority of these responses (approximately 71%) were from large broker-dealers. Another approximately 36% of respondents indicated that they did not know what initial costs they would incur to comply with a 5 milliseconds threshold. Other respondents indicated the following estimated initial compliance costs: $1 to $999 (approximately 4%); $1,000 to $9,999 (approximately 5%); $10,000 and $99,999 (approximately 9%); $100,000 and $499,999 (approximately 9%); $500,000 and $999,999 (approximately 5% of respondents—all large broker-dealers); and $1 million to $1.99 million (approximately 5% of respondents—all large broker-dealers). Approximately 2% of respondents indicated that a 5 milliseconds threshold would be cost prohibitive from an initial costs standpoint.
+The majority of respondents providing information on initial implementation costs identified as large broker-dealers (approximately 63%). Large broker-dealer respondents reported the following costs to comply with the lower threshold: $0 (approximately 29%); $1 to $999 (approximately 3%); $1,000 to $9,999 (approximately 3%); $10,000 to $99,999 (approximately 9%); $100,000 to $499,999 (approximately 6%); $500,000 to $999,999 (approximately 9%); and $1 million to $1.99 million (approximately 9%). One large broker-dealer respondent said that the initial costs of compliance would be prohibitive. Approximately 31% of large broker-dealer respondents could not estimate their initial costs to comply with a 5 milliseconds threshold. Small broker-dealer respondents reported the following initial costs to comply with the lower threshold: $0 (approximately 14%); $1,000 to $9,999 (approximately 14%); $10,000 to $99,999 (approximately 14%); and $100,000 to $499,999 (approximately 14%). Approximately 43% of small broker-dealer respondents could not estimate their initial costs to comply with the lower threshold. Respondents that operate ATSs estimated the following initial implementation costs: $0 (approximately 17%); $100,000 to $499,999 (approximately 17%); $500,000 to $999,999 (approximately 33%); and $1 million to $1.99 million (approximately 17%). Approximately 17% of respondents operating ATSs did not know their initial costs.
+In terms of ongoing costs to comply with a 5 milliseconds threshold, approximately 17% of respondents reported an estimated cost of $0 and approximately 38% of respondents could not estimate ongoing costs. Other respondents reported the following costs: $1 to $999 (approximately 4%); $1,000 to $9,999 (approximately 10%); $10,000 to $99,999 (approximately 19%); $100,000 to $499,999 (approximately 4%); $500,000 to $999,999 (approximately 4%); and $1 million to $1.99 million (approximately 2%). Approximately 2% of respondents stated that ongoing costs would be prohibitive.
+The majority of responses regarding estimated ongoing costs (approximately 63%) were from large broker-dealers. Large broker-dealers indicated the following ongoing costs: $0 (approximately 18%); $1,000 to $9,999 (approximately 9%); $10,000 to $99,999 (approximately 24%); $100,000 to $499,999 (approximately 3%); $500,000 to $999,999 (approximately 6%); and $1 million to $1.99 million (approximately 3%). Approximately 3% of large broker-dealer respondents stated that ongoing costs to comply with the lower threshold would be prohibitive. Half of the small broker-dealers that responded to this question could not estimate ongoing costs of compliance. Other small broker-dealer responses were split as follows: $0 (approximately 17%); $1,000 to $9,999 (approximately 17%); and $10,000 to $99,999 (approximately 17%). Respondents that operate ATSs reported the following estimated ongoing costs: $10,000 to $99,999 (approximately 50%); $100,000 to $499,999 (approximately 17%); and $500,000 to $999,999 (approximately 17%). Approximately 17% of respondents operating ATSs could not estimate ongoing costs of compliance.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, Findings Related to Specific Thresholds, 1 millisecond
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ 1 millisecond,
+ broker-dealers,
+ Large Broker-Dealer,
+ Small Broker-Dealer,
+
+ Approximately 28% of respondents reported that they did not know how long it would take them to comply with a 1 millisecond threshold. Other respondents reported the following time estimates: no time (approximately 21%); less than 1 month (approximately 8%); 1 to 2 months (approximately 6%); 3 to 5 months (approximately 11%); 6 to 11 months (approximately 21%); 1 to 1.5 years (approximately 4%); and 1.5 to 1.99 years (approximately 2%).
+Most of the respondents providing implementation time estimates identified as large broker-dealers (approximately 66% of the respondents). The large broker-dealer respondents provided the following implementation times: no time (approximately 23%); less than 1 month (approximately 8%); 1 to 2 months (approximately 3%); 3 to 5 months (approximately 14%); 6 to 11 months (approximately 23%); 1 to 1.5 years (approximately 6%); and 1.5 to 1.99 years (approximately 3%). Approximately 20% of large broker-dealer respondents could not estimate an implementation time to comply with the lower threshold. Approximately 33% of small broker-dealer respondents could not estimate an implementation time to comply with the lower threshold and approximately 16% stated that implementation time was unknown. Other small broker-dealer respondents provided the following implementation time estimates: no time (approximately 17%); 1 to 2 months (approximately 17%); and 6 to 11 months (approximately 17%). Respondents operating ATSs indicated the following implementation time estimates: no time (approximately 29%); 3 to 5 months (approximately 14%); and 6 to 11 months (approximately 57%).
+With respect to initial costs to comply with a 1 millisecond threshold, approximately 20% of respondents stated that they would incur no initial costs. Other respondents indicated the following estimated initial compliance costs: $1 to $999 (approximately 4%); $1,000 to $9,999 (approximately 4%); $10,000 and $99,999 (approximately 11%); $100,000 and $499,999 (approximately 9%); $500,000 and $999,999 (approximately 11%); and $1 million to $1.99 million (approximately 4%). Approximately 2% of respondents indicated that the initial costs of complying with a 1 millisecond threshold would be prohibitive. Approximately 35% of respondents could not estimate their initial compliance costs.
+Most of the respondents providing initial cost estimates were large broker-dealers (approximately 67%). Large broker-dealer respondents indicated the following initial costs of compliance: $0 (approximately 25%); $1,000 to $9,999 (approximately 3%); $10,000 to $99,999 (approximately 14%); $100,000 to $499,999 (approximately 6%); $500,000 to $999,999 (approximately 14%); and $1 million to $1.99 million (approximately 6%). One large broker-dealer said that the initial costs of compliance would be prohibitive. Approximately 31% of large broker-dealer respondents could not estimate their initial costs to comply with a 1 millisecond threshold. Small broker-dealer respondents reported the following initial costs to comply with the lower threshold: $0 (approximately 17%); $1 to $999 (approximately 17%); $10,000 to $99,999 (approximately 17%); and $100,000 to $499,999 (approximately 17%). Approximately 33% of small broker-dealer respondents could not estimate their initial costs to comply with the lower threshold. Respondents operating ATSs estimated the following initial implementation costs: $0 (approximately 17%); $100,000 to $499,999 (approximately 17%); $500,000 to $999,999 (approximately 33%); and $1 million to $1.99 million (approximately 17%). Approximately 17% of respondents operating ATSs did not know their initial costs.
+With respect to estimated ongoing costs to comply with a 1 millisecond threshold, approximately 17% of respondents reported an estimated cost of $0 and approximately 38% of respondents could not estimate ongoing costs. Other respondents reported the following costs: $1 to $999 (approximately 4%); $1,000 to $9,999 (approximately 10%); $10,000 to $99,999 (approximately 17%); $100,000 to $499,999 (approximately 6%); $500,000 to $999,999 (approximately 4%); and $2 million to $4.99 million (approximately 2%). Approximately 2% of respondents stated that ongoing costs would be prohibitive.
+The majority of responses regarding estimated ongoing costs (approximately 67%) were from large broker-dealers. Large broker-dealers indicated the following ongoing costs: $0 (approximately 17%); $1,000 to $9,999 (approximately 9%); $10,000 to $99,999 (approximately 23%); $100,000 to $499,999 (approximately 6%); $500,000 to $999,999 (approximately 6%); and $2 million to $4.99 million (approximately 2%). Approximately 3% of large broker-dealer respondents stated that ongoing costs to comply with the lower threshold would be prohibitive. Approximately 40% of small broker-dealer respondents could not estimate ongoing costs of compliance. Other responses were as follows: $0 (approximately 20%); $1,000 to $9,999 (approximately 20%); and $10,000 to $99,999 (approximately 20%). Respondents operating ATSs reported the following estimated ongoing costs: $10,000 to $99,999 (approximately 50%); $100,000 to $499,999 (approximately 17%); and $500,000 to $999,999 (approximately 17%). Approximately 17% of respondents operating ATSs could not estimate ongoing costs of compliance.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, Findings Related to Specific Thresholds, 500 microsecond
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ 500 microseconds,
+ broker-dealers,
+ Large Broker-Dealer,
+ Small Broker-Dealer,
+
+ Approximately 30% of respondents reported that they did not know how long it would take them to comply with a 500 microseconds threshold. Other respondents reported the following time estimates: no time (approximately 15%); less than 1 month (approximately 2%); 1 to 2 months (approximately 11%); 3 to 5 months (approximately 8%); 6 to 11 months (approximately 13%); 1 to 1.5 years (approximately 8%); and 1.5 to 1.99 years (approximately 4%).
+Most of the respondents providing implementation time estimates identified as large broker-dealers (approximately 66% of the respondents). The large broker-dealers provided the following implementation times: no time (approximately 14%); 1 to 2 months (approximately 11%); 3 to 5 months (approximately 11%); 6 to 11 months (approximately 17%); 1 to 1.5 years (approximately 9%); and 1.5 to 1.99 years (approximately 6%). Approximately 20% of large broker-dealer respondents could not estimate an implementation time to comply with the lower threshold. Small broker-dealer respondents provided the following implementation time estimates: no time (approximately 33%); 1 to 2 months (approximately 17%); and 6 to 11 months (approximately 17%). Approximately 33% of small broker-dealer respondents could not estimate an implementation time to comply with the lower threshold. Respondents operating ATSs reported the following estimated initial implementation times: no time (approximately 17%); 3 to 5 months (approximately 17%); and 6 to 11 months (approximately 50%). Approximately 17% of respondents that operate ATSs could not estimate their initial implementation costs.
+With respect to initial costs to comply with a 500 microseconds threshold, approximately 15% of respondents stated that they would incur no initial costs. Other respondents indicated the following estimated initial compliance costs: $1,000 to $9,999 (approximately 5%); $10,000 and $99,999 (approximately 7%); $100,000 and $499,999 (approximately 13%); $500,000 and $999,999 (approximately 2%); $1 million to $1.99 million (approximately 9%); $2 million to $4.99 million (approximately 5%); and $5 million or more (approximately 4%). Approximately 2% of respondents indicated that the initial costs of complying with a 500 microseconds threshold would be prohibitive. Approximately 38% of respondents could not estimate their initial compliance costs.
+Most of the respondents providing initial cost estimates were large broker-dealers (approximately 67%). Large broker-dealer respondents indicated the following initial costs of compliance: $0 (approximately 16%); $10,000 to $99,999 (approximately 8%); $100,000 to $499,999 (approximately 16%); $500,000 to $999,999 (approximately 3%); $1 million to $1.99 million (approximately 14%); $2 million to $4.99 million (approximately 5%); and $5 million or more (approximately 5%). One large broker-dealer said that the initial costs of compliance would be prohibitive. Approximately 27% of large broker-dealer respondents could not estimate their initial costs to comply with a 500 microseconds threshold. Small broker-dealer respondents reported the following initial costs to comply with the lower threshold: $0 (approximately 17%); $1,000 to $9,999 (approximately 17%); $10,000 to $99,999 (approximately 17%); and $100,000 to $499,999 (approximately 17%). Approximately 33% of small broker-dealer respondents could not estimate their initial costs to comply with the lower threshold. Respondents operating ATSs estimated the following initial implementation costs: $0 (approximately 14%); $100,000 to $499,999 (approximately 14%); $1 million to $1.99 million (approximately 43%); and $10 million to $20 million (approximately 14%). Approximately 14% of respondents operating ATSs did not know their initial costs.
+With respect to estimated ongoing costs to comply with a 500 microseconds threshold, approximately 12% of respondents reported an estimated cost of $0 and approximately 45% of respondents could not estimate ongoing costs. Other respondents reported the following costs: $1 to $999 (approximately 4%); $1,000 to $9,999 (approximately 2%); $10,000 to $99,999 (approximately 24%); $100,000 to $499,999 (approximately 4%); $500,000 to $999,999 (approximately 4%); $1 million to $1.99 million (approximately 2%); and $2 million to $4.99 million (approximately 2%). Approximately 2% of respondents stated that ongoing costs would be prohibitive.
+The majority of responses regarding estimated ongoing costs (approximately 67%) were from large broker-dealers. Large broker-dealers indicated the following ongoing costs: $0 (approximately 12%); $1,000 to $9,999 (approximately 3%); $10,000 to $99,999 (approximately 29%); $100,000 to $499,999 (approximately 6%); $500,000 to $999,999 (approximately 6%); $1 million to $1.99 million (approximately 3%); and $2 million to $4.99 million (approximately 3%). Approximately 3% of large broker-dealer respondents stated that ongoing costs to comply with the lower threshold would be prohibitive and approximately 36% of large broker-dealer respondents stated that ongoing costs were unknown. Small broker-dealer respondents reported the following ongoing costs: $0 (approximately 20%); $1 to $999 (approximately 20%); and $10,000 to $99,999 (approximately 20%). Approximately 40% of small broker-dealer respondents could not estimate ongoing costs of compliance. Respondents operating ATSs indicated the following estimated ongoing costs: $10,000 to $99,999 (approximately 33%); $100,000 to $499,999 (approximately 17%); and $500,000 to $999,999 (approximately 33%). Approximately 17% of respondents operating ATSs could not estimate ongoing costs of compliance.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, Findings Related to Specific Thresholds, 100 microseconds
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ 100 microseconds,
+ broker-dealers,
+ Large Broker-Dealer,
+ Small Broker-Dealer,
+
+ Approximately 32% of respondents reported that they did not know how long it would take them to comply with a 100 microseconds threshold. Other respondents reported the following time estimates: no time (approximately 12%); less than 1 month (approximately 2%); 1 to 2 months (approximately 11%); 3 to 5 months (approximately 9%); 6 to 11 months (approximately 11%); 1 to 1.5 years (approximately 18%); 1.5 to 1.99 years (approximately 4%); and 2 years or more (approximately 2%).
+Most of the respondents providing implementation time estimates identified as large broker-dealers (approximately 68% of the respondents). The large broker-dealers provided the following implementation times: no time (approximately 13%); 1 to 2 months (approximately 8%); 3 to 5 months (approximately 13%); 6 to 11 months (approximately 13%); 1 to 1.5 years (approximately 23%); and 1.5 to 1.99 years (approximately 5%). Approximately 23% of large broker-dealer respondents could not estimate an implementation time to comply with the lower threshold. Small broker-dealer respondents provided the following implementation time estimates: no time (approximately 33%); 1 to 2 months (approximately 17%); and 6 to 11 months (approximately 17%). Approximately 33% of small broker-dealer respondents could not estimate an implementation time to comply with the lower threshold. Respondents operating ATSs reported the following estimated initial implementation times: 3 to 5 months (approximately 17%); 6 to 11 months (approximately 50%); and 1 to 1.5 years (approximately 33%).
+With respect to initial costs to comply with a 100 microseconds threshold, approximately 9% of respondents stated that they would incur no initial costs. Other respondents indicated the following estimated initial compliance costs: $1 to $999 (approximately 7%); $1,000 to $9,999 (approximately 10%); $10,000 and $99,999 (approximately 10%); $100,000 and $499,999 (approximately 9%); $500,000 and $999,999 (approximately 7%); $2 million to $4.99 million (approximately 7%); and $5 million or more (approximately 2%). Approximately 2% of respondents indicated that the initial costs of complying with a 100 microseconds threshold would be prohibitive. Approximately 42% of respondents could not estimate their initial compliance costs.
+Most of the respondents providing initial cost estimates were large broker-dealers (approximately 69%). Large broker-dealer respondents indicated the following initial costs of compliance: $0 (approximately 10%); $1 to $999 (approximately 3%); $1,000 to $9,999 (approximately 13%); $10,000 to $99,999 (approximately 13%); $100,000 to $499,999 (approximately 13%); $500,000 to $999,999 (approximately 10%); $2 million to $4.99 million (approximately 8%); and $5 million or more (approximately 3%). One large broker-dealer said that the initial costs of compliance would be prohibitive. Approximately 28% of large broker-dealer respondents could not estimate their initial costs to comply with a 100 microseconds threshold. Small broker-dealer respondents reported the following initial costs to comply with the lower threshold: $0 (approximately 17%); $1 to $999 (approximately 17%); $1,000 to $9,999 (approximately 17%); and $10,000 to $99,999 (approximately 17%). Approximately 33% of small broker-dealer respondents could not estimate their initial costs to comply with the lower threshold. Respondents operating ATSs estimated the following initial implementation costs: $100,000 to $499,999 (approximately 14%); $500,000 to $999,999 (approximately 14%); $1 million to $1.99 million (approximately 43%); $10 million to $20 million (approximately 14%). Approximately 14% of respondents operating ATSs did not know their initial costs.
+With respect to estimated ongoing costs to comply with a 100 microseconds threshold, approximately 13% of respondents reported an estimated cost of $0 and approximately 42% of respondents could not estimate ongoing costs. Other respondents reported the following costs: $1 to $999 (approximately 2%); $1,000 to $9,999 (approximately 4%); $10,000 to $99,999 (approximately 20%); $100,000 to $499,999 (approximately 11%); $500,000 to $999,999 (approximately 4%); $1 million to $1.99 million (approximately 2%); and $2 million to $4.99 million (approximately 2%). Approximately 2% of respondents stated that ongoing costs would be prohibitive.
+The majority of responses regarding estimated ongoing costs (approximately 69%) were from large broker-dealers. Large broker-dealer respondents indicated the following ongoing costs: $0 (approximately 13%); $1,000 to $9,999 (approximately 3%); $10,000 to $99,999 (approximately 24%); $100,000 to $499,999 (approximately 16%); $500,000 to $999,999 (approximately 5%); $1 million to $1.99 million (approximately 3%); and $2 million to $4.99 million (approximately 3%). Approximately 3% of large broker-dealer respondents stated that ongoing costs to comply with the lower threshold would be prohibitive. Small broker-dealer respondents reported the following ongoing costs: $0 (approximately 20%); $1,000 to $9,999 (approximately 20%); and $10,000 to $99,999 (approximately 20%). Approximately 40% of small broker-dealer respondents could not estimate ongoing costs of compliance. Respondents operating ATSs reported the following estimated ongoing costs: $10,000 to $99,999 (approximately 33%); $100,000 to $499,999 (approximately 17%); and $500,000 to $999,999 (approximately 33%). Approximately 17% of respondents operating ATSs could not estimate ongoing costs of compliance.
+pubdate: May 15, 2017 effdate: N/A
+ 5. Current Business Clock Synchronization Practices
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ broker-dealers,
+ Large Broker-Dealer,
+ Small Broker-Dealer,
+
+ A majority of respondents (approximately 64%) indicated that their current Business Clock synchronization threshold is less than 50 milliseconds; however, these responses were skewed toward large broker-dealers, which made up approximately 80% of the responses. Respondents varied as to the particular thresholds that they currently use. In particular, respondents reported the following current thresholds: 1 microsecond to 499 microseconds (approximately 9%); 500 microseconds to 999 microseconds (approximately 8%); 1 millisecond to 49 milliseconds (approximately 47%); 50 milliseconds to 499 milliseconds (approximately 13%); 500 milliseconds to 1 second (approximately 4%) and more than one second (approximately 1%). Approximately 19% of respondents did not know their firm’s current Business Clock synchronization thresholds.
+Focusing on type of respondent, large broker-dealer respondents indicated that they have current thresholds of: 1 microsecond to 499 microseconds (approximately 12%); 500 microseconds to 999 microseconds (approximately 6%); 1 millisecond to 49 milliseconds (approximately 51%); 50 milliseconds to 499 milliseconds (approximately 12%); and 500 milliseconds to 1 second (approximately 3%). Approximately 17% of large broker-dealer respondents did not know their firm’s current threshold. Small broker-dealer respondents reported the following current thresholds: 500 microseconds to 999 microseconds (approximately 19%); 1 millisecond to 49 milliseconds (approximately 11%); 50 milliseconds to 499 milliseconds (approximately 26%); 500 milliseconds to 1 second (approximately 11%) and more than one second (approximately 7%). Approximately 26% of small broker-dealer respondents did not know their firm’s current threshold.
+Approximately 55% of respondents indicated that their Business Clock synchronization tolerances did not vary based on whether Business Clocks were located in particular systems. Respondents did not express a clear majority view on the frequency with which they check the synchronization of Business Clocks. Focusing on large and small broker-dealers, the majority of large broker-dealer respondents (approximately 57%) and small broker-dealer respondents (approximately 65%) stated that their synchronization tolerances do not vary based on where a Business Clock is located. Approximately 19% of large broker-dealer respondents indicated that their synchronization tolerances vary based on where Business Clocks are located; by comparison, no small broker-dealer respondents indicated that their tolerances vary based on the location of Business Clocks. Approximately 25% of large broker-dealer respondents and approximately 35% of small broker-dealer respondents did not know if their tolerances vary based on where Business Clocks are located.
+Generally, respondents reported that NTP was the most common technology used to maintain Business Clock synchronization, although, with respect to co-located systems in particular, PTP was the most common technology used. The most common response among large broker-dealer respondents (approximately 40%) was that they employ multiple technologies to maintain synchronization. Small broker-dealer respondents most commonly (approximately 30%) indicated that they use NTP to maintain synchronization; however, approximately 41% of small broker-dealer respondents did not know what technology they use to maintain synchronization. Overall, the NIST atomic clock was the most common master clock used by respondents.
+These findings are discussed further below.
+pubdate: May 15, 2017 effdate: N/A
+ a. Maintaining Business Clock Synchronization
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Maintaining Business Clock Synchronization
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ PTP,
+ NTP,
+ GPS,
+ CDMA,
+ Large Broker-Dealer,
+
+ Approximately 15% of respondents did not know what technology their firms use to maintain Business Clock synchronization. Focusing on the respondents that did know what technology their firms use, the most common response (approximately 50% of respondents) was that firms used a combination of different technologies to maintain synchronization—typically, these respondents use a combination of PTP, NTP and GPS. In terms of a single solution, NTP was the most common technology used by respondents with approximately 46% reporting that they use this solution. GPS and PTP were the next most common solutions, with each being used by approximately 22% of respondents.25
+Large broker-dealer respondents reported using the following solutions to maintain synchronization: multiple technologies (approximately 40%); NTP (approximately 27%); PTP (approximately 6%); GPS (approximately 6%); CDMA (approximately 2%); and other technologies (approximately 3%). Approximately 16% of large broker-dealer respondents did not know what technology they use to maintain synchronization. Small broker-dealer respondents reported using the following solutions to maintain synchronization: NTP (approximately 30%); other technologies (approximately 15%); GPS (approximately 7%); and multiple technologies (approximately 7%). Approximately 41% of small broker-dealer respondents did not know what technology they use to maintain synchronization.
+Results also varied when analyzed by type of system, as described further below.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Maintaining Business Clock Synchronization, Origination Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ PTP,
+ GPS,
+ CDMA,
+
+ Respondents operating origination systems indicated that their firms use the following technologies to maintain Business Clock synchronization: PTP was the primary technology used (approximately 46% of respondents) followed by GPS and PTP (each used by approximately 22% of respondents), other technology (approximately 7% of respondents) and CDMA (approximately 3% of respondents). Approximately 25% of respondents did not know what technology their firms use to maintain synchronization.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Maintaining Business Clock Synchronization, Routing Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ PTP,
+ GPS,
+ CDMA,
+ NTP,
+
+ Respondents operating routing systems stated that their firms use the following technologies to maintain Business Clock synchronization: NTP (approximately 43%); GPS (approximately 25%); PTP (approximately 24%); CDMA (approximately 4%); and other solutions (approximately 4%). Approximately 20% of respondents did not know what technology their firms use to maintain synchronization. Based on the Survey results, routing systems appear to have the highest use of CDMA technology of any system based on the number of responses.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Maintaining Business Clock Synchronization, Execution Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ PTP,
+ GPS,
+ CDMA,
+ NTP,
+
+ Respondents operating execution systems reported that their firms use the following technologies to maintain Business Clock synchronization: NTP (approximately 44%); PTP (approximately 25%); GPS (approximately 21%); other solutions (approximately 8%); and CDMA (approximately 1%). Approximately 13% of respondents did not know what technology their firms use to maintain synchronization.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Maintaining Business Clock Synchronization, Co-located Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ PTP,
+ GPS,
+ CDMA,
+ NTP,
+
+ Respondents operating co-located systems indicated that their firms use the following technologies to maintain Business Clock synchronization: NTP (approximately 35%); PTP (approximately 33%); GPS (approximately 25%); CDMA (approximately 5%); and other solutions (approximately 2%). Approximately 10% of respondents did not know what technology their firms use to maintain Business Clock synchronization. Based on information provided by the respondents, co-located systems have the lowest use of NTP and the highest use of PTP across any systems addressed in the Survey.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Maintaining Business Clock Synchronization, Internalization Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ PTP,
+ GPS,
+ NTP,
+
+ Respondents operating internalization systems stated that their firms use the following technologies to maintain Business Clock synchronization: NTP (approximately 42%); GPS (approximately 31%); PTP (approximately 23%); and other technology (approximately 4%). Approximately 17% of respondents indicated that they did not know what technology their firms use to maintain Business Clock synchronization. Based on information provided by respondents, internalization systems have the highest use of GPS technology across any system addressed in the Survey and, along with third-party systems (discussed below) the lowest use of CDMA technology (no respondents reported using GPS technology to maintain synchronization of internalization systems).
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Maintaining Business Clock Synchronization, Back-Office Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ PTP,
+ GPS,
+ CDMA,
+ NTP,
+
+ Respondents operating back-office systems reported that their firms use the following technologies to maintain Business Clock synchronization: NTP (approximately 56%); GPS (approximately 19%); PTP (approximately 19%); CDMA (approximately 3%); and other technology (approximately 3%). Approximately 15% of respondents did not know what technology their firms use to maintain Business Clock synchronization. Based on the information provided by respondents, back-office systems have the highest use of NTP and the lowest use of GPS across any of the systems addressed in the Survey.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Maintaining Business Clock Synchronization, Third-Party Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ PTP,
+ GPS,
+ CDMA,
+ NTP,
+
+ Respondents that use third-party systems indicated that their firms use the following technologies to maintain Business Clock synchronization: NTP (approximately 49%); GPS (approximately 26%); PTP (approximately 17%); and other technology (approximately 9%). No respondents reported using CDMA to maintain Business Clock synchronization in third-party systems. Approximately 15% of respondents indicated that they did not know what technology they use to maintain Business Clock synchronization.
+pubdate: May 15, 2017 effdate: N/A
+ b. Current Business Clock Synchronization Tolerances
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Current Business Clock Synchronization Tolerances
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Tolerance,
+ broker-dealers,
+ Large Broker-Dealer,
+ Small Broker-Dealer,
+
+ As previously noted, a majority of respondents (approximately 60%) indicated that their current Business Clock synchronization tolerance is better than the standard currently set forth in the Plan. However, this result is not necessarily representative of the industry as a whole since the vast majority of these responses (approximately 80%) were provided by large broker-dealer respondents. Conversely, approximately 20% of respondents stated that their current synchronization tolerance is at or above the current standard set forth in the Plan, and the approximately 20% of respondents indicated that they did not know their current synchronization tolerance.
+Respondents that identified as large broker-dealers reported that they currently maintain the following Business Clock synchronization tolerances: 1 microsecond to 499 microseconds (approximately 12%); 500 microseconds to 999 microseconds (approximately 6%); 1 millisecond to 49 milliseconds (approximately 51%); 50 milliseconds to 499 milliseconds (approximately 12%); and 500 milliseconds to 1 second (approximately 3%). Approximately 17% of large broker-dealer respondents did not know their current synchronization tolerances. Small broker-dealer respondents reported that they currently maintain the following synchronization tolerances: 500 microseconds to 999 microseconds (approximately 19%); 1 millisecond to 49 milliseconds (approximately 11%); 50 milliseconds to 499 milliseconds (approximately 26%); and 500 milliseconds to 1 second (approximately 11%); and more than 1 second (approximately 7%). Approximately 26% of small broker-dealer respondents did not know their current synchronization tolerances.
+These findings are discussed further below, focusing on the types of systems used by respondents.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Current Business Clock Synchronization Tolerances, Origination Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ Origination Systems,
+
+ Approximately 60% of respondents operating origination systems reported that they currently use a synchronization tolerance that is better than the standard set forth in the Plan. Specifically, respondents reported the following current tolerances: 1 microsecond to 499 microseconds (approximately 10%); 500 microseconds to 999 microseconds (approximately 7%); 1 millisecond to 49 milliseconds (approximately 44%); 50 milliseconds to 499 milliseconds (approximately 13%); and 500 milliseconds to 1 second (approximately 3%). Approximately 24% of respondents indicated that they did not know their current synchronization tolerances.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Current Business Clock Synchronization Tolerances, Routing Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ Routing Systems,
+
+ Approximately 70% of respondents operating routing systems reported that they currently use a tolerance that is better than the standard set forth in the Plan. Specifically, respondents reported the following tolerances: 1 microsecond to 499 microseconds (approximately 10%); 500 microseconds to 999 microseconds (approximately 8%); 1 millisecond to 49 milliseconds (approximately 53%); 50 milliseconds to 499 milliseconds (approximately 10%); and more than 1 second (approximately 1%). Approximately 18% of respondents did not know their current synchronization tolerances.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Current Business Clock Synchronization Tolerances, Execution Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ Execution Systems,
+
+ Approximately 57% of respondents operating execution systems reported that they currently use a synchronization tolerance that is better than the standard set forth in the Plan. Specifically, respondents reported the following current tolerances: 1 microsecond to 499 microseconds (approximately 9%); 500 microseconds to 999 microseconds (approximately 4%); 1 millisecond to 49 milliseconds (approximately 44%); 50 milliseconds to 499 milliseconds (approximately 16%); 500 milliseconds to 1 second (approximately 7%); and more than 1 second (approximately 2%). Approximately 19% of respondents did not know their current synchronization tolerances.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Current Business Clock Synchronization Tolerances, Co-located Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ Co-located Systems,
+
+ Approximately 82% of respondents operating co-located systems reported that they currently use a tolerance that is better than the standard set forth in the Plan. In particular, respondents reported that they currently use the following tolerances: 1 microsecond to 499 microseconds (approximately 22%); 500 microseconds to 999 microseconds (approximately 19%); 1 millisecond to 49 milliseconds (approximately 41%); and 50 milliseconds to 499 milliseconds (approximately 14%). Approximately 5% of respondents indicated that they did not know their current synchronization tolerances.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Current Business Clock Synchronization Tolerances, Internalization Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ Internalization Systems,
+
+ Approximately 73% of respondents operating internalization systems reported that they currently use a synchronization tolerance that is better than the standard set forth in the Plan. Specifically, respondents reported the following current tolerances: 1 microsecond to 499 microseconds (approximately 6%); 500 microseconds to 999 microseconds (approximately 11%); 1 millisecond to 49 milliseconds (approximately 56%); 50 milliseconds to 499 milliseconds (approximately 11%); and 500 milliseconds to 1 second (approximately 6%). Approximately 11% of respondents did not know their current synchronization tolerances.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Current Business Clock Synchronization Tolerances, Back-Office Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ Back-Office Systems,
+
+ Approximately 63% of respondents operating back-office systems reported that they currently use a tolerance that is better than the standard set forth in the Plan. Specifically, respondents reported the following tolerances: 1 microsecond to 499 microseconds (approximately 4%); 500 microseconds to 999 microseconds (approximately 8%); 1 millisecond to 49 milliseconds (approximately 51%); 50 milliseconds to 499 milliseconds (approximately 15%); and 500 milliseconds to 1 second (approximately 9%). Approximately 13% of respondents did not know their current synchronization tolerances.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Current Business Clock Synchronization Tolerances, Third-Party Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ Third-Party Systems,
+
+ Approximately 44% of respondents using third-party systems stated that they currently use a tolerance that is better than the standard set forth in the Plan. In particular, respondents reported the following tolerances: 1 microsecond to 499 microseconds (approximately 3%); 1 millisecond to 49 milliseconds (approximately 41%); and 50 milliseconds to 499 milliseconds (approximately 16%). Approximately 41% of respondents did not know their current synchronization tolerances.
+pubdate: May 15, 2017 effdate: N/A
+ c. Business Clock Location
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Location
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Tolerance,
+ broker-dealers,
+ Large Broker-Dealer,
+ Small Broker-Dealer,
+
+ A majority of respondents (approximately 55%) stated that their Business Clock synchronization tolerances did not vary based on where a Business Clock was located. Conversely, approximately 15% of respondents indicated that their tolerances did vary based on where a Business Clocks was located. Approximately 30% of respondents did not know if their tolerances vary based on the location of a Business Clock.
+The majority of large broker-dealer respondents (approximately 57%) stated that their synchronization tolerances did not vary based on the location of Business Clocks, while approximately 19% reported that tolerances did vary based on location. Approximately 25% of large broker-dealer respondents did not know if tolerances varied by the location of Business Clocks. Similarly, the majority of small broker-dealer respondents (approximately 65%) indicated that their synchronization tolerances did not vary based on the location of Business Clocks, however, no small broker-dealer respondents reported that tolerances varied based on location of Business Clocks. Approximately 35% of small broker-dealer respondents did not know if their synchronization tolerances varied by the location of Business Clocks.
+These results are described below, focusing on type of system.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Location, Origination Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ Business Clock Location,
+ Origination Systems,
+
+ Approximately 56% of respondents operating origination systems indicated that their Business Clock synchronization tolerances did not vary based on where Business Clocks were located. Approximately 14% of respondents stated that their tolerances did vary based on where Business Clocks were located. Approximately 30% did not know if their synchronization tolerances varied based on the location of Business Clocks.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Location, Routing Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ Business Clock Location,
+ Routing Systems,
+
+ Approximately 55% of respondents operating routing systems stated that their synchronization tolerances did not vary based on where Business Clocks were located, while approximately 15% of respondents stated that their tolerances did vary based on where Business Clocks were located. Approximately 30% of respondents did not know if their tolerances varied based on the system in which Business Clocks were located.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Location, Execution Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ Business Clock Location,
+ Execution Systems,
+
+ Approximately 56% of respondents operating execution indicated that their Business Clock tolerances did not vary based on where Business Clocks were located, and approximately 15% of respondents indicated that their tolerances did vary based on where Business Clocks were located. Approximately 29% of respondents did not know if their tolerances varied based on the system in which Business Clocks were located.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Location, Co-located Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ Business Clock Location,
+ Co-located Systems,
+
+ The majority of respondents operating co-located systems (approximately 67%) indicated that their synchronization tolerances did not vary based on where Business Clocks were located, while approximately 19% of respondents indicated that their tolerances did vary based on where Business Clocks were located. Approximately 14% of respondents did not know if their synchronization tolerances varied based on where Business Clocks were located.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Location, Internalization Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ Business Clock Location,
+ Internalization Systems,
+
+ Respondents operating internalization systems were roughly split, with approximately 39% reporting that their synchronization tolerances did not vary based on where Business Clocks were located and 39% reporting that their tolerances did vary based on where Business Clocks were located. Approximately 22% of respondents did not know if their Business Clock synchronization tolerances varied based on where Business Clocks were located.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Location, Back-Office Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ Business Clock Location,
+ Back-Office Systems,
+
+ Approximately 68% of respondents operating back-office systems reported that their tolerances did not vary based on the location of Business Clocks. Approximately 10% of respondents stated that their tolerances did vary based on where Business Clocks were located. Approximately 22% of respondents did not know if their tolerances varied based on where Business Clocks were located.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Location, Third-Party Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Threshold,
+ Business Clock Location,
+ Third-Party Systems,
+
+ Approximately 41% of respondents using third-party systems indicated that their tolerances did not vary based on where Business Clocks were located, and approximately 18% of respondents stated that their tolerances did vary based on where Business Clocks were located. Approximately 41% of respondents did not know if Business Clock synchronization tolerances varied based on where Business Clocks were located.
+pubdate: May 15, 2017 effdate: N/A
+ d. Business Clock Synchronization Frequency
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Synchronization Frequency
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Accuracy,
+ Business Clock Synchronization Frequency,
+ broker-dealers,
+ Large Broker-Dealer,
+ Small Broker-Dealer,
+
+ With respect to the frequency with which respondents check their Business Clock synchronization accuracy, the most common response (approximately 23%) was that respondents check synchronization accuracy once a minute or more but less than once a second. Other respondents indicated checking synchronization accuracy with the following frequencies: once an hour or more but less than once a minute (approximately 20%); once a second or more but less than once a hundredth of a second (approximately 14%); more than once a day but less than once an hour (approximately 14%); once a day (approximately 12%); and more than once a hundredth of a second (approximately 3%). Only approximately 15% of respondents reported that they did not know how often their firms checked Business Clock synchronization accuracy.
+Large broker-dealer respondents reported that they check synchronization accuracy at the following frequencies: once a day (approximately 9%); more than once a day but less than once an hour (approximately 15%); once an hour or more but less than once a minute (approximately 23%); once a minute or more but less than once a second (approximately 18%); once a second or more but less than once a hundredth of a second (approximately 17%); and more than once a hundredth of a second (approximately 4%). Approximately 14% of large broker-dealer respondents did not know how often they check the accuracy of Business Clock synchronization. Small broker-dealer respondents indicated that they check synchronization accuracy at the following frequencies: once a day (approximately 47%); more than once a day but less than once an hour (approximately 10%); and once a minute or more but less than once a second (approximately 20%). Approximately 23% of small broker-dealer respondents did not know how often they check the accuracy of Business Clock synchronization.
+These results are discussed further below, focusing on the types of systems that respondents operate.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Synchronization Frequency, Originating Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Accuracy,
+ Origination Systems,
+
+ Respondents operating origination systems indicated that they check Business Clock synchronization accuracy at the following frequencies: once a day (approximately 18%); more than once a day but less than once an hour (approximately 14%); once an hour or more but less than once a minute (approximately 26%); once a minute or more but less than once a second (approximately 14%); once a second or more but less than once a hundredth of a second (approximately 10%); and more than once a hundredth of a second (approximately 1%). Approximately 17% of respondents did not know how often they check the accuracy of their Business Clock synchronization.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Synchronization Frequency, Routing Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Accuracy,
+ Routing Systems,
+
+ Respondents operating routing systems reported that they check Business Clock synchronization accuracy at the following frequencies: once a day (approximately 9%); more than once a day but less than once an hour (approximately 13%); once an hour or more but less than once a minute (approximately 26%); once a minute or more but less than once a second (approximately 19%); once a second or more but less than once a hundredth of a second (approximately 16%); and more than once a hundredth of a second (approximately 3%). Approximately 16% of respondents did not know how often they check the accuracy of their Business Clock synchronization.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Synchronization Frequency, Execution Systems,
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Accuracy,
+ Execution Systems,
+
+ Respondents operating execution systems stated that they check Business Clock synchronization accuracy at the following frequencies: once a day (approximately 16%); more than once a day but less than once an hour (approximately 15%); once an hour or more but less than once a minute (approximately 16%); once a minute or more but less than once a second (approximately 18%); once a second or more but less than once a hundredth of a second (approximately 18%); and more than once a hundredth of a second (approximately 4%). Approximately 13% of respondents did not know how often they check the accuracy of their Business Clock synchronization.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Synchronization Frequency, Co-located Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Accuracy,
+ Co-located Systems,
+
+ Respondents operating co-located systems indicated that they check Business Clock synchronization accuracy at the following frequencies: once a day (approximately 3%); more than once a day but less than once an hour (approximately 8%); once an hour or more but less than once a minute (approximately 22%); once a minute or more but less than once a second (approximately 22%); once a second or more but less than once a hundredth of a second (approximately 31%); and more than once a hundredth of a second (approximately 3%). Approximately 11% of respondents did not know how often they check the accuracy of their Business Clock synchronization.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Synchronization Frequency, Internalization Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Accuracy,
+ Internalization Systems,
+
+ Respondents operating internalization systems reported that they check Business Clock synchronization accuracy at the following frequencies: once a day (approximately 11%); more than once a day but less than once an hour (approximately 17%); once a minute or more but less than once a second (approximately 44%); once a second or more but less than once a hundredth of a second (approximately 11%); and more than once a hundredth of a second (approximately 6%). Approximately 11% of respondents did not know how often they check the accuracy of their Business Clock synchronization.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Synchronization Frequency, Back-Office Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Accuracy,
+ Back-Office Systems,
+
+ Respondents operating back-office systems indicated that they check Business Clock synchronization accuracy at the following frequencies: once a day (approximately 13%); more than once a day but less than once an hour (approximately 15%); once an hour or more but less than once a minute (approximately 25%); once a minute or more but less than once a second (approximately 21%); once a second or more but less than once a hundredth of a second (approximately 6%); and more than once a hundredth of a second (approximately 4%). Approximately 17% of respondents did not know how often they check the accuracy of their Business Clock synchronization.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Synchronization Frequency, Third-Party Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Accuracy,
+ Third-Party Systems,
+
+ Respondents using third-party systems reported that they check Business Clock synchronization accuracy at the following frequencies: once a day (approximately 13%); more than once a day but less than once an hour (approximately 15%); once an hour or more but less than once a minute (approximately 26%); once a minute or more but less than once a second (approximately 20%); once a second or more but less than once a hundredth of a second (approximately 6%); and more than once a hundredth of a second (approximately 4%). Approximately 17% of respondents did not know how often they check the accuracy of their Business Clock synchronization.
+pubdate: May 15, 2017 effdate: N/A
+ e. Master Clocks
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Master Clocks
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock synchronization,
+ PTP,
+ GPS,
+ NTP,
+ CDMA,
+ broker-dealers,
+ Large Broker-Dealer,
+ Small Broker-Dealer,
+
+ Respondents that provided information regarding the type of master clock that they use for purposes of maintaining Business Clock synchronization most commonly reported using the NIST atomic clock (approximately 45%). The next most popular solutions were: GPS (approximately 20%); other vendor or hardware-provided time (approximately 10%); data center-provided time (approximately 4%); and CDMA (approximately 1%). Approximately 15% of respondents did not know what their firms use as a master clock.
+Large broker-dealer respondents reported using the following as a master clock: NIST atomic clock (approximately 43%); GPS (approximately 27%); other vendor or hardware-provided time (approximately 11%); data center-provided time (approximately 3%); and CDMA (approximately 3%). Approximately 13% of large broker-dealers did not know what they use as a master clock. The responses from small broker-dealer respondents differed somewhat as they indicated using the following: NIST atomic clock (approximately 37%); other vendor or hardware-provided time (approximately 19%); and data center-provided time (approximately 7%). Approximately 37% of small broker-dealer respondents did not know what they use as a master clock.
+These results are described further below, based on the types of systems that respondents operate.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Master Clocks, Origination Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Requirement,
+ Master Clock,
+ Origination Systems,
+
+ Respondents operating origination systems reported that they use the following as a master clock for purposes of complying with the Business Clock synchronization requirement: NIST atomic clock (approximately 50%); GPS (approximately 20%); other vendor or hardware-provided time (approximately 10%); data center-provided time (approximately 4%); and CDMA (approximately 1%). Approximately 15% of respondents did not know what they use as a master clock.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Master Clocks, Routing Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Requirement,
+ Master Clock,
+ Routing Systems,
+ NIST,
+ CDMA,
+ GPS,
+
+ Respondents operating routing systems stated that they use the following as a master clock for purposes of complying with the Business Clock synchronization requirement: NIST atomic clock (approximately 40%); GPS (approximately 25%); other vendor or hardware-provided time (approximately 10%); data center-provided time (approximately 5%); and CDMA (approximately 5%). Approximately 15% of respondents did not know what they use as a master clock.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Master Clocks, Execution Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Requirement,
+ Master Clock,
+ Execution Systems,
+ NIST,
+ CDMA,
+ GPS,
+
+ Respondents operating execution systems stated that they use the following as a master clock for purposes of complying with the Business Clock synchronization requirement: NIST atomic clock (approximately 50%); GPS (approximately 20%); other vendor or hardware-provided time (approximately 15%); data center-provided time (approximately 5%); and CDMA (approximately 2%). Approximately 10% of respondents did not know what they use as a master clock.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Master Clocks, Co-located Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Requirement,
+ Master Clock,
+ Co-located Systems,
+ NIST,
+ CDMA,
+ GPS,
+
+ Respondents operating co-located systems stated that they use the following as a master clock for purposes of complying with the Business Clock synchronization requirement: NIST atomic clock (approximately 40%); GPS (approximately 30%); other vendor or hardware-provided time (approximately 10%); CDMA (approximately 5%); and data center-provided time (approximately 3%). Approximately 15% of respondents did not know what they use as a master clock.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Master Clocks, Internalization Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Requirement,
+ Master Clock,
+ Internalization Systems,
+ NIST,
+ CDMA,
+ GPS,
+
+ Respondents operating internalization systems stated that they use the following as a master clock for purposes of complying with the Business Clock synchronization requirement: GPS (approximately 40%); NIST atomic clock (approximately 35%); and other vendor or hardware-provided time (approximately 10%). No respondents reported using data center-provided time or CDMA as their master clocks. Approximately 10% of respondents did not know what they use as a master clock.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Master Clocks, Back-Office Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Requirement,
+ Master Clock,
+ Back-Office Systems,
+ NIST,
+ CDMA,
+ GPS,
+
+ Respondents operating back-office systems stated that they use the following as a master clock for purposes of complying with the Business Clock synchronization requirement: NIST atomic clock (approximately 50%); GPS (approximately 20%); other vendor or hardware-provided time (approximately 15%). No respondents indicated that they used data center-provided time or CDMA as their master clocks. Approximately 15% of respondents did not know what they use as a master clock.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Master Clocks, Third-Party Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Requirement,
+ Master Clock,
+ Third-Party Systems,
+ NIST,
+ CDMA,
+ GPS,
+
+ Respondents using third-party systems stated that they use the following as a master clock for purposes of complying with the Business Clock synchronization requirement: NIST atomic clock (approximately 50%); GPS (approximately 20%); and other vendor or hardware-provided time (approximately 15%). No respondents reported using data center-provided time or CDMA as their master clocks. Approximately 15% of respondents did not know what they use as a master clock.
+pubdate: May 15, 2017 effdate: N/A
+ f. Synchronization Across Geographically Disparate Systems
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Synchronization Across Geographically Disparate Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Across Geographically Disparate System,
+ broker-dealers,
+ Large Broker-Dealer,
+ Small Broker-Dealer,
+
+ Approximately 40% of respondents responding to the question on maintaining Business Clock synchronization across geographically disparate systems indicated that they do maintain synchronization across systems that are geographically disparate.26 Approximately 30% of respondents reported that they do not synchronize Business Clocks across geographically disparate systems. Approximately 30% of respondents indicated that this question was not applicable.
+The most common response from large broker-dealer respondents was that they did maintain Business Clock synchronization across geographically disparate systems (approximately 44%). Approximately 29% of large broker-dealer respondents reported that they did not maintain synchronization across geographically disparate systems, and approximately 27% indicated that this question was not applicable to them. Approximately 38% of small broker-dealer respondents stated that they maintain synchronization across geographically disparate systems, and approximately 28% reported that they do not. Approximately 34% of small broker-dealer respondents indicated that this question was not applicable to them.
+These results are discussed further below, based on the types of systems that respondents operate.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Synchronization Across Geographically Disparate Systems, Origination Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Across Geographically Disparate System,
+ Origination Systems,
+
+ Approximately 30% of respondents operating origination systems indicated that they maintained Business Clock synchronization across geographically disparate systems. Approximately 35% of respondents stated that they did not maintain synchronization across geographically disparate systems. Approximately 30% of respondents indicated that this question did not apply to their operations.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Synchronization Across Geographically Disparate Systems, Routing Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Across Geographically Disparate System,
+ Routing Systems,
+
+ Approximately 35% of respondents operating routing systems reported that they maintained Business Clock synchronization across geographically disparate systems. Approximately 40% of respondents indicated that they did not maintain synchronization across geographically disparate systems. Approximately 25% of respondents indicated that this question did not apply to their operations.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Synchronization Across Geographically Disparate Systems, Execution Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Across Geographically Disparate System,
+ Execution Systems,
+
+ Approximately 40% of respondents operating execution systems stated that they maintained Business Clock synchronization across geographically disparate systems. Approximately 20% of respondents indicated that they did not maintain synchronization across geographically disparate systems. Approximately 40% of respondents indicated that this question did not apply to their operations.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Synchronization Across Geographically Disparate Systems, Co-located Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Across Geographically Disparate System,
+ Co-located Systems,
+
+ Approximately 50% of respondents operating co-located systems stated that they maintained Business Clock synchronization across geographically disparate systems. Approximately 20% of respondents stated that they did not maintain synchronization across geographically disparate systems. Approximately 30% of respondents indicated that this question did not apply to their operations.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Synchronization Across Geographically Disparate Systems, Internalization Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Across Geographically Disparate System,
+ Internalization Systems,
+
+ Approximately 50% of respondents operating internalization systems indicated that they maintained Business Clock synchronization across geographically disparate systems. Approximately 15% of respondents stated that they did not maintain synchronization across geographically disparate systems. Approximately 30% of respondents indicated that this question did not apply to their operations.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Synchronization Across Geographically Disparate Systems, Back-Office Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Across Geographically Disparate System,
+ Back-Office Systems,
+
+ Approximately 40% of respondents operating back-office systems indicated that they maintained Business Clock synchronization across geographically disparate systems. Approximately 40% of respondents stated that they did not maintain synchronization across geographically disparate systems. Approximately 20% of respondents indicated that this question did not apply to their operations.
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Synchronization Across Geographically Disparate Systems, Third-Party Systems
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Across Geographically Disparate System,
+ Third-Party Systems,
+
+ Approximately 35% of respondents stated that they maintained Business Clock synchronization across geographically disparate systems. Approximately 40% of respondents indicated that they did not maintain synchronization across geographically disparate systems. Approximately 25% of respondents indicated that this question did not apply to their operations.
+pubdate: May 15, 2017 effdate: N/A
+ VI. Recommendations: Current Clock Synchronization Requirements
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, Recommendations: Current Clock Synchronization Requirements
+ Compliance User: Broker-dealers
+ Keywords:
+ CAT NMS Plan - Section 6.6,
+ Business Clock synchronization,
+ Participants,
+ CAT Reporter,
+ Industry Member,
+
+ As required by Section 6.6(a)(ii) of the CAT NMS Plan, the Participants provide these recommendations with respect to the current Business Clock synchronization requirements based on their analysis of the data collected in the Survey. As discussed further below, the Participants do not believe that it is appropriate to amend the current Business Clock synchronization requirements set forth in the Plan at this time based on the results of the Survey.
+The Participants note that data collected in the survey is limited in certain ways for general applicability.27 For instance, the data is heavily skewed towards larger broker-dealers (approximately 60% of all respondents), thus making its applicability to small broker-dealers (approximately 13% of all respondents) more questionable. In addition, many respondents indicated in their responses to various questions that they did not know their firm’s current practices and did not know, or cannot estimate, potential costs (i.e., with respect to implementation times and initial and ongoing monetary costs).
+Moreover, the Participants note that the current Business Clock synchronization standards were only recently implemented, and the Participants believe that the Participants and Industry Members should gain experience with those new standards prior to implementing more stringent or granular standards. In particular, the Participants desire to evaluate the effectiveness of current Business Clock synchronization requirements on the linkage and sequencing of independent events in the CAT, or whether more granular synchronization requirements are important to the accurate linkage and sequencing of the events. After gaining experience with
+the synchronization standards and their effect on the accuracy of the CAT, the Participants believe that they will be able to analyze whether narrower clock synchronization requirements are necessary to obtain the intended regulatory goals of the CAT and whether any narrower requirements should be applied to certain groups or types of Industry Members consistent with industry standard practices. The Participants also anticipate that Industry Members, Small Industry Members and Service Providers that maintain synchronized Business Clocks will be able to provide more detailed and accurate responses after all CAT Reporters that are Industry Members and Small Industry Members are subject to the synchronization standards set forth in the Plan.
+Nevertheless, despite these concerns and recognition of the limitations of the Survey results, the Participants provide the following suggestions for consideration at a future date regarding potential amendments related to the type of CAT Reporter, type of Industry Member and type of system.
+pubdate: May 15, 2017 effdate: N/A
+ A. Type of CAT Reporter
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, Recommendations: Current Clock Synchronization Requirements, Type of CAT Reporter
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Requirements,
+ Participants,
+ CAT Reporter,
+ Industry Member,
+
+ The Participants evaluated whether it is appropriate to amend the Business Clock synchronization requirements in the Plan based on the type of CAT Reporter – Participant and Industry Members. The current clock synchronization standards impose different standards on Participants and Industry Members. Participants are required to meet a 100 microseconds standard, whereas Industry Members are required to meet a 50 milliseconds standard. The Participants do not recommend changing these standards at this time.
+As discussed above, the Survey focused on collecting data regarding Industry Members. The Participants, however, have reported that they comply with the 100 microseconds requirement currently set forth in the Plan. Based on prior analysis of the Participants’ clock synchronization practices, the Participants believe that 100 microseconds is an appropriate synchronization standard to apply to the Participants. Moreover, at this time, the Participants do not believe that the same standard should apply to the Participants and to CAT Reporters that are Industry Members and/or Small Industry Members since the Survey results do not reflect a uniformity of synchronization thresholds among all CAT Reporters.
+With regard to Industry Members, the data collected indicates that many potential CAT Reporters currently synchronize their Business Clocks at thresholds that are better (i.e., narrower) than currently required by the Plan, although not necessarily to the granularity of the Participants. For example, approximately 64% of respondents indicated that their current synchronization threshold is less than 50 milliseconds, with respondents most commonly reporting that they maintain thresholds of between 1 millisecond and 49 milliseconds (approximately 47%). By comparison, relatively few respondents indicated that they currently maintain synchronization thresholds below 1 millisecond (approximately 17%). The Participants, however, do not believe that this supports decreasing the synchronization thresholds applicable to all Industry Members as a group at this time. As discussed in this assessment, the sample set is heavily skewed toward large broker-dealers (approximately 80% of respondents providing data on current synchronization thresholds), and the Participants have not had an opportunity to fully evaluate the extent to which the Survey respondents represent large broker-dealers, so additional information is necessary before the Plan may be amended.
+pubdate: May 15, 2017 effdate: N/A
+ B. Type of Industry Member
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, Recommendations: Current Clock Synchronization Requirements, Type of Industry Member
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Requirements,
+ broker-dealers,
+ Large Broker-Dealer,
+ Small Broker-Dealer,
+ CAT NMS plan,
+ CAT Reporting,
+
+ The Participants evaluated whether it is appropriate to amend the Business Clock synchronization requirements in the Plan based on the type of Industry Member (e.g., ATS, small broker-dealer) when establishing appropriate industry standards. Recognizing the limitations of the Survey, the data suggests that many large-broker dealer respondents may already meet or exceed the standard set forth in the Plan. However, as discussed below, the Participants believe that additional analysis is necessary for implementing any narrower thresholds that are generally applicable to Industry Members or applicable to a particular subset thereof.
+The Survey data preliminarily suggests many large broker-dealers currently synchronize their Business Clocks at thresholds that are better (i.e., narrower) than currently required by the Plan. For example, 69% of the large broker-dealer respondents indicated that they have current thresholds of less than the current 50 millisecond standard. In particular, large broker-dealer respondents reported that they used the following standards: 1 microsecond to 499 microseconds (approximately 12%); 500 microseconds to 999 microseconds (approximately 6%); 1 millisecond to 49 milliseconds (approximately 51%); 50 milliseconds to 499 milliseconds (approximately 12%); and 500 milliseconds to 1 second (approximately 3%). Approximately 16% of large broker-dealer respondents did not know their firm’s current threshold. Moreover, many large broker-dealer respondents indicated that it would take them no time to comply with narrower standards of 5 milliseconds (approximately 23%), 1 millisecond (approximately 23%), 500 microseconds (approximately 14%) and 100 microseconds (approximately 13%). Although these results do not reflect a consensus among large broker-dealer respondents, the Participants believe that future analysis may indicate that compliance implementation times will decrease due to technological advances in the industry and after large broker-dealers gain experience reporting to the Central Repository. However, large broker-dealer respondents, without a majority or consensus view, also indicated that they would incur a range of costs to comply with narrower synchronization thresholds, with some estimating costs of $5 million or more to comply with thresholds below 1 millisecond. Accordingly, the Participants believe that, although large broker-dealers may be able to comply with a narrower synchronization standard without significant costs in terms of implementation time, monetary costs may be significant and possibly prohibitive. The SEC expressed a similar view when it recently approved the Plan. It explained, “[w]hile the Commission believes that regulators’ ability to sequence orders accurately in certain cases could improve if the clock synchronization for Industry Members were finer, the Commission is sensitive to the costs associated with requiring a finer clock synchronization [standard] for Industry Members at this time, and believes that a standard of 50 milliseconds for Industry Members will allow regulators to sequence orders and events with a level of accuracy that is acceptable for the initial phases of CAT reporting.”28
+The Survey results suggest that it would be premature to lower the clock synchronization standards with regard to small broker-dealers. As noted, the number of respondents that identified as small broker-dealers was limited; only 13% of the respondents identified as small broker-dealers, which does not provide a representative view of small broker-dealers in the industry. Moreover, only approximately 30% of small broker-dealer respondents reported that they used a synchronization threshold less than the 50 milliseconds standard. Specifically, small broker-dealer respondents reported the following current thresholds: 500 microseconds to 999 microseconds (approximately 19%); 1 millisecond to 49 milliseconds (approximately 11%); 50 milliseconds to 499 milliseconds (approximately 26%); 500 milliseconds to 1 second (approximately 11%); and more than one second (approximately 7%). Approximately 26% of small broker-dealer respondents did not know their firm’s current threshold. Some, but not a majority or a representative sample, of small broker-dealer respondents indicated that it would take them no time to comply with narrower standards of 5 milliseconds (approximately 29%), 1 millisecond (approximately 17%), 500 microseconds (approximately 33%) and 100 microseconds (approximately 33%). However, as discussed throughout this assessment, the number of respondents that identified as small broker-dealers was limited, which suggests that this data may not be representative of small broker-dealers generally. In addition, given that, throughout the development of the CAT NMS Plan, small broker-dealers and industry associations have noted that they believe that small broker-dealers will be disproportionately burdened when it comes to complying with the Plan requirements, the Participants believe that it is necessary to understand the potential impact of any amendment to the Plan on small broker-dealers. For instance, as was the case with large broker-dealer respondents, small broker-dealer respondents indicated a range of potential costs to comply with a narrower synchronization threshold without a clear consensus or majority view. Although many small broker-dealers estimated that they would incur substantial costs to comply with narrower standards, a significant portion of small broker-dealer respondents could not estimate anticipated compliance costs.
+The Survey results also suggest that it may not be appropriate to subject ATSs to narrower synchronization standards at this time. Few ATS respondents indicated that it would take them no time to comply with narrower thresholds of: 5 milliseconds (approximately 18%); 1 millisecond (approximately 29%); 500 microseconds (approximately 17%); and 100 microseconds (0%). Moreover, many ATSs reported that they would incur significant costs to comply with narrower synchronization thresholds. For instance, for thresholds of 500 microseconds and 100 microseconds, the majority of ATS respondents estimated that they would incur initial compliance costs between $1 million and $20 million (approximately 57% each for thresholds of 500 microseconds and 100 microseconds). However, as is the case with data from small broker-dealer respondents, in some respects the data provided by ATS respondents is limited. For instance, as of May 3, 2017, the SEC reported that there are 83 ATSs with current Forms ATS on file, but only 12 respondents (approximately 8%) indicated that they operate an ATS.29 The Participants believe that it is necessary to better understand the synchronization practices of ATSs, as well as the potential costs that ATSs would incur to comply with narrower synchronization standards.30
+pubdate: May 15, 2017 effdate: N/A
+ C. Type of System
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, Recommendations: Current Clock Synchronization Requirements, Type of System
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Requirements,
+ Order Origination System,
+ Order Routing System,
+ Order Execution System,
+ Co-located System,
+ Internalization Systems,
+ Back-Office Systems,
+ Third Party Systems,
+
+ The Participants evaluated whether it is appropriate to amend the Business Clock synchronization requirements in the Plan based on the type of system, including: order origination systems; order routing systems; order execution or matching systems; co-located systems; internalization systems; back-office systems; and third-party systems (including vendor systems). Based on the Survey, the Participants do not believe that it is appropriate to apply different synchronization thresholds to different types of systems at this time.
+The Survey results did not indicate any consistent patterns that would necessarily support implementing a narrower or higher threshold for particular systems. For instance, with the exception of third-party systems, the majority of respondents that submitted system-level responses indicated that Business Clocks in those systems tend to be narrower than required by the Plan. However, given the ranges provided in the Survey, the Participants cannot precisely determine the current synchronization thresholds commonly used in the various systems addressed in the Survey. Moreover, of the respondents that provided information regarding current synchronization thresholds, approximately 55% indicated that their Business Clock synchronization tolerances did not vary based on whether Business Clocks were located in particular systems. Approximately 19% of large broker-dealer respondents indicated that their synchronization tolerances varied based on where Business Clocks were located; by comparison, no small broker-dealer respondents indicated that their tolerances varied based on location of Business Clocks. This further indicates that additional analysis is necessary to better determine whether, if required to do so, CAT Reporters would be capable of complying with synchronization thresholds that vary by type of system, or whether the costs of doing so would be significant or otherwise prohibitive.31
+pubdate: May 15, 2017 effdate: N/A
+ D. Conclusion
+Topic: SEC Reports, CAT NMS Plan Clock Synchronization, Recommendations: Current Clock Synchronization Requirements, Conclusion
+ Compliance User: Broker-dealers
+ Keywords:
+ Business Clock Synchronization Requirements,
+ Business Clock Synchronization Threshold,
+ CAT Reporter,
+ Business Clock Synchronization Practices,
+
+ As discussed above, the Participants do not believe that it is necessary or appropriate to amend the Business Clock synchronization requirements set forth in the Plan at this time. The Participants will reassess whether the Business Clock synchronization requirements remain consistent with industry standards – or whether it may be necessary to amend such requirements – in the future as part of the annual assessment required by Section 6.8(c) of the Plan. To make such an assessment, the Participants intend to continue working with the Advisory Committee and the industry generally, including CAT Reporters of various sizes and types, to determine whether current Business Clock synchronization practices have changed sufficiently to suggest that narrower synchronization thresholds may be consistent with industry standards. As the Commission noted when it approved the Plan, if the Participants determine based on a future assessment that the clock synchronization requirements in the Plan should be changed, the Participants would need to file a proposed amendment to the Plan with the Commission. Such a submission would enable the Commission, as well as Industry Members and the public, to evaluate the proposed requirements, including anticipated costs, benefits and related implementation time frames.
+
+ | fn |
+ 1 The CAT NMS Plan is a national market system plan approved by the Commission pursuant to Section 11A of the Exchange Act and the rules and regulations thereunder. See Securities Exchange Act Release No. 79318 (Nov. 15, 2016), 81 Fed. Reg. 84696 (Nov. 23, 2016) (the “Adopting Release”). The full text of the CAT NMS Plan is available at www.catnmsplan.com. + |
| fn |
+ 2 The Participants to the CAT NMS Plan are Bats BYX Exchange, Inc., Bats BZX Exchange, Inc., Bats EDGA Exchange, Inc., Bats EDGX Exchange, Inc., BOX Options Exchange LLC, C2 Options Exchange, Incorporated, Chicago Board Options Exchange, Incorporated, Chicago Stock Exchange, Inc., Financial Industry Regulatory Authority, Inc., Investors’ Exchange LLC, Miami International Securities Exchange, LLC, MIAX PEARL, LLC, NASDAQ BX, Inc., Nasdaq GEMX, LLC, Nasdaq ISE, LLC, Nasdaq MRX, LLC, NASDAQ PHLX LLC, The NASDAQ Stock Market LLC, NYSE National, Inc., New York Stock Exchange LLC, NYSE MKT LLC, and NYSE Arca, Inc. Note that National Stock Exchange, Inc. has been renamed NYSE National, Inc. See Securities Exchange Act Rel. No. 79902 (Jan. 30, 2017), 82 Fed. Reg. 9258 (Feb. 3, 2017). Note further that ISE Gemini, LLC, ISE Mercury, LLC and International Securities Exchange, LLC have been renamed Nasdaq GEMX, LLC, Nasdaq MRX, LLC, and Nasdaq ISE, LLC, respectively. See Securities Exchange Act Rel. No. 80248 (Mar. 15, 2017), 82 Fed. Reg. 14547 (Mar. 21, 2017); Securities Exchange Act Rel. No. 80326 (Mar. 29, 2017), 82 Fed. Reg. 16460 (Apr. 4, 2017); and Securities Exchange Act Rel. No. 80325 (Mar. 29, 2017), 82 Fed. Reg. 16445 (Apr. 4, 2017). + |
| fn |
+ 3 Unless otherwise defined herein, capitalized terms are defined as set forth in the CAT NMS Plan. + |
| fn |
+ 4 Adopting Release at 84785. + |
| fn |
+ 6 Adopting Release at 84785 (“For the initial implementation of the CAT, however, the Commission believes a 50 millisecond clock synchronization standard for Industry Members is reasonable at this time.”). + |
| fn |
+ 7 Id. + |
| fn |
+ 8 Id. + |
| fn |
+ 9 The CAT NMS Plan’s public website is available at www.catnmsplan.com. + |
| fn |
+ 10 The Participants asked the following industry trade associations to notify their respective members about the Survey: Financial Information Forum, the Security Traders Association and the Securities Industry and Financial Markets Association. + |
| fn |
+ 11 For purposes of this assessment, “small broker-dealer” has the meaning set forth in Rule 613. In particular, Rule 613(a)(3)(v) states that “small broker-dealer” has the meaning set forth in SEC Rule 0-10(c), which defines a “small broker-dealer” as 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[.] + |
| fn |
+ 12 Specifically, the question listed the following options: order origination systems; order routing systems; order execution or matching systems; co-located systems; internalization systems; back-office systems; third-party systems (including vendor systems); and other (in which case a respondent was asked to identify such other system). Respondents also could indicate that they do not know the types of systems in which they currently maintain synchronized Business Clocks. + |
| fn |
+ 13 See, e.g., Letter from CAT NMS Plan Participants to Brent J. Fields, dated Sept. 23, 2016. + |
| fn |
+ 14 All figures and data discussed in this assessment are approximate and subject to potential minor rounding errors and assumptions. When discussing responses to specific questions regarding synchronization practices (i.e., the non-demographic questions), percentages focus on those respondents that provided information in response to the relevant questions. + |
| fn |
+ 15 Survey responses were identified as “substantially complete” using a two-step process: (1) verification of whether a response was submitted as “complete” (even if some responses were blank); and (2) verification of whether a response was at least 50% complete (generally, responses with less than a 50% completion rate provided only demographic information and no meaningful data regarding Business Clock synchronization practices, costs or views). + |
| fn |
+ 16 Specifically, approximately 12% of respondents stated that they were not FINRA members and approximately 10% stated that they are excluded or exempt from OATS reporting. + |
| fn |
+ 17 Some respondents provided comments with their responses regarding “other” activities. These respondents noted the following activities: execution services, network services and/or technology provider; market maker; ATS; national securities exchange routing facility; financial technology firm; private placement of securities and mutual fund retailer; and principal underwriter and distributor of affiliate insurers’ registered annuity products. + |
| fn |
+ 18 Some of the ATS respondents that believed that different requirements should apply to Execution Venues provided comments with their responses. One ATS respondent explained that Execution Venues currently maintain very tight clock synchronization standards, which is not always the case for non-ATS broker-dealer systems. Two respondents believed that Execution Venues should be subject to more stringent tolerances but they did not provide an explanation for this view. One ATS respondent explained that Execution Venues may adhere to tighter clock synchronization standards than broker-dealers and that requiring broker-dealers to meet the same standards as Execution Venues may impose significant costs and burdens on the broker-dealer community. + |
| fn |
+ 19 Some respondents that indicated that firms voluntarily improve their synchronization tolerances provided additional comments with their responses. One respondent identified itself as a technology firm that can easily adjust its Business Clock synchronization tolerances, so it tries “to be ahead of the curve.” Other respondents generally believe that firms voluntarily work on improving their synchronization tolerances to address customer comments and reduce system latencies (which may provide a competitive advantage). + |
| fn |
+ 20 Some respondents that indicated that firms only improve their synchronization tolerances when required to do so provided additional comments with their responses. Respondents provided various views. Some respondents believed that firms only update synchronization tolerances when required to do so due to costs or limited resources. Others believed that firms only update tolerances when required to do so in the absence of some sort of business or competitive advantage that could be gained by updating tolerances. Some respondents expressed that they believe that regulators often drive changes to tolerances since the regulatory need for lower tolerances may exceed the business need. + |
| fn |
+ 21 Respondents listed the following other factors: competitive advantage; efficient and effective client service; latency concerns; algorithmic high frequency trading; as technology and cost permits (i.e., no directing of scarce resources to unnecessary tasks); and reliance on vendors. + |
| fn |
+ 22 Some respondents provided comments with their responses. Some respondents indicated that they incurred no costs since they already complied with the Business Clock synchronization thresholds required by the Plan. One respondent stated that it achieved a 10 microseconds tolerance at a cost of $1 million to $2 million before the effective date of the Plan. Other respondents reported that they rely on a vendor so they do not incur direct costs or that they do not have any trading activity. + |
| fn |
+ 23 Generally, these respondents provided comments that indicated that they already comply with the thresholds, rely on vendors or do not have trading activities. + |
| fn |
+ 24 One large broker-dealer respondent indicated that it took (or would take) it one year to comply with the initial requirements. + |
| fn |
+ 25 As described in the sections that follow, some respondents provided comments with their responses indicating that they use other solutions. These respondents listed the following as “other” solutions: NIST US time; third-party software/solution; Nagios; and STP. + |
| fn |
+ 26 These respondents indicated that key challenges with respect to synchronizing Business Clocks in geographically disparate systems generally relate to time, monetary costs and resources. One respondent also indicated that challenges include signal quality (e.g., GPS line of site and GPS jamming), network congestion, protocol and software selection and configuration, and real-time monitoring and alerting. Another respondent indicated that traceability across multiple systems is its primary challenge. + |
| fn |
+ 27 In connection with future assessments of the Business Clock synchronization standards set forth in the Plan, the Participants will consider how to improve the efficiency and effectiveness of collecting data from CAT Reporters and the securities industry generally. For instance, the Participants may elect to, without limitation: use targeted studies/surveys or small group discussions with particular types of Industry Members; collect data regarding synchronization practices and thresholds from certain types of Industry Members (e.g., those with the lowest synchronization thresholds) and compare the data to the Participants’ practices and thresholds; analyze data recorded in Industry Members’ synchronization logs; or recommend the implementation of pilot programs where certain CAT Reporters would comply with a narrower synchronization threshold for a period of time to give the Participants an opportunity to assess the costs, benefits and general utility of a narrower threshold. + |
| fn |
+ 28 Adopting Release at 84785. + |
| fn |
+ 29 Alternative Trading Systems with Forms ATS on File with the SEC as of May 3, 2017, available at https://www.sec.gov/files/data/frequently-requested-foia-documentalternative-trading-system-atslist/atslist0517.pdf. Please note that the 83 ATSs referenced above includes both equity and fixed income ATSs as the SEC’s publicly available list does not differentiate equity versus fixed income ATSs. + |
| fn |
+ 30 The Participants believe that it may be appropriate for any future assessment of the costs and benefits of imposing a narrower synchronization threshold on ATSs to take into consideration that ATSs often act in a manner similar to exchanges. + |
| fn |
+ 31 In a future assessment, it may be appropriate to consider whether certain types of Industry Members – such as electronic trading firms using a business model that relies on low latency trading strategies – should be subject to narrower synchronization standards, to the extent that the nature of their business would, in practice, require them to use such narrower standards. The Participants will consider collecting additional data in future assessments to evaluate this question. + |
jurisdiction: US
regulatory_authority: US/SEC
- content_type: compilation
- document_title: CAT Industry Member Reporting Scenarios
- document_type: Scenarios
- source: US/SEC/Scenarios/Member Reporting Scenarios
- source_type: Member Reporting Scenarios
+ content_type: periodic
+ document_title: CAT NMS Plan Potential Expansion
+ document_type: Reports
+ source: US/SEC/Reports/Potential Expansion Report
+ source_type: Potential Expansion Report
language: English
citation: N/A
- pubdate: February 28, 2019 effdate: N/A
- CAT Industry Member Reporting Scenarios
-Topic: CAT Industry Member Reporting Scenarios
- Compliance User: Industry Member
+ pubdate: May 15, 2017 effdate: N/A
+ CAT NMS Plan Potential Expansion
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion
+ Compliance User: Equity Securities
Keywords:
- Technical Specification,
+ File Number 4-698,
+ National Market System Plan Governing the CAT,
- (For IM Technical Specification v1.1)
-2/28/19 DRAFT Version 1.1
-pubdate: N/A effdate: N/A
- Executive Summary
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary
- Compliance User: Industry Member
+ July 19, 2017
+Brent J. Fields
+Secretary
+Securities and Exchange Commission
+100 F Street, NE
+Washington, DC 20549-1090
+Re: File Number 4-698
+National Market System Plan Governing the Consolidated Audit Trail
+Dear Mr. Fields:
+In accordance with Section 6.11 of the National Market System Plan Governing the Consolidated Audit Trail (the “CAT NMS Plan” or “Plan”),1 on May 15, 2017, the Operating Committee for CAT NMS, LLC provided the Securities and Exchange Commission with a document outlining how the Participants2 could incorporate into the consolidated audit trail (“CAT”) information with respect to equity securities that are not NMS Securities or OTC Equity Securities, including Primary Market Transactions in securities that are not NMS Securities or OTC Equity Securities and in debt securities (the “Expansion Report”).3 The Participants determined to update the discussion of equity securities other than NMS Securities and OTC Equity securities that appears on pages 63 and 64 of the enclosed amended Expansion Report.
+Brent J. Fields
+July 19, 2017
+Page2
+Thank you for your attention to this matter. Please contact me at 212-229-2455 if you have any questions or comments.
+
+ cc (via email): The Hon. Jay Clayton, Chairman
+The Hon. Michael S. Piwowar, Commissioner
+The Hon. Kara M. Stein, Commissioner
+Ms. Heather Seidel, Acting Director, Division of Trading and Markets
+Mr. Gary L. Goldsholle, Deputy Director, Division of Trading and Markets
+Mr. David S. Shillman, Associate Director, Division of Trading and Markets
+Mr. David Hsu, Assistant Director, Division of Trading and Markets
+CAT NMS Plan Participants
+pubdate: May 15, 2017 effdate: N/A
+ DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN
+ Compliance User: Equity Securities
Keywords:
- Technical Specifications,
- CAT NMS plan,
+ File Number 4-698,
+ National Market System Plan Governing the CAT,
+ Potential Expansion of 6.11,
+ Sec Rule 613,
+ CAT NMS Plan - Section 6.11,
+ Expansion Document,
- This document is a companion document to the CAT Reporting Technical Specifications for Industry Members (“Technical Specifications”) and is provided to assist Industry Members in implementing the reporting requirements laid out in the Technical Specifications. This document illustrates the specific reporting requirements for a variety of order handling execution scenarios for both equities and options Eligible Securities (as defined in the CAT NMS Plan). The scenarios illustrate the reporting requirements for Phases 2a and 2b. Additional scenarios will be added for Phases 2c and 2d when the Technical Specifications are published for those phases.
-The reporting scenarios are presented in a separated document from the Technical Specifications to provide the greatest flexibility in the ability to modify or add scenarios as new questions are presented and trading practices evolves. It is expected that changes and additions will be necessary for reporting scenarios with greater frequency than changes to the Technical Specifications that would be required when record format, field value changes, etc., occur. By maintaining a separate reporting scenarios document, reporting scenarios may be clarified or added without the need for a new version of the Technical Specifications.
-This document contains interpretive guidance for Industry Member CAT Reporters with respect to how the Technical Specifications must be implemented. As such, any changes to this document are subject to the same review and approval process by the Operating Committee, pursuant to the CAT NMS Plan, as the Technical Specifications.
-This document represents a phased approach to industry reporting. Please note that a proposed amendment to the CAT NMS Plan will be filed with the Securities and Exchange Commission ("Commission") to reflect the phased approach for the Industry member CAT reporting described in the Technical Specifications. The proposed amendment will be subject to the approval of the Commission.
-Revision / Change Process
-
- pubdate: N/A effdate: N/A
- 1. Introduction
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Introduction
- Compliance User: Industry Member
+ PREPARED BY THE PARTICIPANTS TO THE CAT NMS PLAN
+PREPARED MAY 15, 2017
+(AMENDED JULY 19, 2017)
+On July 11, 2012, the Securities and Exchange Commission (“Commission”) adopted Rule 613 of Regulation NMS (“Rule 613”) under the Securities Exchange Act of 1934 (“Exchange Act” or “SEA”)1 to require the national securities exchanges and national securities association to jointly submit a national market system plan to create, implement, and maintain a consolidated audit trail (“CAT”) and central repository.2 On September 30, 2014, the national securities exchanges and the Financial Industry Regulatory Authority (“FINRA”), the sole national securities association (collectively, the “Participants”), filed the National Market System Plan Governing the Consolidated Audit Trail (“CAT NMS Plan”).3 The Commission unanimously approved the CAT NMS Plan, as amended by the Participants and modified by the Commission, and deemed it effective on November 15, 2016.4
+Pursuant to Rule 613(i) and Section 6.11 of the CAT NMS Plan, the Participants are required to “jointly provide to the Commission within six months after effectiveness of the [CAT NMS Plan] a document outlining how [the Participants] could incorporate into the [CAT] information with respect to . . . debt securities, . . . and primary market transactions in debt securities, including details for each order and reportable event that may be required to be provided, which market participants may be required to provide the data, an implementation timeline, and a cost estimate” (“Expansion Document”). Specifically, Rule 613(i) requires the Expansion Document to address expanding the CAT to include:
+1. Equity securities that are not NMS securities,5
+2. Debt securities, and
+3. Primary market transactions in NMS securities, equity securities that are not NMS securities and debt securities.
+In addition, the Expansion Document must include the relevant details for each order and reportable event, identification of the market participants that would be providing the data, an implementation timeline, and a cost estimate for expanding the CAT.6
+pubdate: May 15, 2017 effdate: N/A
+ I. DEBT SECURITIES
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Debt Securities
+ Compliance User: Equity Securities
Keywords:
- Event Reports,
+ Debt Securities,
+ CAT NMS plan,
+ Sec Rule 613,
- This document is organized by product, and then within each product, by general handling scenario, such as order receipt and routing, order execution, etc.
-For each scenario, a description of the scenario along with a diagram is provided and then is followed by specific Event Reports illustrating the correct values to be populated for each field.
-pubdate: N/A effdate: N/A
- 2. Equity Scenarios and Examples
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples
- Compliance User: Industry Member
- Keywords:
- This section will illustrate sample equity reporting scenarios. Each scenario will include a brief scenario description including the reportable order events, a flow chart, and step-by-step reporting responsibilities.
-pubdate: N/A effdate: N/A
- 2.1. Order Origination and Route Scenarios
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios
- Compliance User: Industry Member
+ pubdate: May 15, 2017 effdate: N/A
+ A. Debt Securities Market Background
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Debt Securities, Debt Securities Market Background
+ Compliance User: Equity Securities
Keywords:
- Order,
+ Debt Securities,
+ CAT NMS plan,
+ Sec Rule 613,
+ CMO,
- pubdate: N/A effdate: N/A
- 2.1.1. New Principal Order Routed to Exchange and Executed
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, New Principal Order Routed to Exchange and Executed
- Compliance User: Industry Member
- Keywords:
- Industry Member Broker 1,
- Route Scenarios,
-
- This scenario illustrates the reporting requirements to CAT for an Industry Member that creates a new principal order, routes it to an exchange, and then the order is executed on the exchange.
-For this scenario, Industry Member Broker 1 is required to report the following events:
-• The creation of a New Order (Principal)
-• The route to an exchange as an Order Route event
-Note that the execution will be reported by the exchange, Broker 1 does not need to report the fill received.
-
-
-
- pubdate: N/A effdate: N/A
- 2.1.2. Customer Order Routed to Exchange as Agent
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Customer Order Routed to Exchange as Agent
- Compliance User: Industry Member
- Keywords:
- Average Price Bases,
-
- This scenario illustrates the reporting requirements to CAT for an Industry Member that routes a customer order to an exchange on an agency basis.
-For this scenario, Industry Member Broker 1 is required to report the following events:
-• New Order event for the customer order
-• Order Route event for routing the customer order to the exchange
-In this scenario, since the execution is passed back directly to the customer, no Order Fulfillment event is required to be reported.
-
-
-
- pubdate: N/A effdate: N/A
- 2.1.3. Customer Order Fulfilled on Average Price Basis
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Customer Order Fulfilled on Average Price Basis
- Compliance User: Industry Member
- Keywords:
- Two Industry Members,
-
- This scenario illustrates the reporting requirements to CAT for an Industry Member that works a customer order through an average price account by routing one or more representative orders to the exchange. The Industry Member then fills the customer order on an average price basis.
-For this scenario, Industry Member Broker 1 is required to report the following events:
-• New Order event for the customer order
-• New Order event for the representative order created from the average price account
-• Order Route event for each representative order, or portion of the representative order, routed to the exchange
-• Order Fulfillment event to report the average price given to the customer
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.1.4. Order Routed between Two Industry Members and Subsequently Executed
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Order Routed between Two Industry Members and Subsequently Executed
- Compliance User: Industry Member
- Keywords:
- Multiple Industry Members,
-
- This scenario illustrates the reporting requirement when an order is routed from one Industry Member to another.
-
- For this scenario, Industry Member Broker 1 is required to report the following events:
-• New Order event for the customer order
-• Order Route event for routing the customer order to Broker 2
-For this scenario, Industry Member Broker 2 is required to report the following events:
-• Order Accepted event for the received client order from Broker 1
-• Order Route event for routing the client order to the exchange
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.1.5. Order Split and Routed to Multiple Industry Members, Exchange, and Filled
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Order Split and Routed to Multiple Industry Members, Exchange, and Filled
- Compliance User: Industry Member
- Keywords:
- Routing Broker,
-
- This section illustrates the reporting requirement when a customer order is split and each slice is subsequently routed to different parties - external Industry Member and subsequently an exchange and to an ATS.
-
- For this scenario, Industry Member Broker 1 is required to report the following events:
-• New Order event for the customer order
-• Order Route event for the routing of an order slice to Broker 2
-• Order Route event for the routing of an order slice to ATS 3
-For this scenario, Industry Member Broker 2 is required to report the following events:
-• Order Accepted event for the received client order from Broker 1
-• Order Route event for routing of the order to Exchange 1
-For this scenario, Industry Member ATS 3 is required to report the following events:
-• Order Accepted event for the received client order from Broker 1
-• Trade event when the order is matched
-
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.1.6. Order Routed from an Exchange through a Routing Broker to another Exchange
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Order Routed from an Exchange through a Routing Broker to another Exchange
- Compliance User: Industry Member
- Keywords:
- Broker,
- Industry Member Broker 1,
- original manual timestamp,
-
- This section will show the scenario when one exchange routes an order via a routing broker who is an Industry Member to another exchange.
-
- For this scenario, the exchange that routes the order (Exchange 1) must report:
-• The route of the order to its routing broker
-• After the execution, a Fill of the routed order
-The routing broker (Industry Member Broker 1) must report the following events:
-• The receipt of the order from the exchange as an Order Accepted event
-• Order Route event for the route of the order to another exchange
-The exchange that accepts the routed order (Exchange 2) must report the following events:
-• The receipt of the order routed from Broker 1; and
-• Any subsequent order handling events, if applicable
-
-
- pubdate: N/A effdate: N/A
- 2.1.7. Manual Order Route Followed by Electronic Route, Merged Event
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Manual Order Route Followed by Electronic Route, Merged Event
- Compliance User: Industry Member
- Keywords:
- This scenario illustrates the reporting requirements when an Industry Member manually routes an order to another Industry Member and follows up with an electronic route message.
-
- For this scenario, the sending Industry Member Broker 1 is required to report:
-• New Order event for the customer order
-• Order Route event for the electronically routed order (inclusive of routedOrderID) to Broker 2 with both the electronic and original manual timestamp
-For this scenario, the receiving Industry Member Broker 2 is required to report:
-• Order Accepted event for the electronically received client order (inclusive of routedOrderID) from Broker 1 with both the electronic and original manual timestamp
-
-
- pubdate: N/A effdate: N/A
- 2.1.8. Manual Order Route, Electronic Duplicate Order
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Manual Order Route, Electronic Duplicate Order
- Compliance User: Industry Member
- Keywords:
- CAT Reporting,
- Industry Member Broker,
-
- This scenario illustrates the Phase 2a reporting requirements when an Industry Member manually routes an order but is unable to merge the manual and electronic copies of the order into a single message for CAT Reporting. The Industry Member may report a manual order route event without a routedOrderID, followed by an electronic event which must include electronicDupFlag = true.
-For this scenario, Industry Member Broker 1 is required to report:
-• New Order event for the receipt of the customer order
-• Order Route event for the manual route to Broker 2
-• Order Route event for the electronic route message sent to Broker 2 (marked with electronicDupFlag = true)
-For this scenario, Industry Member Broker 2 is required to report:
-• Order Accepted event once agreeing to the route from Broker 1
-• Order Accepted event for the receipt of the electronic order route from Broker 1 (marked with electronicDupFlag = true)
-
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.1.9. Manual Order, One Side Reports Merged Event
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Manual Order, One Side Reports Merged Event
- Compliance User: Industry Member
- Keywords:
- Manual Order,
-
- This scenario illustrates the Phase 2a reporting requirements when an Industry Member manually routes an order to anther Industry Member. The sending Industry Member chooses to report a single merged order event with both a manual and systematized timestamp, but the receiving Industry Member reports the receipt of the order twice - once for the manual receipt of the order followed by an electronic duplicate event which includes the electronicDupFlag = true. Note that in Phase 2a, events with either manualFlag = true or electronicDupFlag = true will not be subject to the standard inter-firm linkage process.
-For this scenario, the sending Industry Member Broker 1 is required to report:
-• New Order event for the customer order
-• Order Route event for the electronically routed order (inclusive of routedOrderID) to Broker 2 with both the electronic and original manual timestamp
-For this scenario, the receiving Industry Member Broker 2 is required to report:
-• Order Accepted event for agreeing to the route from Broker 1 (with manualFlag = true)
-• Order Accepted event for the receipt of the electronic order route from Broker 1 (marked with electronicDupFlag = true)
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.2. Trade Scenarios
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Trade Scenarios
- Compliance User: Industry Member
- Keywords:
- pubdate: N/A effdate: N/A
- 2.2.1. Agency Order Cross
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Trade Scenarios, Agency Order Cross
- Compliance User: Industry Member
- Keywords:
- New Order event,
-
- This scenario illustrates the reporting requirements to CAT when an Industry Member (Broker 1) matches a Customer Buy order with a Sell order routed from another Industry Member (Broker 2).
-
- For this scenario, Industry Member Broker 1 is required to report the following events:
-1) The receipt of the order from the customer (New Order event)
-2) The receipt of the order routed from Broker 1 (Order Accepted event)
-3) The execution (Trade event)
-Industry Member Broker 2 would report the following events:
-1) The receipt of customer order (New Order event)
-2) The route of the order to Broker 1 (Order Route event)
-The customer Order A at Broker 1 was fully executed, while the routed order from Broker 2 was partially executed.
-For ATS agency order cross, please refer to Section 2.2.1 step 10 for more details.
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.2.2. Internalized Trade against Proprietary Account
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Trade Scenarios, Internalized Trade against Proprietary Account
- Compliance User: Industry Member
- Keywords:
- Trade Event,
- Industry Member Broker 1,
-
- This scenario illustrates the reporting requirements to CAT for an Industry Member that executes a customer order against its own proprietary account.
-For this scenario, Industry Member Broker 1 is required to report the following events:
-• The receipt of the customer order as a New Order event (New Order event)
-• The execution as a Trade event
-
-
- pubdate: N/A effdate: N/A
- 2.2.3. ATS Cross with Multiple Orders on One Side
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Trade Scenarios, ATS Cross with Multiple Orders on One Side
- Compliance User: Industry Member
- Keywords:
- Order,
- ATS A,
-
- This scenario illustrates the reporting requirement when an ATS performs a cross that has multiple orders on one side. For this case, the ATS must report:
-• The receipt of the three orders involved in the execution (three Order Accepted events)
-• Two Trade Events
-
-
-
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.2.4. Negotiated Trade
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Trade Scenarios, Negotiated Trade
- Compliance User: Industry Member
- Keywords:
- Industry Member,
- New Order,
- New Order and Trade,
-
- This scenario illustrates the reporting requirement when an Industry Member executes a customer order as the result of negotiating a trade with another Industry Member (e.g. through a system such as OTCLink). For this case, Industry Member Broker 1 (initiator) is required to report the following:
-• The receipt of the customer order in a New Order event
-• The execution of the order (Trade event)
-Industry Member Broker 2 (respondent) must report the following to CAT:
-• A New Order event
-• The execution of the order (Trade event)
-All of the New Order and Trade events occurring within the negotiation process must have the negotiatedTradeFlag and negotiatedTradeSide present and marked properly.
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.2.5. Trade as the Result of a Quote
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Trade Scenarios, Trade as the Result of a Quote
- Compliance User: Industry Member
- Keywords:
- Market Maker,
- Industry Member Market Maker,
- Industry Member OTCM,
-
- This scenario illustrates the reporting requirements to CAT when a Market Maker (and Industry Member Market Maker A) submits a displayed (bid) quote to an inter-dealer quotation system - Industry Member OTCM, another Market Maker (and Industry Member, Market Maker B) wants to trade at the displayed quote, sends a message through the inter-dealer quotation system, consummating in a trade.
-In Phase 2a, Industry Member Market Maker A is required to report the following event:
-• A Trade as a Result of a Quote event for execution against Market Maker B
-For this scenario, Industry Member Market Maker B must report the following event:
-• A New Order event
-• A Trade event for execution against Market Maker A
-For this scenario Industry Member OTCM must report the following event:
-• Quote Received event for the receipt of the quote from Market Maker A
-
-
-
-
+ pubdate: May 15, 2017 effdate: N/A
+ 1. Scope of the Term “Debt Securities”
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Debt Securities, Debt Securities Market Background, Scope of the Term "Debt Securities"
+ Compliance User: Equity Securities
+ Keywords:
+ CAT NMS Plan - Section 6.11,
+ Debt Securities,
+ NYSE,
+ MSRB,
+ FINRA,
+ TRACE,
+ Corporate Bonds,
+ Asset-Backed Securities,
+ Agency Debt Securities,
+ Collateralized Mortgage Obligations,
+ Small Business Administration,
+
+ Section 6.11 of the CAT NMS Plan, which implements Rule 613(i), requires that the Expansion Document address the possible expansion of CAT to “debt securities.” Although there is no definition of the term “debt securities” in Rule 613, when proposing Rule 613, the Commission indicated that it intends that the CAT eventually would be expanded to include corporate bonds, asset-backed securities, municipal bonds, and other debt instruments.7
+Debt securities are issued by many different entities, including the U.S. government, counties, cities, corporations, and financial institutions, as well as international bodies and can take the form of a number of different security types. Debt securities can vary based on factors such as issuer characteristics (e.g., federal government versus private corporations) and issue characteristics (e.g., coupon rate, collateral, maturity), and trading practices in different types of debt securities can also vary (e.g., electronic trading versus voice messaging). Such differences can also lead to different clientele for the instruments. For example, while there is a lot of retail participation in the municipal securities market, mainly due to the tax advantage of interest income for some investors, the corporate bond market has a combination of retail and institutional investors, and securitized products are mainly traded by institutions.
+There are also differences in regulatory reporting across debt securities. FINRA, the New York Stock Exchange (“NYSE”), and the Municipal Securities Rulemaking Board (“MSRB”)8 each already require reporting of certain information for debt securities. The MSRB’s rules govern the reporting of transactions in municipal securities.9 The NYSE’s rules govern the entry, display and execution of orders and the reporting of transactions in debt securities on the NYSE Bonds® system.10 FINRA rules govern the reporting of trades in most other types of debt securities. The debt securities currently reportable to FINRA’s Trade Reporting and Compliance Engine (“TRACE”) system include:11
+• Corporate Bonds: Corporate bonds are issued by individual companies to raise money for capital expenditures, operations, and acquisitions. There are many types of corporate bonds with various structures, coupon rates, maturity dates and credit quality, among other characteristics.12
+• Asset-Backed Securities (“ABSs”): ABSs are certificates that represent an interest in a pool of assets such as credit card receivables, auto loans and leases, home equity loans, and even the future royalties of a musician. This class includes Mortgage-Backed Securities (“MBSs”).13
+• Agency Debt Securities (“Agencies”): There are two types of Agencies: (1) bonds issued or guaranteed by U.S. federal government agencies; and (2) bonds issued by government-sponsored enterprises (“GSEs”)—corporations created by Congress to foster a public purpose, such as affordable housing. Bonds issued or guaranteed by federal agencies such as the Government National Mortgage Association (Ginnie Mae) are backed by the “full faith and credit of the U.S. government,” like Treasuries. This is an unconditional commitment to pay interest payments and to return the principal investment in full to the security holder when a debt security reaches maturity. Bonds issued by GSEs such as the Federal National Mortgage Association (Fannie Mae), the Federal Home Loan Mortgage (Freddie Mac), and the Federal Agricultural Mortgage Corporation (Farmer Mac) are not backed by the same guarantee as federal government agencies.14
+• Collateralized Mortgage Obligations (“CMOs”): CMOs are debt securities that are backed by mortgage loans or assets derived from MBSs, including Real Estate Mortgage Investment Conduit (“REMICs”).15
+• Small Business Administration (“SBA”) Backed ABS: An SBA-Backed ABS is a debt instrument issued by a program of the SBA for which the timely payment of principal and interest is guaranteed by the SBA. An SBA-Backed ABS represents an ownership interest in a pool or pools of loans or debentures and structured to “pass through” the principal and interest payment made by the borrowers in such loans or debentures to the holders of the security on a pro rata basis.16
+In addition to FINRA’s TRACE reporting requirements, the MSRB requires reports of transactions in municipal securities, which are debt securities issued by states, cities, counties and other state or local governmental entities to raise money to fund public projects. Most municipal debt pays a specified amount of interest (usually semiannually) and returns the principal to the security holder on a specific maturity date.17 Because the MSRB is not a Participant in the CAT NMS Plan, it did not participate in preparation of the Expansion Document, and since the MSRB has specific jurisdiction over municipal securities, the Participants recommend that the MSRB be consulted before any analysis regarding the potential expansion of the CAT to municipal securities is undertaken.18 Thus, although some concepts discussed in the Expansion Document may be relevant to municipal securities, it is generally focused on debt securities that are reportable to TRACE or the NYSE as of the date of the Expansion Document.
+pubdate: May 15, 2017 effdate: N/A
+ 2. Debt Markets v. Equity Markets
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Debt Securities, Debt Securities Market Background, Debt Markets v. Equity Markets
+ Compliance User: Equity Securities
+ Keywords:
+ Debt Markets,
+ Equity Markets,
+ TRACE,
+ Daily Trading Volume,
+ FINRA,
+ NYSE,
+
+ The U.S. debt markets and equity markets are vastly different in most material respects. As noted above, the markets vary significantly in types of issuers, issue characteristics, trading, and regulatory regimes such as the level of market transparency on both a pre- and post-trade basis. All of these differences would influence how expanding the CAT to include reporting for debt securities could be efficiently and effectively achieved. Below, we describe some of the key characteristics of the government and corporate debt markets.
+First, the U.S. debt market is significantly larger than the equities market in terms of both the number of outstanding securities and the amount of capital raised; however, the size of the U.S. debt market is heavily influenced by U.S. Treasury securities.19 Second, there are significantly more issuances of debt securities as compared with equity securities. Many public companies may have only one class of stock, but can issue numerous types of bonds with different yields, maturities, and denominations.20 For example General Electric has only one class of stock, but it has issued over 1,000 unique bonds.21 In addition, daily trading volumes are significantly different for equities than for debt, with the number of trades in equity securities far surpassing trades in debt securities.
+The following charts highlight some of the more significant differences between the debt markets and the equity markets. Chart 1 compares the monthly value of new issue corporate bonds and public corporate stocks in the United States from January 2015 to January 2017.22
+
+ Chart 2 demonstrates the number of issues in the U.S. debt and equities markets by charting the number of unique CUSIPs reportable to a FINRA facility as of the beginning of the calendar year for each of the last five years.23 As the chart makes clear, there are significantly more CUSIPs for debt securities than for equity securities.24
+
+ Chart 3 displays the average daily trading volume for U.S. corporate debt, all TRACE reported debt, and exchange-listed equity securities for each month from January 2016 to March 2017.25 As the chart makes clear, in any given month the trading volume on equities exchanges is generally over five times that in U.S. corporate debt. However, when compared with all TRACE reported debt, the notional volume of transactions in U.S. debt and exchange-listed equity securities is relatively similar due to the high notional volume of transactions in Agency MBSs.
+
+ Chart 4 shows the combined equity trades on exchanges compared to the TRACE reported trades during each quarter of 2016.26 Despite the fact that there are substantially more bonds in the market and more new bond issuances, the volume of equity trades is higher, and there are significantly more equity transactions on a daily basis than bond transactions. While exchanges had in excess of 1.5 billion trades each quarter, with one quarter over 2.5 billion, TRACE averages only 4.5 million reported trades per quarter.
+
+ Another major difference between the bond and equity markets is the size of the trades. The dollar value of bond transactions typically is greater than stock transactions. The average size of a bond trade exceeds $500,000 whereas the average stock trade is less than $10,000.27 These large transaction sizes are the result of a substantial portion of transactions by institutional investors in the debt markets as compared to the equity markets.28 Chart 5 uses Federal Reserve financial sector data to chart retail investors in different bond types.
+Chart 5: Presence of Retail Investors in the Bond Market29
+
+ In general, the debt markets have a much higher proportion of institutional market participants than in the equity markets, in which retail investor participation is substantially higher.30 However, for purposes of Chart 5, institutional investors include mutual funds, pension funds, insurance companies, and endowments. When these forms of indirect ownership are factored in, 49% of U.S. households are invested in bonds.31
+Two other major differences between the debt and equity markets are related. Due to the vast number and variety of debt securities outstanding, most individual debt securities trade much less often than a typical stock, particularly listed stocks. For an equity security that is listed on an exchange, there is an active market for the stock, and, consequently, it is easy to obtain a current price for any particular listed stock. However, bonds and other debt securities tend to actively trade during the period after their initial issue, but, thereafter, trading in a particular debt security may not occur for months or even years.
+Chart 6: Trading Volume Reduction in Corporate Debt 90 Days After Issuance32
+
+ Because of the relative lack of liquidity in the debt markets compared to the equity markets, there is significantly less pre-trade price transparency for most debt securities compared to equity securities. In addition, because of the relative lack of trading activity in the debt markets compared to the equity markets, it is significantly less difficult to link specific orders in debt securities to resultant trades. For example, an order in an equity security may be split into numerous child orders (or numerous orders can be aggregated into a larger order). By requiring that the parent order and each child order be linked, the equity order audit trail provides insight into these relationships that otherwise would be difficult to ascertain.
+Along with these fundamental differences in the character of equity versus debt securities, the manner in which orders are handled in the two markets—and even what constitutes an “order”—and how trades are executed, differ substantially. In the debt market, it is common for an investor to contact his or her broker to purchase a bond with certain characteristics (e.g., a specific yield, credit rating or maturity) rather than a particular security, and the broker will reach out to other bond brokers and assess what debt securities that meet those criteria are available. Based on this information, the broker generally provides the investor with options, and the investor can choose a particular debt security to purchase when presented with the options. FINRA requires its members to submit trade reports to TRACE and disseminates some of this information; however, this information is limited to post-trade transparency and is subject to other limitations, such as volume thresholds. By contrast, exchanged-listed stocks always have pre-trade bid and offer prices available, often on multiple trading centers.
+Finally, unlike most equity securities, most debt securities are traded over-the counter (“OTC”) rather than on an exchange. In 2017, approximately 10,000 of the approximately 61,500 corporate bonds outstanding–approximately 16% were reportable to NYSE’s bond trading platform, which is the largest centralized corporate bond exchange in the U.S..33 The vast majority of transactions in debt securities are executed through informal networks of bond dealers in the OTC market. Further, while there has been significant growth in electronic trading venues for bonds in recent years—the number of corporate bond transactions occurring on ATSs has grown to approximately 20%—much of the activity in this space occurs as a Request for Quote (“RFQ”) or similar format where the terms of a trade are negotiated bilaterally.34
pubdate: N/A effdate: N/A
- 2.3. Fulfillment Scenario s
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s
- Compliance User: Industry Member
- Keywords:
- pubdate: N/A effdate: N/A
- 2.3.1. Representative Order Execution
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Representative Order Execution
- Compliance User: Industry Member
- Keywords:
- This section will illustrate the Phase 2a reporting requirements for the execution of a customer/client order that is not required to be reported for public dissemination purposes and use of an Order Fulfillment, rather than a Trade Event, is required.
-In this scenario, Industry Member Broker A receives two customer orders to BUY XYZ at 10.01. Industry Member Broker A creates a representative order that will be used to fill two customer orders. The representative order is routed to an exchange where it is executed. Upon execution of the representative order, the Industry Member fills each of the customer orders on an agency basis.
-For this scenario, Broker A is required to report the following events to CAT for the customer orders:
-1) New Order events for the customer orders
-2) An Order Fulfillment for each customer order
-Broker A is required to report the following events to CAT for the representative order:
-1) New Order event for the representative order (flagged to indicate it represents customer orders, but no explicit linkage to the underlying orders)
-2) Routing the representative order to the exchange (Order Route event)
-Note that execution of the representative order is only reported by the exchange.
-Because this scenario involves an aggregation of two customer orders that are worked as a single representative order, this is a Phase 2c representative order scenario and linkage between the customer orders and the representative orders is not required. In Phase 2c, the representative order and the underlying customer orders must be linked.
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.3.2. Fill of a Single Order on a Riskless Principal Basis
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Fill of a Single Order on a Riskless Principal Basis
- Compliance User: Industry Member
- Keywords:
- Order Route Event,
- New Order event,
-
- This scenario illustrates the CAT reporting requirements when an Industry Member fills an order as riskless principal.
-In this example, upon receipt of the customer order, the Industry Member sends a riskless principal or principal order to an exchange for execution, in order to satisfy the customer's order. The representative principal order is linked to the original customer order.
-
- The Industry Member Broker 1 is required to report the following events to CAT:
-• The creation of the customer order as a New Order event
-• The creation of a riskless principal order with linkage to the original customer order (New Order event with aggregatedOrders field). As an alternative, the Industry Member may report a New Order event (for the principal order) without linkage to the customer order, and an additional New Order Supplement event
-• The route of the principal order to the exchange (Order Route event)
-• After the execution, the flip of the executed shares back to the customer order (an Order Fulfillment Event).
-The exchange will report the following:
-• The receipt of the order B routed from the Broker 1
-• The execution of order
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.3.3. Customer Order Internally Routed to Another Desk and Subsequently Executed Against a Firm Proprietary Account
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Customer Order Internally Routed to Another Desk and Subsequently Executed Against a Firm Proprietary Account
- Compliance User: Industry Member
- Keywords:
- Order Internal Route event,
- Trade Event,
-
- This section will illustrate an example of CAT reporting when an Industry Member internally routes a customer order from the sales desk to the trading desk, and subsequently executes against a firm proprietary account. The sales desk and trading desk are separated by information barriers.
-
- In this scenario, Industry Member Broker 1 must report the following events to CAT:
-• The receipt of the customer order in a New Order event
-• The internal route from the sales desk to the trading desk (Order Internal Route event)
-• The principal execution (Trade event)
-
-
- pubdate: N/A effdate: N/A
- 2.3.4. Customer Order Internally Routed to Multiple Desks and Subsequently Executed
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Customer Order Internally Routed to Multiple Desks and Subsequently Executed
- Compliance User: Industry Member
- Keywords:
- Program Trading Desk,
-
- This scenario illustrates the CAT reporting requirements when an Industry Member internally routes a customer order from the sales desk to multiple desks within the Industry Member. Each destination desk subsequently internally fills the order. Each internal route and execution must be reported separately.
-
- For this scenario, Industry Member Broker 1 is required to report the following events for CAT:
-• At the Sales Desk
-• New Order event for the customer order
-• At the Trading Desk
-• Order Internal Route event from the sales desk to the trading desk
-• The principal execution as a Trade event
-• At the Arbitrage Desk
-• Order Internal Route event from trading desk to the arbitrage desk
-• The principal execution as a Trade event
-• At the Program Trading Desk
-• Order Internal Route event from the trading desk to the program trading desk
-• The principal execution as a Trade event
-
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.3.5. Internal Route and Execution, Leaves Quantity Routed Externally
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Internal Route and Execution, Leaves Quantity Routed Externally
- Compliance User: Industry Member
- Keywords:
- This scenario illustrates the reporting requirements to CAT when an Industry Member internally routes an order to another desk where it is partially executed and the remainder is routed to another Industry Member to execute.
-
- Industry Member Broker 1 is required to report the following events:
-• New Order event for the customer order
-• Order Internal Route from the Sales Desk to the Trading Desk
-• Trade event for the partial execution of the customer order
-• Order Route of the remaining shares to Broker 2
-Industry Member Broker 2 is required to report the following events:
-• Order Accepted event for the order from Broker 1
-• Trade event for the execution of Broker 1's order
-
-
-
- pubdate: N/A effdate: N/A
- 2.3.6. Fill of a Customer Order from a Pre-Existing Principal Order
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Fill of a Customer Order from a Pre-Existing Principal Order
- Compliance User: Industry Member
- Keywords:
- Order Fulfillment event,
-
- This scenario illustrates the reporting requirements to CAT for an Industry Member that creates a new principal order and routes it to an exchange. Before execution of the principal order, the Industry Member receives a customer order. Upon execution of the principal order, the Industry Member fills the customer order on a riskless principal basis.
-For this scenario, Industry Member Broker 1 is required to report the following events:
-• The creation of a new principal order (New Order event)
-• Route the principal order to an exchange via an Order Route event
-• The receipt of a customer order (New Order event)
-• Fill of the customer order with the executed principal order via an Order Fulfillment event
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.3.7. Fill of a Customer Order from a Pre-Existing Principal Order with Better Price than the Representative Order
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Fill of a Customer Order from a Pre-Existing Principal Order with Better Price than the Representative Order
- Compliance User: Industry Member
- Keywords:
- This scenario illustrates the reporting requirements to CAT for an Industry Member that creates and routes a representative order to work a customer order, but ultimately fills the customer order with an existing principal order that executed at a better price.
-For this scenario, Industry Member Broker 1 is required to report the following events:
-• A New Order event for the creation of the principal order
-• The route of the principal order to the exchange (Order Route event)
-• The receipt of the customer order as a New Order event
-• The creation of the representative order as a New Order event
-• The route of the representative order to the exchange as an Order Route event
-• An Order Fulfillment event for the fill of the customer order against the principal order
-
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.3.8. Route to Foreign Broker
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Route to Foreign Broker
- Compliance User: Industry Member
- Keywords:
- CAT Reporter,
-
- This scenario illustrates the reporting requirements to CAT for an Industry Member (Broker 1) that routes an order to a foreign broker-dealer. Because the foreign broker dealer is not a CAT reporter, Broker 1 must report an Order Fulfillment event to represent the outcome of the customer order.
-For this scenario, Industry Member Broker 1 is required to report the following events:
-• A New Order event for the receipt of customer order
-• An Order Route event for the routing of the order to the foreign broker
-• An Order Fulfillment event to show the executed shares given back to the customer
-
-
-
- pubdate: N/A effdate: N/A
- 2.3.9. Order Fulfillment Amendment
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Order Fulfillment Amendment
- Compliance User: Industry Member
- Keywords:
- In the following scenario, the Industry Member amends the price of a customer fill that was reported to CAT on a previous day.
-For this scenario, Industry Member Broker 1 is only required to report an Order Fulfillment Amendment event for T+1.
-
- Note that the amendment reporting is only applicable to Order Fulfillment events, not the events reported to the TRF for media dissemination (which would have originally been reported as Trade events).
-
- pubdate: N/A effdate: N/A
- 2.4. Order Modification Scenarios
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios
- Compliance User: Industry Member
- Keywords:
- pubdate: N/A effdate: N/A
- 2.4.1. Customer Order and Modification
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Customer Order and Modification
- Compliance User: Industry Member
- Keywords:
- Order Modified event,
-
- This scenario illustrates the reporting requirements to CAT for an Industry Member for a customer initiated modification on an order.
-
- For this scenario, Industry Member Broker 1 is required to report the following events:
-• New Order event for the customer order
-• Order Modified event upon receipt of customer request
-
-
- pubdate: N/A effdate: N/A
- 2.4.2. Customer Initiated Modification of Order Previously Routed to Exchange
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Customer Initiated Modification of Order Previously Routed to Exchange
- Compliance User: Industry Member
- Keywords:
- Order Modification event,
- EXCH1,
-
- This scenario illustrates a customer-initiated modification of an order which the Industry Member had previously routed to an exchange.
-In this scenario, Industry Member Broker 1 is required to report the following events to CAT:
-• A New Order event for the receipt of customer order
-• Order Route event for the route to the exchange
-• An Order Modification event
-• A second Order Route event for the route of the modified order to the exchange
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.4.3. Customer Initiated Modification of Order Previously Routed to Another Industry Member
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Customer Initiated Modification of Order Previously Routed to Another Industry Member
- Compliance User: Industry Member
- Keywords:
- EXCH1,
-
- This scenario illustrates the reporting requirements to CAT for two Industry Members when a customer of the first Industry Member initiates a modify on an order. The example shown does not illustrate events that would occur following the second Order Route event to account for the New Order and Order Accepted events, such as cancellations, trades, or fulfillments.
-
- For this scenario, Industry Member Broker 1 is required to report the following events:
-• New Order event for the customer order
-• Order Route event for the routing of the order to Broker 2
-• Order Modified event for customer initiated modification
-• Order Route event for the routing of the modified order to Broker 2
-For this scenario, Industry Member Broker 2 is required to report the following events:
-• Order Accepted event for the received client order from Broker 1
-• Order Modified event upon receiving the modify notice from Broker 1
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.4.4. System Driven Modification of Previously Routed Order
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, System Driven Modification of Previously Routed Order
- Compliance User: Industry Member
- Keywords:
- This scenario illustrates the reporting requirements to CAT for two Industry Members when the Industry Member sending an order uses a programmed algorithmic system, which modifies the order routes. Since the order modification is determined by the algorithm and not by the sending Industry Member, the sending Industry Member does not need to report subsequent Order Route events. The modifications driven by the algorithm are captured by the receiving Industry Member in an Order Modified event.
-For this scenario, sending Industry Member Broker 1 is required to report the following events:
-• New Order event for the accept of the customer order
-• Order Route event for the routing of the order to Broker 2
-For this scenario, receiving Industry Member Broker 2 is required to report the following events:
-• Order Accepted event for the received order from Broker 1
-• Order Modified event upon receiving the modify from Broker 1
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.4.5. Order Modification of a PEG Order by a Display ATS
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Order Modification of a PEG Order by a Display ATS
- Compliance User: Industry Member
- Keywords:
- Section 6.4(d)(i) of the CAT NMS Plan,
- Order Adjusted Event,
- CAT NMS plan,
- Per CAT FAQ #H1,
- Broker 1,
-
- This section will show how an Order Adjusted Event is reported when a display ATS reprices a peg order. Per CAT FAQ #H1, each time an Industry Member reprices a peg order based on a market move (i.e., 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.
-In this scenario, Industry Member Broker 1 routes a customer midpoint PEG order to ATS A. ATS A gives the order a working price upon receipt. Then the NBBO changes while the order stays open on the book. The ATS reprices the order which is required to be reported to CAT.
-Industry Member Broker 1 in this case is required to report:
-• The receipt of customer order (New Order event)
-• The route of the order to the ATS in an Order Route event
-ATS A must report:
-• An Order Accepted event for the receipt of the PEG order from Broker 1
-• The modification of the price due to NBBO changes - this should be reported using an Order Adjusted Event with only the price fields restated
-
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.4.6. Display Modifications of a Display ATS
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Display Modifications of a Display ATS
- Compliance User: Industry Member
- Keywords:
- Order Adjusted Event,
-
- Display modifications can be reported to CAT using the Order Adjusted event. This scenario illustrates the reporting requirements when an order is partially executed on an ATS, and as a result the display size of the order changes.
-
- In this scenario, an order is routed to an ATS for execution. The sending Industry Member Broker 1 is required to report:
-• Receipt of the order from the customer in a New Order event
-• An Order Route event of the order route to ATS A
-ATS A is required to report:
-• An Order Accepted event for the receipt of the order routed from Broker 1
-• Partial execution of the order as a Trade Event
-• Update to the display size post execution as an Order Adjusted event
-Note that ATS A and Broker 1 may have subsequent order handlings on the order. This example is to illustrate the display modification reporting only, so not all possible steps are shown here.
-
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.4.7. Manual Route, Followed by an Electronic Modification
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Manual Route, Followed by an Electronic Modification
- Compliance User: Industry Member
- Keywords:
- Industry Member Broker 2,
- Order Route Event,
- Order Modified event,
-
- This scenario illustrates the Phase 2a reporting requirement to CAT when an order is initially routed manually between two Industry Members, and then an electronic message is sent to modify the material terms of the order.
-
- In this scenario, Industry Member Broker 1 must report:
-• Receipt of the customer order in a New Order event
-• Manual route of the order to Broker 2 (Order Route event)
-• Order Modified event for reducing the quantity of the order
-• Route of the modified order to Broker 2 (Order Route event)
-The following must be reported by Industry Member Broker 2:
-• Receipt of the manual route from Broker 1 (Order Accepted event)
-• An Order Modified event for reducing quantity of the order (Order Modified event)
-
-
-
-
+ pubdate: May 15, 2017 effdate: N/A
+ B. Current Audit Trail Requirements for Debt Securities
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Debt Securities, Current Audit Trail Requirements for Debt Securities
+ Compliance User: Equity Securities
+ Keywords:
+ TRACE,
+ Debt Securities,
+ TRACE-Eligible Securities,
+
+ pubdate: May 15, 2017 effdate: N/A
+ 1. TRACE Reporting Requirements
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Debt Securities, Current Audit Trail Requirements for Debt Securities, TRACE Reporting Requirements
+ Compliance User: Equity Securities
+ Keywords:
+ TRACE,
+ Debt Securities,
+ TRACE-Eligible Securities,
+ FINRA Rule 6730,
+ TRACE Reporting Timeframes,
+ Information Reported to TRACE,
+ Transactions Excepted from TRACE,
+ Transactions Exempted from TRACE,
+
+ a. Debt Securities Reportable to TRACE and Reporting Timeframes
+Pursuant to the FINRA Rule 6700 Series (“TRACE Rules”), broker-dealers that are FINRA members generally are required to report executed transactions in TRACE-Eligible Securities35 to FINRA through the TRACE system, unless an exception or exemption applies.36 FINRA uses the information reported to TRACE for regulatory purposes and disseminates certain transaction information publicly. “TRACE-Eligible Security” includes corporate bonds, Agencies37 and Securitized Product38 (“SP”) sub-types. SPs include ABSs,39 Agency Pass-Through Mortgage-Backed Securities,40 SBA-Backed ABSs,41 and any other SP.
+FINRA Rule 6730 prescribes the period of time within which a reportable transaction in a TRACE-Eligible Security must be reported to TRACE: (1) corporates, agencies, ABSs, and Agency Pass-Through Mortgage-Backed Securities traded TBA for good delivery generally must be reported within 15 minutes of execution of the transaction; (2) Agency Pass-Through Mortgage-Backed Securities traded TBA not for good delivery, SBA-Backed ABSs traded TBA or in Specified Pool Transactions, and CMOs executed on or after issuance generally must be reported within 60 minutes of the time of execution of the transaction;42 and (3) other SPs generally must be reported by the end of the day of execution.
+ +TRACE reporting timeframes differ for primary market transactions, specifically, for transactions that meet the definition of “List or Fixed Offering Price Transaction” or “Takedown Transaction.”43 The TRACE Rules provide that transactions that meet either of these two definitions be reported by no later than the next business day during TRACE system hours. TRACE trade reporting obligations, however, generally do not include any primary market transaction that is a sale from an issuer to an underwriter or initial purchaser as part of an offering.44
+b. Information Reported to TRACE
+Each FINRA member that is a party to a reportable transaction in a TRACE-Eligible Security generally is required to report the transaction to TRACE, and FINRA Rule 6730(c) (Transaction Information To Be Reported) sets forth the items of information required to be reported to TRACE in connection with the execution of a transaction in a TRACE-Eligible Security. Importantly, the TRACE reporting requirements apply only to transactions; any activity prior to execution is not required to be reported. Each TRACE trade report generally must include the following information:
+• CUSIP number, similar numeric identifier, or FINRA symbol;
+• Size (volume) of the transaction;
+• Price of the transaction (or the elements necessary to calculate price, which are contract amount and accrued interest);
+• Buy or Sell;
+• Date of Trade Execution (“as/of” trades only);
+• Contra-party’s identifier (MPID, customer, or a non-member affiliate, as applicable);
+• Principal or Agent;
+• Time of Execution;
+• Reporting side executing broker as “give-up” (if any);
+• Contra side Introducing Broker in case of “give-up” trade;
+• Commission (total dollar amount), if applicable;
+• Date of settlement;
+• If the member is reporting a transaction that occurred on an alternative trading system (“ATS”) pursuant to Rule 6732, the ATS’s separate MPID obtained in compliance with Rule 6720(c); and
+• Modifiers, as applicable.
+c. Transactions Excepted or Exempt from TRACE
+The TRACE Rules except or exempt certain transactions and transfers of securities from trade reporting. FINRA Rule 6730(e) (Reporting Requirements for Certain Transactions and Transfers of Securities) generally provides that the following types of transactions not be reported:
+• Transfers of TRACE-Eligible Securities for the sole purpose of creating or redeeming an instrument that evidences ownership of or otherwise tracks the underlying securities transferred (e.g., an exchange-traded fund);
+• Transactions resulting from the exercise or settlement of an option or a similar instrument, or the termination or settlement of a credit default swap, other type of swap, or a similar instrument;
+• Certain transfers of securities made pursuant to an asset purchase agreement in connection with a bankruptcy (subject to conditions);
+• Transactions where the buyer and the seller have agreed to trade at a price substantially unrelated to the current market for the TRACE-Eligible Security (e.g., to allow the seller to make a gift); and
+• Transactions in TRACE-Eligible Securities that are listed on a national securities exchange, when such transactions are executed on and reported to the exchange and the transaction information is disseminated publicly, and certain transactions in TRACE-Eligible Securities that are executed on a facility of NYSE and reported to NYSE and disseminated publicly by NYSE (subject to conditions).
+In addition to the exceptions provided in FINRA Rule 6730(e), exemptions from TRACE reporting may, on a case-by-case basis, be granted to an ATS under FINRA Rule 6731 (Exemption from Trade Reporting Obligation for Certain Alternative Trading Systems) or FINRA Rule 6732 (Exemption from Trade Reporting Obligation for Certain Transactions on an Alternative Trading System). Where an ATS receives an exemption under FINRA Rule 6731 or 6732, it is not required to report some or all transactions to TRACE, as provided for in each rule. However, FINRA continues to receive transaction information on exempt ATS transactions from the other parties to the transaction on the ATS (who report their role in the trades to TRACE), as well as directly from the ATS outside of the TRACE system.
+pubdate: May 15, 2017 effdate: N/A
+ 2. MSRB Reporting Requirements for Municipal Securities
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Debt Securities, Current Audit Trail Requirements for Debt Securities, MSRB Reporting Requirements for Municipal Securities
+ Compliance User: Equity Securities
+ Keywords:
+ TRACE,
+ Securities Reportable to RTRS,
+ MSRB Rule G-14,
+ RTRS,
+ Reporting Timeframe,
+ Information Reported to RTRS,
+ Transactions Excepted from TRACE,
+
+ As noted above, the MSRB is not a Participant, and the following discussion therefore describes the Participants’ understanding of MSRB requirements and MSRB transparency systems.
+a. Securities Reportable to RTRS
+MSRB Rule G-14 requires a broker, dealer or municipal securities dealer to report information about each transaction effected in a municipal security45 to the MSRB’s Real-time Transaction Reporting System (“RTRS”). The MSRB collects the information to provide reported prices for transparency purposes and to compile an audit trail for regulatory purposes.
+Municipal securities required to be reported to RTRS include four municipal security sub-types – fixed rate and zero coupon securities, commercial paper, variable rate demand obligations, and auction rate securities. MSRB rules generally require that these securities be reported to RTRS as follows:
+ +MSRB also provides for specific reporting timeframes for particular transaction types.
+ +b. Information Reported to RTRS
+RTRS collects transaction information for customer and inter-dealer transactions effected in municipal securities. Inter-Dealer Regulatory-Only (IDRO) transactions, which involve instances when an introducing broker effects a trade for a customer against the principal position of its clearing broker, are also reportable to RTRS. For inter-dealer transactions, firms must compare and match their trades through National Securities Clearing Corporation’s (“NSCC”) Real-Time Trade Matching (“RTTM”) system. RTTM allows firms to satisfy their transaction reporting obligations in addition to matching their inter-dealer transactions. Firms are able to submit their municipal securities transactions for both trade matching and regulatory reporting in a single trade message to RTTM. In an IDRO transaction, the transaction between the clearing and introducing broker is not required to be submitted for comparison purposes in RTTM, because it does not result in a movement of a principal position between dealers.46
+Matched data for inter-dealer transactions includes the following:47
+ +Inter-dealer trade data used solely for regulatory purposes includes the following:48
+• Destination
+• Executing Broker Commission
+• External Reference
+• Originator of message
+• Regulatory Dollar Price
+• Reversal Control Number
+• Special Condition Indicator
+• Trade Time
+• Trading Capacity – Contra-party
+• Trading Capacity – Participant
+• Type of Price – Weighted Price
+• All fields on Customer and IDRO trades are used for regulatory purposes only If the trade is subject to the following special conditions,49 firms report the appropriate indicator code:
+• Flat Trades – A security that is traded on terms that do not include accrued interest.
+• Away From Market Trades – A security that is traded at a price that differs substantially from the market price or involved in one of the following specific scenarios:
+‧ Customer Repurchase Agreement Transactions
+‧ UIT-Related Transactions
+‧ TOB-Related Transactions
+• Alternative Trading System Transactions – Inter-trade that was executed with or using the services of an alternative trading system with Form ATS on file with the SEC.
+• Customer Trades Involving Non-Transaction-Based-Compensation (NTBC) Arrangements – A customer trade that did not include a mark-up, markdown or commission.
+Transaction Fields by Trade Type:50
+ +c. Transactions Excepted from RTRS
+Firms are not required to the report the following transactions under MSRB Rule G-14:
+• Transactions in securities without assigned CUSIP numbers;
+• Transactions in municipal fund securities (e.g., 529 College Savings Plans);
+• Inter-dealer transactions for principal movement of securities between dealers that are not inter-dealer transactions eligible for comparison in a clearing agency registered with the Commission;51 and
+• Sales from issuers to broker-dealers as part of new issues of municipal securities.52
+pubdate: May 15, 2017 effdate: N/A
+ 3. NYSE Bonds
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Debt Securities, Current Audit Trail Requirements for Debt Securities, Order Information for Debt Securities, NYSE Bonds
+ Compliance User: Equity Securities
+ Keywords:
+ NYSE Bonds,
+ Order Information,
+ Trade Reports,
+
+ NYSE Bonds is an electronic order-driven matching system through which Exchange members enter and match orders for eligible debt securities on a price and time priority basis. The system provides access to the order book, which displays orders in the time sequence received. Upon execution, trades are submitted for clearing to the Depository Trust Clearing Corporation.
+a. Order Information
+NYSE members authorized to access NYSE Bonds may enter buy and sell orders in eligible bonds to the NYSE Bonds system. All orders, modifications and cancellations of such orders, by NYSE members entered on the NYSE Bonds system throughout each trading day, are retained by the Exchange.
+Each order generally must include the following information:
+• Entering member’s MPID;
+• CUSIP number or identifier;
+• Order type,53 and any modifiers;
+• Buy or Sell;
+• Price and Quantity; and
+• Capacity (Agent or Principal).
+NYSE Bonds centralizes bond trading and publishes a real-time bond data feed to members authorized to use NYSE Bonds and to subscribers that reflects all orders in time sequence on the NYSE Bonds order book.
+b. Trade Reports
+The trade reports of executions on the NYSE Bonds system include the following information:
+• CUSIP number or identifier;
+• Price and Quantity of each filled execution;
+• Average Price of fills for each order;
+• Total Quantity of fills on open orders;
+• Buy or Sell;
+• Time of Execution;
+• Settlement Type (whether same day, T+1, T+2 or T+3);
+• Type of Trade Execution (“Partially Filled”, “Filled”);
+• Type of Instrument (“Corporate Bond”, “Treasury Bill”); and
+• Contra-party’s MPID identifier, and number of Contra-parties on a fill.
+In addition, the Exchange retains a record and disseminates trade data and execution reports of trades that were cancelled. Such reports identify trades that were cancelled after the execution was reported and includes identifiers to map any cancelled trade with the original trade.
+pubdate: May 15, 2017 effdate: N/A
+ 4. Order Information for Debt Securities
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Debt Securities, Current Audit Trail Requirements for Debt Securities, Order Information for Debt Securities
+ Compliance User: Equity Securities
+ Keywords:
+ FINRA Rules,
+ MSRB Rules,
+ SEA Rule 17a-3,
+
+ As discussed above, FINRA and MSRB rules generally require firms to report transaction information in covered securities within specified periods following the execution of reportable transactions and do not require members to report any order or other pre-trade information.
+SEA Rule 17a-3(a)(6)54 prescribes recordkeeping requirements for broker-dealers, including recordkeeping requirements for orders in debt securities. Specifically, SEA Rule 17a-3(a)(6), among other things, requires broker-dealers to make and keep a memorandum of each brokerage order, and of any other instruction, given or received for the purchase or sale of securities, whether executed or unexecuted. The order memorandum must show: (i) the terms and conditions of the order or instructions and of any modification or cancellation thereof; (ii) the account for which entered; (iii) the time the order was received; (iv) the time of entry; (v) the price at which executed; (vi) the identity of each associated person, if any, responsible for the account; (vii) the identity of any other person who entered or accepted the order on behalf of the customer or, if a customer entered the order on an electronic system, a notation of that entry; and (viii) to the extent feasible, the time of execution or cancellation.55
+Firms also may use various systems to internally manage their order workflow in debt securities. These systems may capture order information such as security information (e.g., CUSIP, side, quantity, coupon and maturity), order details (e.g., date and time of order receipt, the order’s time in force, and any limit price), and may include additional information (e.g., settlement date, whether the order was solicited, the name of the representative who took the order, and account information). Based on discussions with multiple firms, firms’ order workflow management practices differ widely, and the systems firms use may provide varying degrees of linkages with other relevant information, such as executions or order updates/cancellations.
pubdate: N/A effdate: N/A
- 2.5. Cancellation Scenarios
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Cancellation Scenarios
- Compliance User: Industry Member
- Keywords:
- pubdate: N/A effdate: N/A
- 2.5.1. Order Canceled
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Cancellation Scenarios, Order Canceled
- Compliance User: Industry Member
- Keywords:
- This scenario illustrates the reporting requirements to CAT for an Industry Member when a customer order is canceled on the same day as the order was created.
-For this scenario, Industry Member Broker 1 is required to report the following events:
-• New Order event for the customer order
-• Order Canceled event upon receipt of notice by the customer
-
- Note that for illustration purposes, actions taken by the Broker between the receipt of the original order and the customer cancellation are not included.
-
-
- pubdate: N/A effdate: N/A
- 2.5.2. Partial Cancellation of an Order
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Cancellation Scenarios, Partial Cancellation of an Order
- Compliance User: Industry Member
- Keywords:
- The following scenario illustrates the reporting requirements to CAT if the customer partially cancels an order placed with an Industry Member.
-In this scenario, Industry Member Broker 1 must report:
-• The receipt of the customer order as a New Order event
-• Either a Order Canceled event or an Order Modified event for the partial cancellation
-
-
-
- pubdate: N/A effdate: N/A
- 2.5.3. Cancellation of a Routed Order
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Cancellation Scenarios, Cancellation of a Routed Order
- Compliance User: Industry Member
- Keywords:
- Order Canceled Event,
-
- This scenario illustrates the CAT reporting requirements for an Industry Member when an order that was previously routed to another Industry Member is canceled.
-
- Industry Member Broker 1 must report:
-• The receipt of the customer's order as a New Order event
-• The initial route of the order to Broker 2 (an Order Route event)
-• The cancellation of the order (an Order Canceled event)
-Industry Member Broker 2 must report:
-• The receipt of the route from Broker 1 as an Order Accepted event
-• The cancellation of the order as an Order Canceled event
-
-
-
+ pubdate: May 15, 2017 effdate: N/A
+ C. Debt Security Consolidated Audit Trail – Possible Approaches
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Debt Securities, Debt Security Consolidated Audit Trail - Possible Approach
+ Compliance User: Equity Securities
+ Keywords:
+ CAR Reporting,
+ Participants,
+ CUSIP,
+
+ As noted above, unlike for equity securities, there is no current regulatory requirement for broker-dealers to report order information for orders involving debt securities. Consequently, there is no current order reporting framework on which to base potential CAT reporting. Set forth below are three general frameworks that could be used in considering how the CAT might be expanded to include debt securities, though the Participants do not currently recommend that the CAT be expanded to debt securities. The Participants believe that the CAT should first be fully implemented for equities and listed options, and that the Participants should then have the benefit of having gained experience with CAT operation in the equity space prior to analyzing the potential expansion to debt securities. In addition, the Participants believe that industry outreach and input would be necessary to inform any analysis of the potential expansion of the CAT to debt securities.
+The possible approaches discussed below by no means are exclusive representations of all frameworks that may warrant discussion. In addition, because current practices related to order taking, sourcing, and agreeing to trades are markedly different for debt securities than for equity securities, the Participants believe that the development of any concept or proposal for CAT expansion (or establishing an order audit trail regime more generally) to debt securities should be carefully considered, including to identify how regulatory objectives may be best met taking these unique characteristics into consideration.
+The three approaches to a possible audit trail framework for debt securities discussed below are presented in order of the simplest and least-granular—from requiring order-originating firms to report new orders and cancellations/executions (Approach #1), to the most complex and granular, which mirrors more closely the extensive order life cycle-reporting regime for equities and options being implemented for the CAT (Approach #3). The approaches attempt to account for unique order handling processes and features in the market for, or nature of, debt securities. For example, in the market for debt securities, customers may contact their representatives providing only general characteristics regarding the type of debt security they wish to invest in, rather than a particular CUSIP. In these cases, based on the investor’s criteria, a representative may present to the customer several similar debt securities for consideration prior to the customer deciding on, and placing an order for, a particular security. In addition to oral interactions with customers, orders or indications of interest between dealers also may be communicated manually (e.g., a telephone call or message to a broker’s broker).
+Some debt securities may not be widely quoted and may trade infrequently and, as a result, information on the security’s availability and pricing may be limited or unavailable. Firms have stated that representatives, therefore, often must take the additional step of confirming the final details of a potential transaction with the customer prior to executing the order and, for this reason, in these cases the time of order receipt and time of order execution are essentially simultaneous (because the customer officially places the order only once the specifics of the potential transaction are known). Similarly, quotations on electronic platforms (including ATSs) that trade debt securities may not be firm (e.g., RFQs and IOIs). In such cases, the systems do not automatically execute transactions and, instead, require manual confirmation from subscribers. Special consideration would need to be given to the use of non-firm quotation types in debt securities (e.g., RFQs and IOIs) on electronic systems and how this might impact an order audit trail for debt securities.
+Thus, the concept of order receipt, order routing, and assessing the market for some debt securities can be very different than for equities or for listed options. Further, firms have represented that, due to the manual nature of order taking in the debt market, creating a new order record electronically and systematically tracking orders through to execution may be a significant departure from current practice for many firms. In addition, industry participants have represented that the lack of full detail on and experience in reporting to the CAT makes it impossible to evaluate or estimate the direct and indirect costs of CAT expansion to debt securities at this time. As such, the Participants do not believe that applying the current CAT framework to debt securities, without significant modification, would be workable. For these reasons and others, as discussed in Section I.D. below,56 the Participants do not recommend expanding the CAT to include debt securities at this time.
+pubdate: May 15, 2017 effdate: N/A
+ 1. Originating Firm New Order Report; Execution Reports (Approach #1)
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Debt Securities, Debt Security Consolidated Audit Trail - Possible Approach, Originating Firm New Order Report; Execution Reports (Approach #1)
+ Compliance User: Equity Securities
+ Keywords:
+ CAT Framework,
+ Participant,
+ CUSIP,
+ TRACE,
+ Report Type,
+ Report Fields,
+
+ Under Approach #1, originating firms would report the receipt of a new order from a customer (i.e., when an order for a CUSIP/specific security is received), including a customer identifier that would be linkable to a separate database containing the relevant personally identifiable information (“PII”), similar to the CAT framework.57 If a transaction is fully or partially executed, the originating firm would enter an execution report that is linked to its new order report in the audit trail. Likewise, if the order was cancelled in whole or in part, the cancellation would be included in the audit trail, and would be linked to the originating firm’s new order report. The execution report also would include an identifier that would link it to the related TRACE transaction report. The Participants do not assume any changes to current transaction reporting frameworks. Where no customer order is involved, no audit trail requirement would be required as data would be available from the transaction report.
+
+ Approach #1 - Example
+The below relates to the sell order scenario depicted above. Relevant order audit trail reports under this approach are underlined. Note that the events used in the example are illustrative and that alternatives, such as indications of interest, requests for quotes, non-firm quotes and negotiated trades, may also be used as examples.
+• 12:10pm – Firm A creates New Order ID #1234 – New Order Report
+ +• 2:08pm – Order Execution: Firm A executes Order ID #1234 with Firm B – Execution Report by Firm A (linked); Firm B would have no reporting obligation
+ +• If all or part of the order was cancelled, Firm A would submit a Cancel Report. The Cancel and New Order Reports would be linked
+ +pubdate: May 15, 2017 effdate: N/A
+ 2. Originating and Route Recipient Firm New Order Reports; Partially Linked; Execution Reports (Approach #2)
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Debt Securities, Debt Security Consolidated Audit Trail - Possible Approach, Originating and Route Recipient Firm New Order Reports; Partially Linked; Execution Reports (Approach #2)
+ Compliance User: Equity Securities
+ Keywords:
+ Participant,
+ CUSIP,
+ Report Type,
+ Report Fields,
+
+ Under Approach #2, originating firms would report the receipt of a new order from a customer (i.e., when an order for a CUSIP/specific security is received), including a customer identifier that would be linkable to a separate database containing the relevant PII. Where the originating firm sends an order to another firm or solicits interest from or through another firm regarding an order, the sending firm would document this activity by submitting a route report. While this approach describes this activity as a “route,” the Participants acknowledge that, because of the differences in the debt markets, typically, the order itself is not truly being routed in the same sense as occurs in the equity markets; rather, the firm is contacting a dealer or market center for indications of interest in the particular bond.
+Under this approach, the receiving firm would be required to create a new order report only if it further sends the order to another firm (e.g., report a new order and link it to the route report). If a receiving firm executes the order, or if the order is cancelled before any further action is taken by the receiving firm, a new order report would not be required of the receiving firm. Full or partial execution reports would be required of any firm with a related new order. The execution report also would include an identifier that would link it to the related transaction report. Likewise, if the order was cancelled in whole or in part, any firm with a new order report related to the cancellation also would report the cancellation.
+Approach #2 - Example
+The below relates to the same sell order scenario depicted above for Approach #1. Relevant order audit trail reports under this approach are underlined. Note that the events used in the example are illustrative and that alternatives, such as indications of interest, requests for quotes, non-firm quotes and negotiated trades, may also be used as examples.
+• 12:10pm – Firm A creates New Order ID #1234, a reportable event by Firm A – New Order Report
+• At 12:15pm, 12:16pm and 12:17pm, respectively, Firm A sends Sub-Orders #12341, #12342 and #12343 to Firm B, ATS #1 and ATS #2, respectively. Reportable events by Firm A – Route Reports
+ +• Firm B, ATS #1, and ATS #2 are required to record items of new order information only if they ultimately route the order
+• 2:08pm - Order Execution: Firm A executes Order ID #1234 / #12341 with Firm B – Execution Report by Firm A
+• Firm A cancels Sub-Orders #12342 and #12343 – Cancel Report
+pubdate: May 15, 2017 effdate: N/A
+ 3. Complete, Linked, Order through Execution Life Cycle (Approach #3)
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Debt Securities, Debt Security Consolidated Audit Trail - Possible Approach, Complete, Linked, Order through Execution Life Cycle (Approach #3)
+ Compliance User: Equity Securities
+ Keywords:
+ Participant,
+ CAT,
+
+ In the course of considering how the CAT might be expanded to include debt securities, the Participants also have considered whether the submission of a new order report is the earliest life cycle event that might be captured for debt securities. As noted above, one of the unique features of the debt market is the often simultaneous timing of an order and its execution (where the customer does not place an order until all the specifics of the potential transaction are known). Prior to the entry of an order for a particular security, however, customers may provide firms with desired criteria for a debt security and the firm then works on identifying, locating, and presenting specific options for the customer’s consideration.
+The Participants understand that this process is common in the debt area and, therefore, initially considered whether an audit trail might begin with recording and reporting certain pre-order information obtained by the firm in advance of the entry of an order for a particular security. For example, an approach might be considered where, if a customer provides a minimum number of descriptive elements regarding a debt security — e.g., where a customer provides several of the following: investment dollar amount; issuer; sector; yield; coupon; maturity; rating; or specified additional features — a firm conceivably might be required to submit a pre-order report. Any securities presented by the firm to the customer as satisfying the customer’s criteria also could be entered into a pre-order report and, should an order result, the pre-order report could be linked to the new order report (which would be followed by route, execution or cancellation reports, as applicable). This type of framework would be an attempt to capture in an automated fashion the pre-order events that are likely to be extensive in the debt markets. However, the Participants haven’t included the concept of a pre-order report in Approach #3 due to the possibly numerous manual steps likely necessary to submit and amend such a report to account for each debt security being explored.
+Under Approach #3, firms (both originating firms and route recipients) would report the receipt of a new order, though only originating firms would be required to report a customer identifier that would be linkable to a separate database containing the relevant PII. As noted above, although typically the order itself is not being truly routed to multiple firms (the originating firm is contacting a dealer or market center for indications of interest in the particular bond), this approach would require new order reports from all receiving firms and any associated executions or cancellations. Where a firm sends an order to another firm, a route report would be added to the audit trail by the sender (linked to the related new order report). If an order is fully or partially executed, any firm with a new order report related to the execution would enter an execution report that is linked to its new order report in the audit trail. The execution report also would include an identifier that would link it to the related transaction report. Likewise, if the order was cancelled in whole or in part, any firm with a new order report related to the cancellation also would report the cancellation.
+Approach #3 - Example
+
+ The below relates to the sell order scenario depicted above. Relevant audit trail reports under this approach are underlined. Note that the events used in the example are illustrative and that alternatives, such as indications of interest, requests for quotes, non-firm quotes and negotiated trades, may also be used as examples.
+• 12:10pm – Firm A creates a new order and assigns Internal Order ID #1234, a reportable event by Firm A – New Order Report
+• 12:15pm, 12:16pm and 12:17pm, Firm A sends Sub-Orders #12341, #12342 and #12343 to Firm B, ATS #1 and ATS #2, respectively. Reportable events by Firm A – Route Reports
+• 12:15pm - Firm B creates Internal Order ID # (linked to Firm A’s Route Report), a reportable event by Firm B – New Order Report
+• 12:16pm - ATS #1 creates Internal Order ID # (linked to Firm A’s Route Report), a reportable event by ATS #1 – New Order Report
+• 12:17pm - ATS #2 creates Internal Order ID # (linked to Firm A’s Route Report), a reportable event by ATS #2 – New Order Report
+• 2:08pm - Order Execution: Firm A executes Internal Order ID #1234 / #12341 with Firm B. Required reports are as follows:
+• Firm A reports execution and links it to Order ID #1234 / #12341 – Execution Report
+• Firm B reports execution and links it to Internal Order ID # (linked to SubOrder #12341) – Execution Report
+• Related Order/Sub-Order cancellations required:
+• Firm A cancels Sub-Orders #12342 and #12343 – Cancel Report
+• ATS #1 cancels Internal Order ID # (linked to Firm A’s Route Report) (Reason Code – cancelled by Firm A) – Cancel Report
+• ATS #2 cancels Internal Order ID # (linked to Firm A’s Route Report) (Reason Code – cancelled by Firm A) – Cancel Report
+pubdate: May 15, 2017 effdate: N/A
+ 4. Other Considerations
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Debt Securities, Debt Security Consolidated Audit Trail - Possible Approach, Other Considerations
+ Compliance User: Equity Securities
+ Keywords:
+ Participant,
+ CAT,
+ Debt Securities,
+ SEC,
+ MSRB,
+ FINRA,
+ NMS Securities,
+ TRACE Reporting,
+ TRACE-Eligible Securities,
+
+ The Participants believe that a discussion of possible ways that order audit trail information for debt securities might be captured for regulatory purposes should include consideration of an option other than expanding the CAT to capture debt securities. One important factor is that there are fewer regulatory entities that would be primary users of order data for debt securities (SEC, MSRB and FINRA) than the universe of regulators for NMS securities, which also would include all national securities exchanges. Thus, the Participants believe that methods other than integrating order audit trail information on debt securities into the CAT should be considered, both from a short-term and long-term solution perspective. For example, the SEC could ask FINRA to: consider ways to enhance its TRACE reporting requirements to include more granular customer information on TRACE-Eligible Securities, such as a large trader identifier or customer categories; and establish a separate reporting mechanism for reporting order-related information that can be linked to TRACE trade reports.
pubdate: N/A effdate: N/A
- 2.6. Additional Reporting Scenarios
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios
- Compliance User: Industry Member
+ pubdate: May 15, 2017 effdate: N/A
+ D. Economic Impact Analysis
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Debt Securities, Economic Impact Analysis
+ Compliance User: Equity Securities
Keywords:
- Order Accepted Event,
+ TRACE,
+ Debt Securities,
+ SIFMA Reports,
+ FINRA,
+ BIS Report,
+ CAT Reporting,
+ Participants,
- pubdate: N/A effdate: N/A
- 2.6.1. Industry Member Utilizes Multiple Systems at One Desk
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Industry Member Utilizes Multiple Systems at One Desk
- Compliance User: Industry Member
- Keywords:
- In the following scenario, the Industry Member has multiple trading systems utilized at a single desk. For CAT reporting, the Industry Member is not required to report information regarding an order's movement between two systems within the same desk or department as an internal route.
-In this scenario, the desk which received the customer's order transfers the order into another internal application in order to route the order to an exchange. Since the desk handling the order does not change, the Industry Member Broker 1 is required to report:
-• New Order event for the receipt of the customer order
-• Order Route event for route to the exchange
-
-
-
- pubdate: N/A effdate: N/A
- 2.6.2. Industry Member Creates Child Orders and Routes
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Industry Member Creates Child Orders and Routes
- Compliance User: Industry Member
- Keywords:
- This scenario illustrates the reporting requirements should an Industry Member chose to slice an order into multiple child orders before further handling.
-For this scenario, Industry Member Broker 1 is required to report:
-• Receipt of the customer order as New Order Event
-• A Child Order event for each slice of the order created
-• An Order Route event for each child order
-Receipt Industry Members Broker 2 and 3 are required to report:
-• Order Accepted events for receipts of the order from Broker 1 (and any subsequent order handling)
-
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.6.3. Industry Member Creates Multiple Branches of Child Orders
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Industry Member Creates Multiple Branches of Child Orders
- Compliance User: Industry Member
- Keywords:
- Order Internal Route event,
- Participant Order Accepted,
- Order Route,
- Child Order,
-
- This scenario illustrates the reporting requirements for an Industry Member where each internal desk has chosen to work an order by splitting the original order into smaller components. The Industry Member has the flexibility to report different events for each desk, should it better reflect the firm's internal systems.
-
- For this scenario, Industry Member Broker 1 must report:
-• The receipt of the customer order at the Sales Desk as a New Order event
-• A Child Order event for each slice created at the Sales Desk prior to routing to another desk
-• An Order Internal Route event for each child order
-• For the Child Order sent to the Arbitrage Desk, a Child Order event for each new slice created
-• An Order Route event for each Child Order routed from the Arbitrage Desk
-• For the Child Order sent to the Trading Desk, an Order Internal Route event for each slice of the order (and any subsequent events not shown)
-
-
-
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.6.4. Order Received and Routed Manually, Electronically Captured at Subsequent Desk
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Order Received and Routed Manually, Electronically Captured at Subsequent Desk
- Compliance User: Industry Member
- Keywords:
- This scenario illustrates the reporting requirements for an Industry Member when an order is received and then manually internally routed to another department where it is immediately entered into an electronic order management system upon receipt (e.g. the branch receives an order and calls the Trading Desk).
-
- For this scenario, Industry Member Broker 1 must report:
-• The receipt of the order from the customer (a New Order event with manualFlag = true)
-• An Order Internal Route event for route of the order to the trading desk which will enter the trade into the Industry Member's electronic system
-• The route of the order to the exchange (Order Route event)
-
-
- pubdate: N/A effdate: N/A
- 2.6.5. Order Routed and Executed via a Clearing Firm
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Order Routed and Executed via a Clearing Firm
- Compliance User: Industry Member
- Keywords:
- This example illustrates the reporting requirements when an introducing firm enters the customer order into the clearing firm's system. The clearing firm then executes the order from a proprietary account. Both the introducing firm and clearing firm are Industry Members.
-
- For this scenario, the introducing firm (Broker 1) must report:
-• The receipt of the order from the customer in a New Order event
-• The route of the order to the clearing firm in an Order Route event
-The clearing firm would report the following:
-• The receipt of the order by the clearing firm in an Order Accepted event
-• The execution of the order in a Trade event
-Only the executing entity is required to report executions to CAT. In this scenario only the clearing firm is responsible to report a Trade event.
-
-
- pubdate: N/A effdate: N/A
- 2.6.6. Direct Order Routing via a Clearing Firm's System
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Direct Order Routing via a Clearing Firm's System
- Compliance User: Industry Member
- Keywords:
- This scenario illustrates the reporting requirement when an introducing firm receives a customer order and, using its clearing firm's system, directs the order to an exchange for execution. The clearing firm does not participate in any order routing or handling instructions but only provides the technology to the introducing firm to route the order.
-The introducing firm, Industry Member Broker 1, must report the following to CAT:
-• The receipt of the order from the customer in a New Order event
-• The route of the order to the Exchange 1 in an Order Route event
-The clearing firm does not have CAT reporting obligations.
-The exchange follows Participant reporting requirements for subsequent handling.
-
-
-
- pubdate: N/A effdate: N/A
- 2.6.7. Order Routing via an Algorithm Provided by the Clearing Firm
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Order Routing via an Algorithm Provided by the Clearing Firm
- Compliance User: Industry Member
- Keywords:
- This scenario illustrates the reporting requirements to CAT when an introducing firm receives a customer order and enters it into its clearing firm's system. The clearing firm's system automatically determines the routing destination based on pre-defined criteria developed by the clearing firm. The clearing firm makes the determination as to where the order is routed. The introducing firm does not direct the order. Both the introducing firm and the clearing firm are Industry Members. In this case, the following CAT events must be reported:
-The introducing firm, Broker 1, must report:
-• The receipt of the customer order in a New Order event
-• The route of the order to the clearing firm in an Order Route event
-The clearing firm must report:
-• The receipt fo the order from the introducing firm in an Order Accepted event
-• The route of the order to the routing destination as an Order Route event
-The routing destination (exchange) must report:
-• The receipt of order routed from the clearing firm
-• The subsequent order handling actives that are CAT reportable
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.6.8. Order Routing via Smart Router Provided by another Industry Member
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Order Routing via Smart Router Provided by another Industry Member
- Compliance User: Industry Member
- Keywords:
- Destination Market Center,
- SEC Rule 11Ac1-6,
- SEC Rule 606,
- Handling Instructions,
- Trade Event,
-
- In this scenario, the introducing firm receives a customer order and enters it directly to a Smart Router provided by another Industry Member to route the order. The Smart Router provided by another industry member does not need to separately report to CAT when all the following conditions apply:
-1. The Industry Member providing the order routing system has no discretion over the order once it is entered into the Industry Member's order-routing system. The order routing destination ("Destination Market Center") must either be directed by the originating Industry Member or be subject to the pre-determined algorithm of the routing system agreed to by the originating Industry Member. The Industry Member providing the order routing system would have no involvement relating to the routing of the order, other than providing the routing mechanism.
-2. The originating Industry Member must have established a relationship with the Destination Market Center, including meeting any and all applicable requirements to route orders to that destination. The originating Industry Member understands that the Industry Member providing the order routing system has no involvement with respect to the order in any way, except for providing a routing mechanism. No pre-established relationship between the Industry Member providing the order routing system and the Destination Market Center would be necessary for the originating Industry Member to access the routing destination.
-3. The Destination Market Center views the order as coming directly from the originating Industry Member, not the Industry Member providing the order routing system, for all purposes, but not limited to, CAT reporting, trade reporting, applicable fees, etc.
-4. The originating Industry Member, rather than the member providing the order routing system, identifies itself as the routing firm for purposes for the SEC Rule 606 (formerly SEC Rule 11Ac1-6).
-
- The introducing firm, Industry Member Broker 1, is required to report:
-• The receipt of the customer order in a New Order event
-• The route of the order through a smart router (Order Route event with handlingInstructions = SMT)
-The destination, Industry Member Broker 2, is required to report:
-• The receipt of the order from Broker 1 as an Order Accepted event
-• Execution of the order (Trade event)
-The Industry Member providing the order routing system is not required to report to CAT.
-
-
-
- pubdate: N/A effdate: N/A
- 2.6.9. GTC Order Routed to Exchange, Modified by Customer
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, GTC Order Routed to Exchange, Modified by Customer
- Compliance User: Industry Member
- Keywords:
- Industry Member Broker 1,
-
- The following scenario illustrates the reporting requirements for handling order types that can live across days (e.g. GTC, GTD). Industry Member Broker 1 receives a "GTC" order from a customer. From Broker 1's perspective, the order is reported as GTC as maintained on their book. When Broker 1 routes the order to the exchange for execution, the order is a "DAY" order from the exchange's perspective and should be reported as timeInForce = DAY on the Order Route event as well as relevant Participant events. The Industry Member must submit an Order Route event every day the order is sent to the exchange until the order is executed or canceled.
-On T+1, the customer modifies the GTC order. Broker 1 must report an Order Modified event with the original order date and an Order Route event for the modification on the exchange.
-
- For this scenario, Industry Member Broker 1 is responsible for reporting:
-• The receipt of the customer GTC order on T (New Order event)
-• An Order Route event for the route to the exchange (as a "DAY" order)
-• Another Order Route event for the route to exchange on T+1 (start of day) as the order was not executed or canceled on T
-• The modification of the customer order on T+1 (during market hours) in an Order Modified
-• The route of the modified order to the exchange on T+1 (Order Route event)
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.6.10. Dividend Reinvestment
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Dividend Reinvestment
- Compliance User: Industry Member
- Keywords:
- dividend reinvestment investment program (DRIP),
- Post Trade Allocation events,
- New Order event,
- Order Route Event,
- handlingInstructions = DIV,
-
- The following scenario illustrates the reporting requirements for an Industry Member whose customers participate in a dividend reinvestment program. Industry Member Broker 1 aggregates dividend reinvestment investment program (DRIP) orders for participating customers, rounds up to the the next whole share, and creates a new order to purchase shares that need to allocate to customers. This order is routed to the street, executed, and allocated to the participating customers. The remaining fractional share is allocated to the proprietary account of Broker 1. It is not required for Broker 1 to report Post Trade Allocation events for allocations to sub-accounts for dividend repurchase orders until Phase 2c.
-
- For this scenario, Industry Member Broker 1 is responsible for reporting:
-• A New Order event for a single order to acquire shares for all customers participating in the dividend reinvestment program
-• An Order Route event for routing the principal purchase to Broker 2
-Industry Member Broker 2 is responsible for reporting:
-• An Order Accepted event to confirm receipt of the order from Broker 1
-• A Trade event confirming execution of the order
-Once the fractional inventory reaches a whole share threshold, Broker 1 would follow standard procedures for sales from proprietary accounts if actions were taken to flatten fractional share inventory.
-
- Industry Member Broker 1 is responsible for reporting:
-• A New Order event for the whole share order
-• An Order Route event for routing the sale order to Broker 3
-Industry Member Broker 3 is responsible for reporting:
-• An Order Accepted event for the receipt of the order from Broker 1
-• A Trade event for the execution of the order
-
-
-
-
-
- pubdate: N/A effdate: N/A
- 2.6.11. Routing of the Equity Leg of a Complex Option to another Industry Member
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Routing of the Equity Leg of a Complex Option to another Industry Member
- Compliance User: Industry Member
- Keywords:
- New Order event,
- Order route events,
- equity leg order (Sell),
- equity leg order (Buy),
-
- This scenario illustrates the reporting requirements when an Industry Member splits the equity leg of complex options from customers. Upon determining the price at which the equity legs must be executed, the Industry Member routes the equity legs to another Industry Member for execution.
-Note that the reporting requirement descriptions and flow chart below only show the equity leg handlings. It does not include the complex option orders or option legs.
-In this scenario, the Industry Member (Broker 1) must report:
-• The receipt of an equity order from the customer (New Order events)
-• The route of the equity order to Broker 2 (Order Route events)
-Industry Member Broker 2 receives the equity leg orders from Broker 1. The orders may come along with an offsetting order to be crossed, or Broker 2 may receive the offsetting order from another Industry Member. Broker 2 then executes as agency cross.
-In this scenario, Broker 2 must report the following events to CAT:
-• The receipt of the equity leg order (Sell) from Broker 1 in an Order Accepted event
-• The receipt of the equity leg order (Buy) from Broker 1 (Or receipt of a Buy order from another Industry Member) in an Order Accepted event
-• The execution of the orders in a Trade Event
-
-
-
-
-
-
- The debt market consists of multiple segmented markets, each with its own clientele and unique trading and reporting practices and processes. Currently, transactions in debt securities in all of the segments except municipal bonds, debt securities issued by a foreign sovereign, and money market instruments are, or soon will be, reportable to TRACE. However, the economic impacts on firms of expanding the CAT to debt securities likely differ in significant ways across these segments due to the differences in the nature and amount of data that is collected in the pre-trade and trade processes in each segment. Such differences in data collection are attributable, to a large extent, to different trading mechanisms (e.g., telephonic communications versus electronic trading systems) and varying levels of automation that are implemented in the trading process (e.g., algorithmic trading).
+Trading in most debt securities traditionally occurred OTC via messaging across broker-dealers and large institutions. However, recent advancements in technology, a changing regulatory environment, and market forces are increasing the role of electronic trading in debt securities.58 First, the emergence of ATSs and other electronic trading platforms has provided trading opportunities that do not exist in traditional voice trading. Second, regulatory reform initiatives enacted after the financial crisis have decreased dealers’ incentives to hold inventories and reduced proprietary trading by broker dealers.59 Also, as the SIFMA Report suggests, there has been an increased emphasis on best execution in the debt markets.60 This emphasis has increased the value of pre-trade transparency that may provide valuable information on prevailing market values, as well as the sources and movements of liquidity. Third, as the FINRA Study shows, changes in the supply and demand for primary and secondary market transactions for corporate debt have manifested in greater transaction volume, but smaller average transaction sizes and increased numbers of counterparties among dealers.61
+The prevalence of electronic trading in some debt markets is relevant to the discussion of a potential order audit trail for debt securities, as electronic trading protocols may already be systematically collecting some of the information that would be requested in the order life-cycle approaches described above. Accordingly, costs associated with CAT reporting may differ for different debt securities based on the level of electronic trading. The SIFMA Report shows that the number of electronic trading platforms has increased from two in 2000, to an estimated 20 in 2016. There are significant differences across platforms with respect to the bond types being traded, the trading protocols employed, and order types. The BIS Report discusses that the use of electronic trading is greater in the most liquid instruments. According to the SIFMA Report, the share of electronic trading of investment grade bonds is estimated to have increased from approximately 8% in 2013 to 20% in 2015 at the time of the study, whereas the shift to electronic trading is relatively slower in municipal bonds.
+The BIS Report also draws attention to regulators’ lack of access to comprehensive data generated by trading protocols across electronic trading platforms and the lack of comparability across trade information collected in different types of bonds, consistent with the assertion in the SIFMA Report that “stakeholders have limited information to gain a robust understanding of the incumbent and new platforms’ functionality and the evolving price discovery and execution protocols.” These differences can include very basic information, such as whether a bond price is represented as a dollar value, as a yield, or as a basis above a reference security. The fact that the degree of electronic trading varies significantly across different types of debt securities is a relevant factor in considering the challenges that likely would be involved in transitioning from reporting only transaction information to CAT reporting.
+The Participants have identified three approaches described in Section I.C. as possible audit trail framework alternatives for debt securities. These approaches differ from each other in terms of the granularity of the data items that would need to be collected, what events in the order life cycle would be captured, the firms that would have reporting obligations, and the linkages that need to be built across the reports.
+As noted in Section I.B, TRACE reporting requirements apply only to transactions, with no pre-trade or route information collected. Each approach described in Section I.C. above progressively introduces additional layers of data collection and reporting in the pre-trade period, and hence is associated with different levels of costs and benefits.
+Approach #1 requires only order originating firms to report and link new orders, cancellations and executions. This approach still requires the creation of a New Order Report that contains information that is not currently reported to regulators. The information that would be contained in an Execution Report is included today in trade reports to the applicable regulator, so the costs of this approach would mostly arise from generating the New Order Report and Cancel Report, and from creating the linkages across reports and to the database that contains the personally identifiable information (PII). Approach #1 would be relatively less costly to implement and provide additional information to regulators than currently is available. For example, if an electronic audit trail were established for debt securities, regulators would have a more efficient means to observe the time of order receipt, the time from receiving the order to execution, and the extent to which others sought to sell the same security at the same time. But this approach provides the regulators with only a limited picture of an order’s life cycle relative to Approaches #2 and #3, discussed below. Specifically, Approach #1 does not capture the route information that provides a detailed view of the dealers that the order has been exposed to before execution or cancellation.
+Approach #2 introduces a Route Report that is linked to the New Order Report, to capture the information on the specific dealers that a bond order travels to before it gets executed or cancelled. As noted in the discussion in Section I.C.1 and 2 above, the Participants acknowledge that orders are not “routed” in the debt market as typically occurs in the equity market. However, for purposes of this discussion, a route occurs when a firm sends an order to another firm or solicits interest from or through another firm regarding an order. New Order and Route Reports could enable regulators to have access to a record of the identity, order and timing of dealers contacted as part of a potential purchase or sale of a specific debt security. As with Approach #1, the obligation accrues only once an order for a specific CUSIP or issue has been received. This approach requires the collection of additional information on the life cycle of orders than described in Approach #1, and therefore would be relatively more costly to capture and report. Nevertheless, the route information could provide useful insight regarding routing practices that might potentially be abusive to customers or inconsistent with best execution obligations.
+Approach #3 requires firms to build a more complete order life-cycle record. This approach resembles the level of granularity required in audit trail reporting for equity securities and potentially provides regulators with the most complete data to conduct markup reviews and surveillance for best execution obligations in debt markets, and enables regulators to compare execution quality across all brokers that orders have been exposed to. Nonetheless, Approach #3 would be the most expensive to implement, as it would require connectivity across firms and collection and reporting of more data. This approach may potentially deter some dealers from accepting orders from other firms because accepting an order from another firm would result in an obligation to create a New Order Report (in addition to Execution and Cancel Reports, as applicable).
+Reporting of primary market transactions may entail further challenges in CAT reporting, as establishing the linkages between New Order and Execution Reports may require more resources for distributions in the primary market, as order receipt and executions are different in nature.
+Since there is no current regulatory requirement for broker-dealers to report order information in debt securities and CAT implementation for equities and options has not yet begun, there currently is no framework to base potential costs regarding the expansion of the CAT to incorporate debt securities. Therefore, the Participants solicited industry feedback regarding the viability of expansion along with the potential direct and indirect costs (challenges) to expansion. The Participants solicited feedback from several market participants as well as industry groups62 to collect information on the potential economic impacts of such potential expansion on the industry, third-party providers and customers.
+The Participants actively sought responses to two sets of questions that were shared with the respondents in advance of the meetings. One set solicited feedback regarding the economic impacts associated with data collection, i.e., the new data fields that would have to be collected for each of the potential reporting scenarios described above. Specifically, the questions sought to address issues such as:
+• Whether existing Order Management Systems (OMS) and Execution Management Systems (EMS) for trading in debt securities are flexible enough to accommodate new asset classes and have the capability to capture order life cycles, i.e., linking new orders, routes, cancellations and executions as described in the options above;
+• The challenges and costs associated with collecting the information required in the reports and creating new data fields contained in such reports (e.g., Route ID);
+• Whether there are limitations to communication / coordination / standardization across trading desks that would hinder the collection of certain items in the reports; and
+• Characteristics of orders (e.g., orders with special handling instructions) or any order types (such as limit versus market orders, IOC, etc.) for which CAT reporting would potentially require more resources.
+The second set of questions was intended to gain a better understanding of the potential impacts associated with reporting information under each of the potential scenarios. The Participants requested feedback on potential issues such as:
+• The nature of the changes that would be necessary to apply CAT reporting obligations to debt securities (e.g., software, hardware, backup, or connectivity);
+• The impact of CAT reporting on order, trade and execution workflows, and competition for provision of intermediation services in debt securities;
+• Whether there would be new functionalities (integration across systems, maintaining and establishing connectivity across brokers, automation of reporting, etc.) and new data management tools (capacity, encryption, transfer, etc.) that would be required to be implemented within the front, middle and back offices;
+• Whether there would be any cost savings provided by potential convergence of platforms and systems across asset classes; and
+• Whether potential costs vary based on size / business model / characteristics of reporting firms, e.g., introducing vs. clearing firms, large vs. small firms, broker-dealers vs. ATSs.
+The respondents stated that there were material differences between equity markets and debt markets with respect to order characteristics, order handling and trade execution. The respondents also expressed that order handling and trading is predominantly OTC, where dealers communicate through informal networks.
+There may be potential benefits associated with a life cycle reporting regime in debt markets, where more granular data, as depicted in Approach #3, may potentially provide regulators with a detailed view of market participants’ decision-making behavior and can provide further insight into relevant regulatory issues such as the cost of liquidity provision or best execution practices in debt markets. As noted above, order receipt and execution are frequently concurrent, as the execution is an outcome of a negotiated process of order details, and an order is placed only once the execution terms are agreed upon. Moreover, the Participants understand that OMSs that automatically capture the details of the order are not utilized at every firm or for every order; therefore, it is likely that the requirement to collect more information that is not currently being collected will impose greater direct costs on firms, which may potentially result in a change in the way they participate in debt markets, and this could eventually impact investors. Respondents voiced concerns that the collection of order details may become so costly that representatives may switch to offering substitute products such as mutual funds and ETFs to their clients. Such a change in behavior potentially could reduce liquidity in the debt markets, reducing the price efficiency in these instruments. The burden of collecting and reporting such data potentially would be more significant for small firms, and the respondents asserted that some of these firms would be more likely to exit the market.
+The respondents also raised concerns regarding establishing linkages across new order, route and execution reports. Building such linkages necessitates creating connectivity across desks and third-party providers, but, due to the manual process of order receipt and routing orders, using a unique order ID to link the reports would not be feasible for most orders. Such a challenge would be more prominent for certain types of securities. Respondents also indicated that communicating with other broker-dealers regarding an order involves multiple feeds and messages and such messages may contain information regarding multiple orders with varying special conditions. Therefore, building a complete order life cycle for debt securities in a manner similar to equities was not perceived by respondents as a viable option.
+Respondents commented that order and execution characteristics are generally different for larger-sized orders, where there is more negotiation and communication across brokers, which may potentially result in a large number of route reports that are recorded manually. Collecting and processing such information may result in significant costs that may hinder the ability to trade large amounts in debt markets.
+Respondents also provided feedback on issues pertaining to reporting such information to CAT. They stated that uniform reporting across all debt securities may potentially create gaps and inconsistencies across different types of debt securities due to the differences in characteristics. However, some respondents believed that a single transaction reporting platform for all types of debt securities may save costs in the long run, provided that a single platform is flexible enough to capture differences across life cycles of different security types (i.e., a single platform for reporting TRACE-Eligible and municipal securities, instead of separately reporting to FINRA, NYSE and MSRB).
pubdate: N/A effdate: N/A
- 2.7. JSON and CSV Examples
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, JSON and CSV Examples
- Compliance User: Industry Member
- Keywords:
- This provides an illustration of the different reporting formats of JSON and CSV.
-pubdate: N/A effdate: N/A
- 2.7.1. JSON Representation
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, JSON and CSV Examples, JSON Representation
- Compliance User: Industry Member
- Keywords:
- JSON representation,
- Internalized Trade,
-
- Below is a JSON representation using the example in section 2.2.2 Internalized Trade Against Proprietary Account.
-
-
- pubdate: N/A effdate: N/A
- 2.7.2. CSV Representation
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, JSON and CSV Examples, CSV Representation
- Compliance User: Industry Member
- Keywords:
- CSV representation,
-
- Below is the corresponding CSV representation of the same sample events.
-Step 2: New Order Event MENO,20180416T153035.234456,E,false,,,XYZ,O12345,N,T,A,,Buy,10.00,,,50 0,,,LMT,,DAY,REG,,,false,INS001,A,,,N,,false,,,,,,,
-Step 3: New Order Event MENO,20180416T153035.234457,E,false,,,XYZ,P12345,F,T,PR,,Sell,10.00,,, 500,,,LMT,,DAY,REG,,,false,PROP123,P,,,N,,false,,,,,,,
-Step 4: Trade Event MEOT,20180416T153035.253456,false,,,XYZ,TXYZ555,500,10.00,DN,NA,TERM123,O1234 5, FRMA,Buy,0,Agency,TRF123,P12345,FRMA,Sell,0,Principal,TRF123,,,,,,,
-pubdate: May 15, 2017 effdate: N/A
+ E. Recommendations and Projected Implementation Timeframe
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Debt Securities, Recommendations and Projected Implementation Timeframe
+ Compliance User: Equity Securities
+ Keywords:
+ Expansion Document,
+ Reporting Information,
+ FINRA,
+ TRACE,
+ MSRB's RTRS System,
+ NYSE Bonds System,
+ Industry Members,
+ OATS,
+
+ As of the submission of this Expansion Document to the Commission, no Participants or industry members are reporting information to the CAT, and Technical Specifications detailing required order information for equity securities by broker-dealers are not yet available. Consequently, it is impractical for the Participants to attempt to itemize with any degree of specificity, beyond that described in Section I.C. above, the order details that might be appropriate to report information regarding orders in debt securities. Based on conversations with industry participants and industry trade organizations, the Participants note the following important considerations:
+• Trade information involving significant portions of the debt markets are already reported to FINRA’s TRACE system, MSRB’s RTRS system, or to the NYSE Bonds system. Consequently, leveraging existing systems could be a more efficient and cost-effective manner to expand the reporting of information concerning debt transactions to include order information.
+• Among industry members, order handling practices for debt securities vary significantly from those in place for equity security orders, primarily due to the differences in the nature of the markets between the two types of securities. Consequently, attempting to replicate the order reporting paradigm for equity securities onto the debt markets is not advisable.
+• The obligation to report information concerning debt security orders and transactions to the CAT would fall primarily on broker-dealers as a substantial majority of all debt market activity is conducted OTC rather than on an exchange. Some of these broker-dealers lack the current infrastructure to report order information. For example, 13% of FINRA members that currently report to TRACE do not conduct equity activity and thus do not report to FINRA’s Order Audit Trail System (“OATS”) and would not have CAT reporting requirements under the Plan. Consequently, expanding order reporting obligations to include debt securities would be a costly and time-intensive effort for these firms.
+As a result of these considerations, the Participants do not currently recommend that the Commission take any steps with respect to requiring the reporting of order information regarding debt securities, including primary market transactions in debt securities,63 to the CAT. The Participants believe such an expansion would be premature at this time and should be considered only after both Participants and industry members are successfully reporting equity securities and listed options information to the CAT so that experience with the operation of the CAT can be used to inform any future expansion. In addition, other alternatives, besides an expansion of CAT, should be considered as a means to collect order data related debt securities. As noted previously, the Participants recommend that the MSRB be consulted before any analysis regarding the potential expansion of the CAT to municipal securities is undertaken. Moreover, a reliable cost/benefit analysis cannot be performed until the Participants and industry members have more details as to the specific information that would be required to be reported and how that information would be reported.
pubdate: N/A effdate: N/A
- 3. Option Scenarios and Examples
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples
- Compliance User: Industry Member
- Keywords:
- This section illustrates reporting scenarios for single leg electronic option events in scope for Phase 2b. Each example includes a process flow table and sample reporting values.
-pubdate: N/A effdate: N/A
- 3.1. Option Order Origination and Route Scenarios
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Origination and Route Scenarios
- Compliance User: Industry Member
- Keywords:
- This section lays out the fundamental and common reporting scenarios. In addition to the scenarios provided below, please also refer to Equity Event Scenarios 2.1.5 (assume split route is two non-ATS Industry Members) and 2.1.6. The guidance also applies to single leg electronic option order reporting.
-pubdate: N/A effdate: N/A
- 3.1.1. New Principal Option Order Routed to Exchange and Executed
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Origination and Route Scenarios, New Principal Option Order Routed to Exchange and Executed
- Compliance User: Industry Member
- Keywords:
- New Option Order (Principal),
- Option Order Route event,
-
- This scenario illustrates the reporting requirements to CAT for an Industry Member that creates a new principal option order electronically, and electronically routes it to an exchange where it is executed.
-For this scenario, Industry Member Broker 1 is required to report the following events:
-• The creation of a New Option Order (Principal)
-• The route to an exchange as an Option Order Route event
-
-
-
- pubdate: N/A effdate: N/A
- 3.1.2. Customer Option Order Routed to the Exchange
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Origination and Route Scenarios, Customer Option Order Routed to the Exchange
- Compliance User: Industry Member
- Keywords:
- New Option Order event,
- Option Order Route event,
-
- This scenario illustrates the reporting requirements to CAT for an Industry Member that routes a customer order to an exchange.
-For this scenario, Industry Member Broker 1 is required to report the following events:
-• New Option Order event for the customer order which was received electronically
-• Option Order Route event for routing the customer order to the exchange
-In this scenario, the execution is passed back directly to the customer, therefore no Option Order Fulfillment is required to be reported.
-
-
-
- pubdate: N/A effdate: N/A
- 3.1.3. Option Order Electronically Routed between Two Industry Members and Subsequently Executed
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Origination and Route Scenarios, Option Order Electronically Routed between Two Industry Members and Subsequently Executed
- Compliance User: Industry Member
- Keywords:
- FLEX Percent option,
- New Option Order event,
- Option Order Route event,
- Option Order Accepted event,
- Option Order Route event,
-
- This scenario illustrates the reporting requirements when an option order is electronically routed from one Industry Member to another.
-
- For this scenario, Industry Member Broker 1 is required to report the following events:
-• New Option Order event for the customer order which was received electronically
-• Option Order Route event for routing the customer option order to Broker 2
-For this scenario, Industry Member Broker 2 is required to report the following events:
-• Option Order Accepted event for receiving the client order from Broker 1
-• Option Order Route event for routing the order to the Exchange
-
-
-
- pubdate: N/A effdate: N/A
- 3.1.4. Customer Option Order Manually Received, Routed Electronically
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Origination and Route Scenarios, Customer Option Order Manually Received, Routed Electronically
- Compliance User: Industry Member
- Keywords:
- CAT Reporting,
- priorUnlinked = M,
-
- This scenario illustrates the reporting requirements for Phase 2b for a customer order received manually by an Industry Member that is systematized and electronically routed.
-For this scenario, Industry Member Broker 1 is required to report the following events: • Option Order Route event for the route of the option order to the exchange
-In Phase 2b, the Option Order Route event must include the priorUnlinked= M, indicating the prior step is a manual handling not reported in Phase 2b.
-
-
-
- pubdate: N/A effdate: N/A
- 3.1.5. Customer Option Order Received Electronically, Manually Routed
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Origination and Route Scenarios, Customer Option Order Received Electronically, Manually Routed
- Compliance User: Industry Member
- Keywords:
- Participant Simple Option Order Accepted event,
- Exchange reports a Participant Simple Option Trade event,
- nextUnlinked flag,
- priorUnlinked flag,
-
- This scenario illustrates the reporting requirement for Phase 2b for a customer order received electronically by an Industry Member that is manually routed to another Industry Member. The order is then subsequently routed to the exchange.
-
- For this scenario, Industry Member Broker 1 is required to report the following events:
-• New Option Order event for the customer order which was received electronically (The nextUnlinked flag must be marked as "M" indicating next step is a manual handling so no linkage is available)
-For this scenario, Industry Member Broker 2 is required to report the following events:
-• Option Order Route event for the route of the option order to the exchange (The priorUnlinked flag must be marked as "M" indicating prior step is a manual handling so no linkage is available)
-
-
+ pubdate: May 15, 2017 effdate: N/A
+ II. PRIMARY MARKET TRANSACTIONS
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Primary Market Transactions
+ Compliance User: Equity Securities
+ Keywords:
+ CAT NMS plan,
+ Primary Market Transactions,
+ CAT Reporting,
+
+ As the Participants described in the CAT NMS Plan, an eventual expansion of the CAT to gather complete information on Primary Market Transactions would be beneficial to providing regulators with a comprehensive audit trail that efficiently and accurately tracks all activity in NMS Securities throughout the U.S. markets.64 The Participants received cost and other information regarding the expansion of the CAT to include Primary Market Transactions in NMS Securities during the comment process for the CAT NMS Plan. Based on the Participants’ 2016 analysis, the Participants concluded that it would be appropriate to limit CAT submissions related to allocations in Primary Market Transactions to sub-account allocations.65
+The Participants believe that any recommendation to expand the CAT to include Primary Market Transactions is premature and should be based on data derived from Participant and Industry Members’ actual experience with CAT reporting. In support of this recommendation, this section discusses our current view of the costs and benefits of the expansion of CAT to include both top-account and sub-account allocations for Primary Market Transactions.66 As required by the Plan, this section also includes details for each order and Reportable Event that may be required to be provided, which market participants may be required to provide the data, the implementation timeline, and a cost estimate associated with incorporating Primary Market Transactions into the CAT.
+pubdate: May 15, 2017 effdate: N/A
+ A. Top-Account Allocations
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Primary Market Transactions, Top-Account Allocations
+ Compliance User: Equity Securities
+ Keywords:
+ CAT,
+ DAG,
+ SRO,
+
+ The Participants, during the course of developing the CAT, received cost estimates regarding inclusion of top account allocation information from members of the Development Advisory Group (“DAG”), a group of industry participants formed to assist the SROs with information to inform the design and implementation of the CAT. Using that data, the SROs concluded that reporting top-account allocation information was not currently justified because of the significant costs likely associated with requiring top-account allocations and the marginal benefit likely derived from reporting top-account information in Primary Market Transactions to the CAT.67 Commenters supported this conclusion, indicating that significant analysis and data modeling are required to implement the inclusion of Primary Market Transactions, and the inclusion of top-account information is less feasible than the inclusion of sub-account allocations.68 Furthermore, given the lack of experience with the CAT, market participants cannot currently provide more definitive cost figures related to such a proposal.
+pubdate: May 15, 2017 effdate: N/A
+ 1. Scope
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Primary Market Transactions, Top-Account Allocations, Scope
+ Compliance User: Equity Securities
+ Keywords:
+ CAT,
+ Primary Market Transactions,
+
+ The Participants understand that top-account allocations occur during the book-building phase of Primary Market Transactions. During this phase, the underwriter engages in efforts to ascertain indications of interest in purchasing quantities of the underwritten securities at varying prices from potential investors. Based on this information, the underwriter will then decide how to allocate IPO shares to purchasers. Accordingly, the top-account allocation could be defined to include the following: (1) the conditional indications of interest that may fluctuate until the offering syndicate terminates, and (2) the final allocation (that is, the actual allocation of securities to the customers’ accounts).
+The cost-benefit analysis also depends upon which market participant(s) would be obligated to report the data to the CAT. As the Commission noted, the estimate included in Appendix C of the Plan was sensitive to the number of underwriters.69 In particular, the estimates assumed that all underwriters participating in an offering would need to implement changes if required to submit top-account allocation information. In contrast, however, the Commission suspected that the total number of underwriters that would need to implement changes for top-account information may be lower because lead underwriters could have all of the information necessary to report the top-account allocation information, depending upon the top-account allocation information that was required to be reported. If only the lead underwriters need to implement systems changes to report top-account allocations, the total implementation costs could be lower.
+In addition, the cost-benefit analysis depends on the data elements that would need to be reported for each Primary Market Transaction. The Participants anticipate that the following top-account allocation data could be reported to the CAT:
+• the identity of all market participants that receive top-account allocations of NMS Securities in Primary Market Transactions;
+• the identification of the relevant NMS Security;
+• the number of such NMS Securities each such market participant is allocated via a top-account;
+• the identity of the entity making each such allocation; and
+• the time of the top-account allocation.
+pubdate: May 15, 2017 effdate: N/A
+ 2. Costs and Benefits
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Primary Market Transactions, Top-Account Allocations, Costs and Benefits
+ Compliance User: Equity Securities
+ Keywords:
+ Benefits,
+ CAT NMS plan,
+ Participants,
+ Costs,
+ CAT Reporters,
+ broker-dealers,
+ DAG,
+
+ a. Benefits
+As set forth in the CAT NMS Plan, the Participants believe that most of the potential benefits could be achieved through the collection of sub-account information.70
+In contrast to the Participants’ conclusions about the value of top-account allocations, the SEC stated that it believes that the inclusion of top-account allocations in the CAT would provide significant regulatory benefits beyond those provided by sub-account allocations.71 The SEC noted that top-account allocation information would be necessary to conduct surveillance for prohibited activities in the book-building process and would improve the efficiency of investigations into such prohibited activities. The SEC also noted that top-account allocation information would provide useful insights into IPO and follow-on allocations in market analysis and that such insights would help inform rulemaking and other policy decisions.72
+Similarly, in response to the proposal of the CAT NMS Plan, one commenter emphasized that many benefits could only be achieved by requiring the reporting of primary market transactions at both the top-account and the sub-account allocation levels.73 Further, this commenter also stated that top-account information would facilitate analyses of the value of discretionary allocation in book-building for issuers. This commenter also indicated that final top-account allocations should be sufficient to achieve such benefits, while also indicating that information on the indications of interest was crucial for the understanding of the capital formation process and for designing efficient regulations that would facilitate capital formation without compromising investor protection.74
+However, the Participants maintain that because top account information of conditional and interim allocations for NMS Securities fluctuates throughout the syndicate process and may vary significantly among firms, the marginal benefits of such information over final sub-account allocations are much less.75
+b. Costs
+The Participants concluded in the CAT NMS Plan that the inclusion of top-account allocations would likely impose significant costs on CAT Reporters. The Participants understand that broker-dealers generally maintain top-account allocation information in book building systems that are separate from their systems for secondary market transactions and that differ across the industry, including the use of applications provided by third parties, in house systems and spreadsheets for small firms. The Participants also understand that the investment banking divisions of broker-dealers typically use different compliance systems than those used for secondary market transactions.76 In addition, the Participants conclusion is based on the estimate received from the DAG that providing top-account allocations would costs $176.1 million.77
+One commenter disputed the DAG’s estimate, stating that the cost would be substantially less, approximately $2,400 per offering for providing top-account allocation information,78 although this estimate may measure the ongoing annual costs to maintain reporting, rather than the implementation costs of adding top-account allocation information to the CAT. Similarly, the SEC posited that the cost to add top-account information to the CAT may be lower than estimated, noting that the cost depended on timestamp requirements and the number of underwriters subject to the reporting requirement.79 The Participants note, however, that they currently have no authoritative information indicating that the less stringent timestamp requirement would result in any material reduction on the cost for Industry Members to institute new systems to enable such reporting. The SEC also noted that it is unclear whether the cost estimates cover the inclusion of indications of interest, or the final top-account allocation information.80
+In light of the varying cost estimates for the inclusion of top-account allocation information in the CAT, the Participants recommend that additional cost analysis be conducted regarding the inclusion of top-account information in the CAT, both for the inclusion of final top-account allocation information and the inclusion of book building indications of interest. Such analysis should be conducted after a period of experience of industry reporting into the CAT. Without the experience of industry reporting into the CAT and without detailed technical analysis by the various industry members who would provide such top-account data, however, the SROs have no ability to improve upon the current cost estimates in this area.
pubdate: N/A effdate: N/A
- 3.2. Fulfillment Scenario s
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Fulfillment Scenario s
- Compliance User: Industry Member
- Keywords:
- pubdate: N/A effdate: N/A
- 3.2.1. Broker Receives Single-Leg Electronic Orders, Creates Complex Order and Routes to Exchange
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Fulfillment Scenario s, Broker Receives Single-Leg Electronic Orders, Creates Complex Order and Routes to Exchange
- Compliance User: Industry Member
- Keywords:
- nextUnlinked = C,
- fulfillmentLinkType = YF,
- priorUnlinked = C,
- New Option Order events,
- Option Order Fulfillment events,
-
- This scenario illustrates the Phase 2b reporting requirements for Industry Members when a complex option order is created from multiple single leg option orders. For Phase 2b, there is no linkage required between the single leg option orders and the complex order.
-
- For this scenario, Industry Member Broker 1 is required to report the following events:
-• New Option Order events for each single leg customer order electronically received
-• Option Order Fulfillment events for each single leg customer order post execution of the complex order
-In Phase 2b, the two New Option Order events must be flagged as nextUnlinked = C, indicating that the orders are represented by a complex order so no linkage to the complex order in Phase 2b.
-
-
-
+ pubdate: May 15, 2017 effdate: N/A
+ B. Sub-Account Allocations
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Primary Market Transactions, Sub-Account Allocations
+ Compliance User: Equity Securities
+ Keywords:
+ CAT NMS plan,
+ Participants,
+
+ As described in the CAT NMS Plan, information related to sub-account allocations is maintained by broker-dealers in a manner that may allow for reporting to the CAT without unreasonable costs and could assist the Commission and the Participants in their regulatory obligations, including a variety of rulemaking and policy decisions.81 Accordingly, the Participants continue to recommend the inclusion of sub-account allocations in the CAT as a future phase in CAT reporting.
+pubdate: May 15, 2017 effdate: N/A
+ 1. Scope
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Primary Market Transactions, Sub-Account Allocations, Scope
+ Compliance User: Equity Securities
+ Keywords:
+ CAT,
+ CAT Market,
+ Primary Market Transactions,
+ NMS Securities,
+
+ The costs and benefits of including sub-account allocation information in the CAT depend on the definition of what constitutes a sub-account allocation and what information is to be reported about the sub-account allocations. The Participants understand that sub-account allocations represent the allocation of IPO shares to the actual account receiving the shares. Sub-account allocations occur after top-account allocations and are made by the top-account institutions and broker-dealers prior to settlement.82
+The cost-benefit analysis also depends upon which market participant(s) would be obligated to report the data to the CAT Market. In addition, the cost-benefit analysis also depends upon the data elements that would need to be reported for each primary market transaction. The Participants anticipate that the following sub-account allocation data may be reported to the CAT:
+• the identity of all market participants that receive sub-account allocations of NMS Securities in Primary Market Transactions;
+• the identification of the relevant NMS Security;
+• the number of such NMS Securities each such market participant is allocated via a sub-account;
+• the identity of the market participant making each such allocation; and
+• the time of the sub-account allocation.
+pubdate: May 15, 2017 effdate: N/A
+ 2. Cost and Benefits
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Primary Market Transactions, Sub-Account Allocations, Scope, Cost and Benefits
+ Compliance User: Equity Securities
+ Keywords:
+ Costs,
+ Primary Market Transactions,
+ broker-dealers,
+ Benefits,
+ Industry Members,
+ Participants,
+
+ a. Benefits
+As set forth in the CAT NMS Plan, the Participants noted that sub-account allocation information could aid the Commission and the Participants to gain a better understanding of how shares allocated in Primary Market Transactions are sold in the secondary market, or how allocations differ across broker-dealers.83 The Commission agreed that such data could improve compliance monitoring and market analyses by the Commission and the Participants, which, in turn, could help inform rulemaking and other policy decisions.84 For example, such data could enhance the Commission’s understanding of the role of the allocations in the capital formation process, when and how investors receiving allocations sell their Eligible Securities and how allocations differ among broker-dealers.85 Such data also could assist the Commission and Participants in conducting their respective examinations and investigations related to Primary Market Transactions.86
+b. Costs
+Based on feedback from Industry Members, the Participants understand that it would be more feasible to gather information relating to sub-account allocations in Primary Market Transactions than top-account allocations.87 The Participants noted their understanding that sub-account allocations are received in a manner and level of detail similar to allocations in secondary market transactions, and that the same middle and back office systems that are used for the processing of sub-account allocations for secondary market transactions generally are also used for the sub-account allocations for Primary Market Transactions. If Industry Members maintain sub-account allocations for Primary Market Transactions in an electronic format that could be converted into a reportable format acceptable for the CAT System, it may be that certain Industry Members could more easily report information about sub-account allocations to the Central Repository. 88 In addition, the Participants’ conclusion was based on the DAG estimate that providing sub-account allocations would cost approximately $58.7 million (as opposed to the much higher $171.6 million for top-account allocations).89
+This conclusion was further supported by another commenter, which argued that the incremental cost of providing sub-account allocation information would be de minimis.90
pubdate: N/A effdate: N/A
- 3.3. Option Order Modification Scenarios
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Modification Scenarios
- Compliance User: Industry Member
- Keywords:
- This section illustrates the common scenarios of single-leg option modifications and the CAT reporting requirements for Phase 2b. In addition to the scenarios provided below, please refer to Equity Event Scenarios 2.4.1,2.4.3, and 2.4.4. The guidance also applies to single leg electronic option order reporting.
-pubdate: N/A effdate: N/A
- 3.3.1. Customer Initiates Modification of Option Order Previously Routed to the Exchange
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Modification Scenarios, Customer Initiates Modification of Option Order Previously Routed to the Exchange
- Compliance User: Industry Member
- Keywords:
- New Option Order event,
- Option Order Route event,
- Option Order Modification event,
- second Option Order Route event,
-
- This scenario illustrates a customer-initiated modification (electronically) of an option order which the Industry Member had previously routed to an exchange.
-In this scenario, Industry Member Broker 1 is required to report the following events:
-• A New Option Order event for the electronic receipt of the customer order
-• Option Order Route event for the route to the exchange
-• An Option Order Modification event for the electronic receipt of the order modification
-• A second Option Order Route event for the route of the modified option order to the exchange
-
-
-
-
- pubdate: May 15, 2017 effdate: N/A
+ C. Implementation Timeline
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Primary Market Transactions, Implementation Timeline
+ Compliance User: Equity Securities
+ Keywords:
+ CAT NMS plan,
+ CAT Reporting,
+ Industry Member CAT Reporters,
+ SIFMA,
+ SRO,
+
+ As noted in the CAT NMS Plan, the Participants do not support the inclusion of any Primary Market Transaction information in the initial phase of CAT reporting.91 As one commenter noted, primary market transactions should not be added to the CAT until regulatory and surveillance requirements have been defined.92 As such, the Participants recommend that further analysis regarding the possible inclusion of Primary Market Transaction data occur no sooner than six months after the Industry Member CAT Reporters have gained experience with implementing changes to secondary market transaction systems and have gained experience reporting to the CAT. Such experience will permit more informed cost analyses. Further supporting the SRO’s recommendation, SIFMA explained that the industry is currently absorbing substantial new regulatory costs. Allowing determination whether to require top-account and sub-account data be reported to CAT reporting to benefit from experience with the CAT would allow the industry to better absorb additional cost because of the experience reporting other data to the CAT and because of the longer time horizon that CAT Reporters would have to comply with any added requirement.93
pubdate: N/A effdate: N/A
- 3.4. Cancellation Scenarios
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Cancellation Scenarios
- Compliance User: Industry Member
- Keywords:
- Reporting option order cancellations follow the same guidance as equities. Please refer to Section 2.5 for examples.
+pubdate: May 15, 2017 effdate: N/A
+ III. EQUITY SECURITIES OTHER THAN NMS SECURITIES AND OTC EQUITY SECURITIES
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Equity Securities Other than NMS Securities
+ Compliance User: Equity Securities
+ Keywords:
+ Sec Rule 613,
+ CAT NMS plan,
+ NMS Securities,
+ OTC Equity Securities,
+
+ Rule 613(i) requires the CAT NMS Plan to include a provision requiring the Participants to include in the Expansion Document how the Participants could incorporate into the CAT information with respect to equity securities that are not NMS Securities or OTC Equity Securities, including primary market transactions in such securities. Section 6.11 of the CAT NMS Plan effectuates this requirement. The CAT NMS Plan submitted to the Commission by the Participants included OTC Equity Securities as Eligible Securities subject to CAT reporting requirements; consequently, OTC Equity Securities are already subject to the same CAT reporting requirements as NMS Securities.94
+Although the vast majority of securities that trade on Participant exchanges are Eligible Securities, the Participants considered whether two types of transactions that may fall into this category are cabinet trades and trades in Flex options. After reviewing these trades, the Participants determined to include Reportable Events regarding cabinet trades and Flex options in the CAT. This section describes cabinet trades and flex trades.
+pubdate: May 15, 2017 effdate: N/A
+ A. Cabinet Trades
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Equity Securities Other than NMS Securities, Cabinet Trades
+ Compliance User: Equity Securities
+ Keywords:
+ Trades,
+ OPRA,
+
+ Cabinet trades are manual trades that are executed in order to remove worthless options from a member firm’s books for accounting purposes. The trades are permitted by exchange rules and typically execute at a price of $1 per options contract. These relatively rare trades are manual trades that are not reported to OPRA.
pubdate: N/A effdate: N/A
- 3.5. Additional Reporting Scenarios
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios
- Compliance User: Industry Member
- Keywords:
- In addition to the scenarios provided below, please refer to Equity Event Scenarios 2.6.1, 2.6.3, 2.6.6, 2.6.7, 2.6.8, and 2.6.9. The guidance also applies to single leg electronic option order reporting.
-pubdate: N/A effdate: N/A
- 3.5.1. Customer Option Order Internally Routed Electronically
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Customer Option Order Internally Routed Electronically
- Compliance User: Industry Member
- Keywords:
- eventTimestamp,
- openCloseIndicator,
-
- This scenario illustrates the reporting requirements for CAT when an Industry Member internally routes a customer option order from the sales desk to the trading desk within the same Industry Member firm.
-For this scenario, Industry Member Broker 1 is required to report the following events:
-• New Option Order event for the customer order which was received electronically
-• Option Order Internal Route event from the sales desk to the trading desk
-• Option Order Route event for the route of the option order to the exchange
-
-
-
- pubdate: N/A effdate: N/A
- 3.5.2. Customer Option Order Internally Routed Electronically, Trading Desk Creates Child Orders Prior to Route
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Customer Option Order Internally Routed Electronically, Trading Desk Creates Child Orders Prior to Route
- Compliance User: Industry Member
- Keywords:
- Child Order events,
- Option Order Internal Route event,
- orderIDs,
- Option Order Route events,
-
- This scenario illustrates the reporting requirements for an Industry Member that creates child orders prior to routing the order slices. Child Order events are always electronically created.
-For this scenario, Industry Member Broker 1 is required to report the following events:
-• New Option Order event for the customer order which was received electronically
-• Option Order Internal Route event from the sales desk to the trading desk
-• Child Order events for slicing the original order into smaller quantities and assigning new orderIDs prior to routing from the Trading Desk
-• Option Order Route events for the route of each child option order to an exchange
-
-
-
-
- pubdate: N/A effdate: N/A
- 3.5.3. Industry Member Receives Complex Option Order, Splits into Individual Single Order Legs to be Worked in the Customer's Account
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Industry Member Receives Complex Option Order, Splits into Individual Single Order Legs to be Worked in the Customer's Account
- Compliance User: Industry Member
- Keywords:
- priorUnlinked = C,
-
- This scenario illustrates the reporting requirements for an Industry Member in Phase 2b that receives a complex option order but routes single leg option orders directly from the customer's account to the exchange without creating new single leg option orders. Linkage between the original complex option order and the single leg option order routes is not required in Phase 2b, but reporters must indicate on the Option Order Route event there is no prior step reported since it was a complex order by populating field priorUnlinked = C. Since the single leg orders were routed to the exchange as single legs, linkage to the related single leg exchange order is required.
-In this scenario, Industry Member Broker 1 is required to report the following events:
-• Option Order Route events for each single leg option order routed to the exchange
-
-
-
- pubdate: N/A effdate: N/A
- 3.5.4. Industry Member Receives Complex Option Order, but Client Sends Multiple Single Leg Option Orders Electronically
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Industry Member Receives Complex Option Order, but Client Sends Multiple Single Leg Option Orders Electronically
- Compliance User: Industry Member
- Keywords:
- handlingInstruction 'CMPX,
- nextUnlinked = 'C,
-
- This scenario illustrates the reporting requirements for an Industry Member that receives a complex order that is routed by the Industry Member to an exchange as a complex order but where the client sends single leg electronic messages due to limitations in the client's system.
-For Phase 2b, reporting this order is out of scope as it was intended to be handled as a complex order. In Phase 2b, the preferred approach is that the Industry Member not report the electronic single leg orders as complex orders are not in scope. However, if Industry Member's elects to report the single legs, they must populate handlingInstruction 'CMPX' and include the nextUnlinked = 'C', to indicate there is no linkage to additional order events as subsequent handling was at the complex order level.
-
-
-
-
- pubdate: N/A effdate: N/A
- 3.5.5. Industry Member Routes Multiple Single Leg Option Orders to another Industry Member, Calls with Complex Order Instructions
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Industry Member Routes Multiple Single Leg Option Orders to another Industry Member, Calls with Complex Order Instructions
- Compliance User: Industry Member
- Keywords:
- Option Order Route,
-
- This scenario illustrates the reporting requirements for Phase 2b when a complex order is routed manually between two Industry Members, but the related electronic order messages are sent and received as single leg option orders. In Phase 2b, the preferred approach is that the Industry Member not report the electronic single leg orders as complex orders are not in scope. However, if Industry Member's elects to report the single legs, they must include handlingInstruction = 'CMPX'. The sending Industry Member must populate nextUnlinked = C on the Option Order Routes events, as no linkage will be available to the complex order at the receiving broker. Similarly, the receiving Industry Member should populate priorUnlinked = C on the Option Order Accepted events.
-In this scenario, if suppression of the electronic message is not possible, Industry Member Broker 1 would report the following events:
-• Four (4) New Option Order events for the electronic single leg orders
-• Four (4) Option Order Route events for the route of the single leg orders to Broker 2
-Industry Member Broker 2 would report the following events:
-• Four (4) Option Order Accepted events for the electronic routes received from Broker 1
-
-
-
-
-
-
-
-
-
- pubdate: N/A effdate: N/A
- 3.5.6. Industry Member Solicits Order, Creates Paired Option for Partial Quantity
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Industry Member Solicits Order, Creates Paired Option for Partial Quantity
- Compliance User: Industry Member
- Keywords:
- Industry Member Broker,
-
- This scenario illustrates the reporting requirements for an Industry Member that electronically received a single leg order from a customer, solicits another Industry Member to pair the order, but is left with a partial quantity of the single leg order still to work. Only the single leg components of the lifecycle are required for CAT reporting in Phase 2b, as paired option orders are not required until Phase 2d.
-In this scenario, Industry Member Broker 1 is required to report the following events:
-• New Option Order event for the receipt of the customer order
-• Option Order Route for the un-paired quantity of the single leg order
-
-
-
-
- pubdate: N/A effdate: N/A
- 3.5.7. Response to an Exchange Auction
-Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Response to an Exchange Auction
- Compliance User: Industry Member
- Keywords:
- Exchange Auction,
-
- This scenario illustrates the reporting requirements for a proprietary option order created in response to an Exchange Auction of a simple option or paired order of simple options. Responses to the complex auctions are deferred until 2D. The Industry Member must include the auction details on the handlingInstructions when reporting to CAT.
-In this scenario, Industry Member Market Maker 1 is required to report the following events:
-• New Option Order event for the creation of the proprietary order
-• Option Order Route event for the response to the exchange auction
-
-
-
- pubdate: May 15, 2017 effdate: N/A
+ B. Flex Options
+Topic: SEC Reports, CAT NMS Plan Potential Expansion, Discussion, DISCUSSION OF THE POTENTIAL EXPANSION OF THE CONSOLIDATED AUDIT TRAIL PURSUANT TO SECTION 6.11 OF THE CAT NMS PLAN, Equity Securities Other than NMS Securities, Flex Options
+ Compliance User: Equity Securities
+ Keywords:
+ Expiration Date,
+ Strike Price,
+ Exercise Style,
+
+ Flex options are bespoke option contracts where parties to the transaction may choose the expiration date, the strike price and the exercise style. These options are permitted by exchange rules, although the option is not standardized.
| fn |
+ 1 The CAT NMS Plan is a national market system plan approved by the Commission pursuant to Section 11A of the Exchange Act and the rules and regulations thereunder. See Securities Exchange Act Release No. 79318 (Nov. 15, 2016), 81 Fed. Reg. (Nov. 23, 2016). The full text of the CAT NMS Plan is available at www.catnmsplan.com. + |
| fn |
+ 2 The Participants to the CAT NMS Plan are Bats BYX Exchange, Inc., Bats BZX Exchange, Inc., Bats EDGA Exchange, Inc., Bats EDGX Exchange, Inc., BOX Options Exchange LLC, C2 Options Exchange, Incorporated, Chicago Board Options Exchange, Incorporated, Chicago Stock Exchange, Inc., Financial Industry Regulatory Authority, Inc., Investors’ Exchange LLC, Miami International Securities Exchange, LLC, MIAX PEARL, LLC, NASDAQ BX, Inc., Nasdaq GEMX, LLC, Nasdaq ISE, LLC, Nasdaq MRX, LLC, NASDAQ PHLX LLC, The NASDAQ Stock Market LLC, NYSE National, Inc., New York Stock Exchange LLC, NYSE MKT LLC, and NYSE Arca, Inc. + |
| fn |
+ 3 See Letter from Michael Simon, CAT NMS Plan Chair, to Brent J. Fields, Secretary, SEC (May 15, 2017). Unless otherwise defined herein, capitalized terms are defined as set forth in the CAT NMS Plan. + |
| fn | + + |
| fn |
+ 2 Securities Exchange Act Release No. 67457 (July 18, 2012), 77 Fed. Reg. 45722, 45743 (Aug. 1, 2012) (“Rule 613 Adopting Release”). + |
| fn |
+ 3 A copy of the CAT NMS Plan as filed on September 30, 2014, is available at https://www.sec.gov/divisions/marketreg/cat-nms-agreement.pdf. The cover letter for the CAT NMS Plan is available at https://www.sec.gov/divisions/marketreg/cat-nms-plan-letter.pdf. The Participants submitted an Amended and Restated CAT NMS Plan in February 2015 and several subsequent amendments, available at http://www.catnmsplan.com/catnmsplan/. + |
| fn |
+ 4 Securities Exchange Act Release No. 79318 (Nov. 15, 2016), 81 Fed. Reg. 84696 (Nov. 23, 2016) (“Plan Adopting Release”). + |
| fn |
+ 5 The Participants, with industry support, included equity securities that are not NMS securities in the definition of “Eligible Securities” under Article 1 of the CAT NMS Plan. See SIFMA Industry Recommendations for the Creation of the Consolidated Audit Trail (CAT) at 70 (Mar. 28, 2013) available at http://www.catnmsplan.com/Source/industryfeedback/p242319.pdf, and discussions with the Development Advisory Group (DAG) on July 24, 2013. + |
| fn |
+ 6 Rule 613 Adopting Release, supra note 2, at 45743. + |
| fn |
+ 7 See Securities Exchange Act Release No. 62174 (May 26, 2010), 75 Fed. Reg. 32556, at 32569, 32587-88 (June 8, 2010). + |
| fn |
+ 8 In 1975, Congress established the MSRB to regulate the activities of broker-dealers and banks that buy, sell and underwrite municipal securities. + |
| fn |
+ 9 Infra Section I.B.2 + |
| fn |
+ 10 NYSE operates the NYSE Bonds® system. Trading in eligible bonds by NYSE members on the NYSE Bonds system is pursuant to NYSE Rules 86-88. FINRA Rule 6730(e)(4) exempts FINRA members from reporting to TRACE transactions in TRACE-Eligible Securities that are executed on a facility of NYSE in accordance with specified NYSE rules and that are reported to NYSE and disseminated publicly, provided that a data sharing agreement between FINRA and NYSE related to transactions covered by FINRA Rule 6730 remains in effect. + |
| fn |
+ 11 On July 10, 2017, FINRA will begin requiring its members to report transactions in U.S. Treasury Securities (“Treasuries”). See FINRA Regulatory Notice 16-39; see also Securities Exchange Act Release No. 79116 (Oct. 18, 2016), 81 Fed. Reg. 73167 (Oct. 24, 2016) (Order Approving SRFINRA-2016-027). The discussion of debt securities in this document does not include Treasuries. + |
| fn |
+ 12 See Types of Bonds, available at http://www.finra.org/investors/types-bonds. + |
| fn |
+ 13 See id. + |
| fn |
+ 14 See id. + |
| fn |
+ 15 See FINRA Rule 6710(dd). + |
| fn |
+ 16 See FINRA Rule 6710(bb). + |
| fn |
+ 17 See Types of Bonds, available at http://www.finra.org/investors/types-bonds. + |
| fn |
+ 18 See 15 USC § 78o-4(b). + |
| fn |
+ 19 For example, at the end of 2016, there was approximately $39.4 trillion in outstanding U.S. bond market debt. Of that total, over one-third (approximately $13.9 trillion) was issued by the U.S. Treasury and another $3.8 trillion represented municipal securities. See U.S. Bond Market Issuance and Outstanding, available at www.sifma.org/research/statistics.aspx. + |
| fn |
+ 20 Kurt Shrout, “The U.S. Bond Market May Be Much Different Than You Think It Is,” LearnBonds, May 30, 2013. Accessed December 18, 2014, available at: http://www.learnbonds.com/how-big-is-the-bond-market. + |
| fn |
+ 21 Id. + |
| fn |
+ 22 Data was compiled from Federal Reserve data available at https://www.federalreserve.gov/data.htm. + |
| fn |
+ 23 For reporting purposes, FINRA maintains CUSIP information for trades reportable to the Over-the-Counter Reporting Facility (ORF) and FINRA’s Trade Reporting Facilities (TRFs). The ORF is the service provided by FINRA for the reporting of trades in OTC Equity Securities executed other than on or through an exchange and for trades in Restricted Equity Securities effected under Securities Act Rule 144A and dissemination of last sale reports. Each FINRA TRF provides FINRA members with a mechanism for the reporting of transactions effected otherwise than on an exchange. Trades by FINRA members in exchange-listed securities executed otherwise than on an exchange may be reported to a FINRA TRF. + |
| fn |
+ 24 From January 2015 through March 2017, there were 52,530 requests for CUSIPs for U.S. corporate or municipal bonds and 22,176 requests for CUSIPs for U.S. equities. Data compiled from CUSIP Issuance Trends available at https://www.cusip.com/cusip/insights.htm. + |
| fn |
+ 25 Data consolidated from SIFMA statistics available at http://www.sifma.org/research/statistics.aspx. TRACE reported debt information includes Agency MBS, Non-Agency MBS, ABS, Corporate Debt and Federal Agency Securities. Equity securities include NYSE, NASDAQ, BATS, Direct Edge, Other and Off-Exchange. + |
| fn |
+ 26 Information for Chart 4 was compiled from https://www.bats.com/us/equities/market_statistics/historical_market_volume/ (equity transactions) and http://www.finra.org/industry/trace/trace-fact-book (TRACE corporate transactions). + |
| fn |
+ 27 Supra note 20. + |
| fn |
+ 28 Id. + |
| fn |
+ 29 Supra note 20. This chart displays corporate bond market data excluding non-financial sector debt obtained from the Federal Reserve at https://www.federalreserve.gov/apps/fof/FOFTables.aspx. + |
| fn |
+ 30 Supra note 20. + |
| fn |
+ 31 See United States, Board of Governors of the Federal Reserve System, “Changes in U.S. Family Finances from 2010 to 2013: Evidence from the Survey of Consumer Finances,” Table 3, Federal Reserve Bulletin, September 2014, Vol. 100, No. 4. Accessed February 17, 2016. Available at: http://www.federalreserve.gov/econresdata/scf/scfindex.htm. + |
| fn |
+ 32 This chart displays the reduction in corporate bond trading in the secondary market 90 days after the issuance. See Bruce Mizrach, “Analysis of Corporate Bond Liquidity,” FINRA Office of the Chief Economist Research Note, December 2015 (“FINRA Study”), available at http://www.finra.org/sites/default/files/OCE_researchnote_liquidity_2015_12.pdf. + |
| fn |
+ 33 As of 2017, NYSE Bonds had 10,007 corporate debt securities reportable to its system and TRACE had 61,522 corporate debt securities. In 2016, the average number of corporate debt securities transactions reported to TRACE was approximately 54,600 per day and on NYSE Bonds it was 20 per day. + |
| fn |
+ 34 See Securities Industry and Financial Markets Association, “SIFMA Electronic Bond Trading Report: US Corporate & Municipal Securities,” February 2016 (“SIFMA Report”), available at http://www.sifma.org/issues/item.aspx?id=8589958906. + |
| fn |
+ 35 FINRA Rule 6710 provides that “TRACE-Eligible Security” means a debt security that is United States (“U.S.”) dollar-denominated and issued by a U.S. or foreign private issuer, and, if a “restricted security” as defined in Securities Act Rule 144(a)(3), sold pursuant to Securities Act Rule 144A; or is a debt security that is U.S. dollar-denominated and issued or guaranteed by an agency or a Government-Sponsored Enterprise (“GSE”). FINRA Rule 6710 also provides that “TRACE-Eligible Security” does not include a debt security that is issued by a foreign sovereign, or a U.S. Treasury Security, or a money market instrument. Effective July 10, 2017, the definition of “TRACE-Eligible Security” will be expanded to include U.S. Treasury Securities. However, as discussed herein, “TRACE-Eligible Security” refers to the definition prior to July 10, 2017, and does not include Treasuries. See supra note 11. + |
| fn |
+ 36 See also Section I.B.1.c. (Transactions Excepted or Exempt from TRACE). + |
| fn |
+ 37 FINRA Rule 6710 generally provides that “Agency Debt Security” means a debt security (i) issued or guaranteed by an agency; or (ii) issued or guaranteed by a GSE. The term excludes a U.S. Treasury Security and a Securitized Product (“SP”), where an agency or a GSE is the securitizer or the guarantor of the SP. + |
| fn |
+ 38 FINRA Rule 6710 generally provides that “Securitized Product” means a security collateralized by any type of financial asset, such as a loan, a lease, a mortgage, or a secured or unsecured receivable, and includes but is not limited to an asset-backed security as defined in Section 3(a)(79)(A) of the SEA, a synthetic asset-backed security, and any residual tranche or interest. + |
| fn |
+ 39 FINRA Rule 6710 generally defines ABS as a type of SP where the ABS is collateralized by any type of financial asset, such as a consumer or student loan, a lease, or a secured or unsecured receivable, and excludes: (i) an SP that is backed by residential or commercial mortgage loans, mortgage-backed securities, or other financial assets derivative of mortgage-backed securities; (ii) an SBA-Backed ABS traded To Be Announced (“TBA”) or in a Specified Pool Transaction; and (iii) a collateralized debt obligation. +FINRA Rule 6710 generally provides that “To Be Announced” means a transaction in an Agency Pass-Through Mortgage-Backed Security or an SBA-Backed ABS where the parties agree that the seller will deliver to the buyer a pool of a specified face amount and meeting certain other criteria but the specific pool to be delivered at settlement is not specified at the time of execution, and includes TBA transactions “for good delivery” and TBA transactions “not for good delivery.” +FINRA Rule 6710 generally provides that “Specified Pool Transaction” means a transaction in an Agency Pass-Through Mortgage-Backed Security or an SBA-Backed ABS requiring the delivery at settlement of a pool that is identified by a unique pool identification number at the time of execution. + |
| fn |
+ 40 Agency Pass-Through Mortgage-Backed Securities may be traded TBA for good delivery, TBA not for good delivery, or in Specified Pool Transactions. FINRA Rule 6710 generally provides that “Agency Pass-Through Mortgage-Backed Security” means a type of SP issued in conformity with a program of an agency or GSE, for which timely payment (principal and interest) is guaranteed by the agency or GSE representing ownership interest in a pool of mortgage loans structured to “pass through” payments to holders of the security on a pro rata basis. + |
| fn |
+ 41 FINRA Rule 6710 generally provides that “SBA-Backed ABS” means an SP issued in conformity with a program of the Small Business Administration (“SBA”), for which the timely payment of principal and interest is guaranteed by the SBA, representing ownership interest in a pool of loans or debentures and structured to “pass through” payments by borrowers to the holders of the security on a pro rata basis. + |
| fn |
+ 42 Transactions in SPs that are CMOs executed before the issuance of the security must be reported no later than the first settlement date of the security. See FINRA Rule 6730(a)(3)(C). + |
| fn |
+ 43 FINRA Rule 6710 generally provides that a “List or Fixed Offering Price Transaction” is a primary market sale transaction sold on the first day of trading of a security, including an ABS but excluding any other SP: (i) by a sole underwriter, syndicate manager, syndicate member or selling group member at the published or stated list or fixed offering price, or (ii) in the case of a primary market sale transaction effected pursuant to Securities Act Rule 144A, by an initial purchaser, syndicate manager, syndicate member or selling group member at the published or stated fixed offering price. + |
| fn |
+ 44 FINRA Rule 6710 provides that a “Reportable TRACE Transaction” is “any transaction in a TRACE-Eligible Security except: (1) a transaction that is not reported as specified in Rule 6730(e); and (2) a sale from an issuer to an underwriter(s) or initial purchaser(s) as part of an offering, except a sale of an Agency Pass-Through Mortgage-Backed Security as defined in [Rule 6710] paragraph (v) from a Securitizer as defined in paragraph (s) to any purchaser.” + |
| fn |
+ 45 Municipal securities are included in the definition of “exempted securities” under Exchange Act Section 3(a)(12)(A)(ii), except with respect to Exchange Act Sections 15 and 17A, and are defined in Section 3(a)(29) as “securities which are direct obligations of, or obligations guaranteed as to principal or interest by, a State or any political subdivision thereof, or any agency or instrumentality of a State or any political subdivision thereof, or any municipal corporate instrumentality of one or more States, or any security which is an industrial development bond (as defined in section 103(c)(2) of the Internal Revenue Code of 1954) the interest on which is excludable from gross income under section 103(a)(1) of such Code if, by reason of the application of paragraph (4) or (6) of section 103(c) of such Code (determined as if paragraphs (4)(A), (5), and (7) were not included in such section 103(c)), paragraph (1) of such section 103(c) does not apply to such security.” + |
| fn |
+ 46 MSRB, “Specifications for Real-Time Reporting of Municipal Securities Transactions,” Version 3.0, July 2016, available at http://www.msrb.org/msrb1/RTRS/RTRS-Specifications.pdf. + |
| fn |
+ 47 Id. + |
| fn |
+ 48 Id. + |
| fn |
+ 49 Special Condition Indicator – The code is used to indicate that a trade is eligible for an extended reporting deadline other than the 15-minute requirement; that a trade is subject to a special condition; and/or that a customer trade did not include a mark-up, markdown, or commission or an inter-dealer transaction executed with or using the services of alternative trading system (ATS) with Form ATS on file with the SEC. + |
| fn |
+ 50 Supra note 46. + |
| fn |
+ 51 Under MSRB Rule G-12(f)(iv)(A), an “Inter-Dealer Transaction Eligible for Comparison by a Clearing Agency Registered with the Commission” means a contract for purchase and sale between one dealer and another dealer, resulting in a contractual obligation for one such dealer to transfer municipal securities to the other dealer involved in the transaction, and which contract is eligible for comparison under the procedures of an automated comparison system operated by a registered clearing agency. + |
| fn |
+ 52 MSRB Rule D-9 defines “customer” to mean “any person other than a broker, dealer, or municipal securities dealer acting in its capacity as such or an issuer in transactions involving the sale by the issuer of a new issue of its securities.” Since Rule G-14 applies only to inter-dealer and customer trades, new issue transactions between an issuer and a broker-dealer, while not explicitly exempt from the reporting requirements, are not subject to the Rule because in this context an issuer is neither a customer nor a broker-dealer. + |
| fn |
+ 53 See NYSE Rule 86(b)(2)(B) for types of orders that may be entered on NYSE Bonds. + |
| fn | + + |
| fn |
+ 55 Id. + |
| fn |
+ 56 See Section I.E. (Recommendations and Projected Implementation Timeframe). + |
| fn |
+ 57 See supra note 3, Amended and Restated CAT NMS Plan at Appendix C, A.1(a)(iii) and Appendix D, 9. + |
| fn |
+ 58 See Bank for International Settlements, “Electronic trading in fixed income markets,” January 2016 (“BIS Report”), available at http://www.bis.org/publ/mktc07.pdf. + |
| fn |
+ 59 See Jack Bao, et al., “The Volcker Rule and Market-Making in Times of Stress,” December 8, 2016, available at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2836714. + |
| fn |
+ 60 Supra note 34. + |
| fn |
+ 61 Supra note 32. + |
| fn |
+ 62 FINRA conducted interviews with Securities Industry and Financial Markets Association (SIFMA), Financial Information Forum (FIF), and Bond Dealers of America (BDA). + |
| fn |
+ 63 Supra note 43. + |
| fn |
+ 64 See Amended and Restated CAT NMS Plan, supra note 3, at Appendix C. + |
| fn |
+ 65 Id. + |
| fn |
+ 66 Plan Adopting Release, supra note 4, at 84779-80. + |
| fn |
+ 67 Amended and Restated CAT NMS Plan, supra note 3, at Appendix C. + |
| fn |
+ 68 Letter to Brent J. Field, Secretary, SEC, from Mary Lou Kaenel, Managing Director, Financial Information Forum (July 8, 2016) (“FIF Letter”) at 13; Letter to Brent J. Field, Secretary, SEC, from Theodore R. Lazo, Managing Director and Associate General Counsel, and Ellen Greene, Managing Director, Financial Services Operations, Securities Industry and Financial Markets Association (July 18, 2016) (“SIFMA Letter”) at 36. + |
| fn |
+ 69 Plan Adopting Release, supra note 4, at 84904. + |
| fn |
+ 70 Amended and Restated CAT NMS Plan, supra note 3 at Appendix C. + |
| fn |
+ 71 Plan Adopting Release, supra note 4, at 84905. + |
| fn |
+ 72 Id. at 84904. + |
| fn |
+ 73 Letter to Brent J. Fields, Secretary, SEC, from Kathleen Weiss Hanley, Bolton-Perella Chair in Finance, Lehigh University, et al., (July 12, 2016) (“Hanley Letter”) at 4. + |
| fn |
+ 74 Id. at 5-6. + |
| fn |
+ 75 Amended and Restated CAT NMS Plan, supra note 3, at Appendix C. + |
| fn |
+ 76 Amended and Restated CAT NMS Plan, supra note 3, at Appendix C. + |
| fn |
+ 77 Id. + |
| fn |
+ 78 Hanley Letter, supra note 73, at 5. + |
| fn |
+ 79 Plan Adopting Release, supra note 4, at 84904. + |
| fn |
+ 80 Id. at 84905. + |
| fn |
+ 81 Amended and Restated CAT NMS Plan, supra note 3, at Appendix C. + |
| fn |
+ 82 Plan Adopting Release, supra note 4, at 84984. + |
| fn |
+ 83 Amended and Restated CAT NMS Plan, supra note 3, at Appendix C. + |
| fn |
+ 84 Plan Adopting Release, supra note 4, at 84984. + |
| fn |
+ 85 Id. + |
| fn |
+ 86 Id. + |
| fn |
+ 87 See generally Amended and Restated CAT NMS Plan, supra note 3, Appendix C, A.6. + |
| fn |
+ 88 Id. at Appendix C. + |
| fn |
+ 89 Id. + |
| fn |
+ 90 Hanley Letter, supra note 69, at 5. + |
| fn |
+ 91 Plan Adopting Release, supra note 4, at 84779. + |
| fn |
+ 92 SIFMA Letter, supra note 68, at 36. + |
| fn |
+ 93 Id. + |
| fn |
+ 94 The term “OTC Equity Security” is defined in the CAT NMS Plan as “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.” This would include all equity securities that are not NMS securities other than Restricted Equity Securities, which are not subject to prompt last sale reporting under FINRA rules, see FINRA Rules 6622(a)(3), 6420(f), and not reportable to FINRA’s Order Audit Trail System, see FINRA Rule 7410(l). Restricted Equity Securities are generally subject to trading restrictions, and the Participants believe inclusion of Restricted Equity Securities in the CAT should be considered only after the CAT is fully implemented. + |
jurisdiction: US
regulatory_authority: US/SEC
- content_type: compilation
- document_title: CAT Reporting Technical Specifications for Industry Members
- document_type: Specifications
- source: US/SEC/Specifications/Technical Specifications
- source_type: Technical Specifications
+ content_type: periodic
+ document_title: CAT NMS PLAN Rollout Plan (SEC Rule 613 Rollout Plan)
+ document_type: Plan
+ source: US/SEC/Plan/Rollout Plan
+ source_type: Rollout Plan
language: English
citation: N/A
- pubdate: February 28, 2019 effdate: N/A
- CAT Reporting Technical Specifications for Industry Members
-Topic: CAT Reporting Technical Specifications for Industry Members
- Compliance User: Industry Members
+ pubdate: N/A effdate: N/A
+ CAT NMS PLAN Rollout Plan (SEC Rule 613 Rollout Plan)
+Topic: CAT NMS, Rollout Plan
+ Compliance User: SRO/Broker-dealers
Keywords:
- Technical Specifications,
+ NMS Plan Participant,
+ SRO,
+ Implementation Date,
- 2/28/2019
-DRAFT Version 1.1
-pubdate: February 28, 2019 effdate: N/A
- Preface
-Topic: CAT Reporting Technical Specifications for Industry Members, Preface
- Compliance User: Industry Members
- Keywords:
- CAT NMS plan,
- SRO,
- CAT NMS LLC,
-
- Rule 613 of the Securities Exchange Act of 1934 requires national securities exchanges and national securities associations (“SROs”) to submit a national market system plan to the Securities and Exchange Commission (“Commission” or “SEC”) to create, implement, and maintain a consolidated audit trail (the “CAT”) that would allow regulators to more efficiently and accurately track all activity in U.S. equity and listed options markets. Pursuant to Rule 613, the SROs filed with the Commission the National Market System Plan Governing the Consolidated Audit Trail (“CAT NMS Plan”), which was approved by the Commission on November 15, 2016.
-Under Rule 613(g)(2), each member of a national securities exchange or national securities association is required to comply with all the provisions of the CAT NMS Plan. Relatedly, as mandated under Rule 613, the CAT NMS Plan requires each SRO to adopt rules requiring its members to comply with Rule 613 and the CAT NMS Plan, and to agree to enforce compliance by its members in that regard. Accordingly, each SRO has adopted rules requiring its members to comply with Rule 613 and the CAT NMS Plan. See, e.g., FINRA Rule 6800 Series.
-The SROs jointly own CAT NMS, LLC, which was formed by the SROs to arrange for and oversee the creation, implementation, and maintenance of the CAT as required under Rule 613. Thus, the CAT is a facility of each SRO.
-This specification represents a phased approach to industry reporting. Key dates are as noted below. Please note that a proposed amendment to the CAT NMS Plan will be filed with the Commission to reflect the phased approach for Industry Member CAT reporting described in these Technical Specifications. The proposed amendment will be subject to the Commission's approval.
-
-
- pubdate: February 28, 2019 effdate: N/A
- Executive Summary
-Topic: CAT Reporting Technical Specifications for Industry Members, Executive Summary
- Compliance User: Industry Members
- Keywords:
- CAT Industry Member Reporting Scenarios,
-
- This document describes the requirements for the reporting of data to CAT by Industry Members, including detailed information about data elements and file formats of each Reportable Event. It also describes how Industry Members should submit files to CAT, including access instructions, network and transport options, and testing requirements.
-A separate companion document containing detailed reporting scenarios entitled CAT Industry Member Reporting Scenarios should be used as a guide for determining how the event types and field values laid out in this document should be applied when reporting various order handling and execution scenarios for both equities and options.
-Revision / Change Process
-
-
- pubdate: February 28, 2019 effdate: N/A
- 1. Introduction
-Topic: CAT Reporting Technical Specifications for Industry Members, Introduction
- Compliance User: Industry Members
- Keywords:
- pubdate: February 28, 2019 effdate: N/A
- 1.1. CAT Overview
-Topic: CAT Reporting Technical Specifications for Industry Members, Introduction, CAT Overview
- Compliance User: Industry Members
- Keywords:
- Sec Rule 613,
- CAT NMS plan,
- CAT Reporting Agents,
- Securities Information Processors (SIPS),
-
- The Securities and Exchange Commission (SEC) approved Rule 613 under the Securities Exchange Act of 1934, which requires national securities exchanges and national securities associations (collectively, the Participants) to submit a national market system plan to create, implement, and maintain a consolidated audit trail (CAT NMS Plan) that would capture customer and order event information for orders in NMS Securities and OTC Equity Securities (Eligible Securities), across all markets, from the time of order inception through routing, cancellation, modification, execution, and allocation. The SEC approved the CAT NMS Plan on November 15, 2016.
-In accordance with SEC Rule 613, the CAT NMS Plan requires a Central Repository that will comprehensively track orders throughout their lifecycle and identify the Participants and Industry Members handling them, as well as the account holders and authorized traders for any account that originates an order (Customers1). Specific data elements will be submitted to the Central Repository by Participants, Industry Members, and CAT Reporting Agents. CAT Reporting Agents may be third-party firms reporting on behalf of other entities, or may be outside parties that are not required to submit data to the CAT, but from which the CAT may receive data per the CAT NMS Plan, such as the Securities Information Processors (SIPs).
-The CAT NMS Plan also requires the selection of an entity as the Plan Processor to be responsible for performing the processing functions required by Rule 613 and the Plan. The Operating Committee of CAT NMS LLC, a governing body composed of representatives of the Participants, oversees the operation of the CAT. The duties of the Operating Committee are further described in Article IV of the CAT NMS Plan.
-Refer to SEC Rule 613, available at: https://www.sec.gov/rules/final/2012/34-67457.pdf for more details. Refer also to CAT NMS Plan, available at: https://www.catnmsplan.com/wpcontent/uploads/2018/02/34-79318-exhibit-a.pdf
-pubdate: February 28, 2019 effdate: N/A
- 2. CAT Reporting Fundamentals
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals
- Compliance User: Industry Members
- Keywords:
- Industry Member,
-
- pubdate: February 28, 2019 effdate: N/A
- 2.1. Industry Member Perspective
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Industry Member Perspective
- Compliance User: Industry Members
- Keywords:
- Industry Member,
- New Order,
- Order Accepted,
-
- Industry Members should populate fields from their own perspective. For example, for “capacity”, the Industry Member should report based on the capacity in which the Industry Member acted. For a New Order and Order Accepted, reports should indicate the instructions as received; for an Order Route, the fields should include the instructions as sent to the destination.
-pubdate: February 28, 2019 effdate: N/A
- 2.2. Key Data Elements
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Key Data Elements
- Compliance User: Industry Members
- Keywords:
- Elements of CAT,
-
- The sections below describe the key data elements of CAT that may be used in order events and/or metadata files.
-pubdate: February 28, 2019 effdate: N/A
- 2.2.1. Reporter ID and Submitter ID
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Key Data Elements, Reporter ID and Submitter ID
- Compliance User: Industry Members
- Keywords:
- Reporter ID,
- Submitter ID,
- CAT Reporting Agents,
-
- Two CAT identifiers, the Reporter ID and the Submitter ID, i.e., CAT Reporting Agent, are used during the CAT file submission process to identify the Industry Member and, if applicable, the party authorized to submit CAT files on behalf of the Industry Member (CAT Reporting Agent).
-Reporter ID
-The CAT Reporter ID is the SRO assigned identifier that an Industry Member used to report order events to CAT. A CAT Reporter may use any SRO assigned identifier that is valid on the CAT Trading Day for which order events are submitted. CAT will use reference data submitted by Participant Reporters each day to identify the Industry Member to which the specific identifier is assigned. Each SRO assigned identifier is linked to the Industry Member's CRD number so that all reporting activity of a single Industry Member CAT reporter can be consolidated at the firm level in CAT.
-Submitter ID
-The Submitter ID is the identifier of the CAT Reporting Agent, the entity authorized to submit the files to CAT on behalf of the Industry Member. CAT Reporters may authorize third-parties (“CAT Reporting Agents”) to submit data to CAT on their behalf. The CAT Reporting Agent must be authorized to submit data on behalf of the Reporter. Each CAT Reporting Agent will be assigned a unique Submitter ID by CAT during onboarding. If an Industry Member submits data on its own behalf, then the Submitter ID assigned to the entity may be the same as the CAT Reporter ID.
-pubdate: February 28, 2019 effdate: N/A
- 2.2.2. Order ID
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Key Data Elements, Order ID
- Compliance User: Industry Members
- Keywords:
- Order ID,
-
- The order ID used in order events, representing the internal order IDs assigned by the Industry Member, must be unique when combined with the date, reporter and symbol (or optionID).
-pubdate: February 28, 2019 effdate: N/A
- 2.2.3. Timestamps
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Key Data Elements, Timestamps
- Compliance User: Industry Members
- Keywords:
- Manual Order Events,
- Industry Members,
- Alternative Trading systems,
- Member Data,
-
- Each Industry Member must record and report Industry Member Data to the CAT with timestamps in milliseconds. However, to the extent that any Industry Member’s order handling or execution systems utilize timestamps in increments finer than milliseconds, such Industry Member must record and report Industry Member Data to the CAT with timestamps in such finer increments. CAT will accept granularity up to nanoseconds. Each Industry Member may record and report Manual Order Events to the CAT in increments up to and including one second, provided that each Industry Member shall record and report the time when a Manual Order Event has been captured electronically in an order handling and execution system of such Industry Member (“Electronic Capture Time”) in milliseconds. Each Industry Member may record and report the time of Allocation Reports in increments up to and including one second.
-There are two timestamps fields in each event - eventTimestamp and electronicTimestamp. The eventTimestamp is the time of order handling or execution pursuant to Section 6.8 of the CAT NMS Plan (e.g. origination, receipt, etc, depending on the respective order event). For manual order handling, eventTimestamp is the manual handling or execution time, which is required to be reported in increments of at least one second. When the manual order is later captured electronically, the systematized time must be captured in the electronicTimestamp field.
-With respect to sequence numbers, Alternative Trading Systems (ATSs) must provide a sequence number assigned by the ATS’s matching engine on all Reportable Events.
-pubdate: February 28, 2019 effdate: N/A
- 2.2.4. Order Types
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Key Data Elements, Order Types
- Compliance User: Industry Members
- Keywords:
- Data Dictionary,
-
- CAT uses a standardized list of order types for Industry Members that can be found in the Data Dictionary. All events with the field orderType will require one of these standard order types as a value.
-For events reported by ATSs, an additional field (in addition to orderType) - atsOrderType - is used to capture ATS-specific order types. Please see Section 3.1.2 ATS Order Types for more details.
-Please note that brokers routing to ATSs are not required to use the atsOrderType field, nor the ATS specific codes in the standardized orderType field in their Order Route events. The orderType on the Order Route event will not be validated against an atsOrderType.
-pubdate: February 28, 2019 effdate: N/A
- 2.2.5. Order Handling Instructions
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Key Data Elements, Order Handling Instructions
- Compliance User: Industry Members
- Keywords:
- RAR,
- New Order,
- Order Accepted,
-
- Special handling instructions are reported in the handlingInstructions field using a standardized list of handling instructions based on common exchange order types and codes. Multiple codes and values can be used in combination to describe the special handling instructions.
-In the event an Industry Member routes an order with exactly the same handling instructions received from the customer, they may use handlingInstructions code "RAR" (Routed as Received) on the Order Route event rather than re-stating all handlingInstructions values from the New Order/Order Accepted event.
-pubdate: February 28, 2019 effdate: N/A
- 2.3. Reference Data
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data
- Compliance User: Industry Members
- Keywords:
- IMID,
-
- pubdate: February 28, 2019 effdate: N/A
- 2.3.1. Industry Member Identifier (IMID)
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data, Industry Member Identifier (IMID)
- Compliance User: Industry Members
- Keywords:
- Industry Member Identifier,
- CHX Acronyms,
- FINRA,
- MPIDs,
- Nasdaq MPIDs,
- SRO,
-
- An Industry Member Identifier, IMID, is any identifier assigned by an SRO to one of its members. Examples of SRO assigned identifiers include FINRA MPIDs, Nasdaq MPIDs, NYSE Mnemonics, CBOE User Acronyms, and CHX Acronyms.
-Reportable events will use fields with the Data Type "IMID" to refer to the Industry Member performing the action described by the event, and/or the entity that is the subject of the action described by the event. In other words, an IMID type field will be used in all scenarios where an Industry Member must refer to themselves or another Industry Member in an event.
-This IMID approach allows the Industry Member to use any SRO-Assigned Industry Member Identifier in the Reportable Events. Acknowledging the potential that the same SRO-assigned Industry Member Identifier may be used by different SRO for different entities, CAT will publish a daily file to highlight any conflict among the SRO-assigned Industry Member Identifiers. Such conflicts are detected in the processing of the daily member dictionaries submitted by each SRO. If a conflict is identified for a specific IMID, the Industry Member may choose to use either the SRO-Assigned Industry Member Identifier by another SRO that is not conflicted with other IDs, or the full format of the IMID - the combination of source (issuing SRO) and the SRO-Assigned Industry Member Identifier - to guarantee uniqueness of the IMID. For example, if AAAA is conflicted with another SRO-Assigned Market Participant Identifier in the CAT, the alternative can be to either use a different SRO-Assigned Market Participant Identifier assigned by another SRO (e.g., AAAB, pointing to the same Industry Member), or the full format FINRA:AAAA - a combination of ID and the source SRO.
-pubdate: February 28, 2019 effdate: N/A
- 2.3.2. Firm Designated ID (FDID)
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data, Firm Designated ID (FDID)
- Compliance User: Industry Members
- Keywords:
- FDID,
- CAT NMS plan,
- CAT Interpretative FAQ,
-
- FDID is defined in Section 1.1 of the CAT NMS Plan as “a unique identifier for each trading account designated by Industry Members for purposes of providing data to the Central Repository, where each such identifier is unique among all identifiers from any given Industry Member for each business date.”
-FDID represents an account and not a specific customer. For example, John Doe has two accounts at BDA, a regular trading account (account #124) and an IRA account (account #456). BDA would have two different FDIDs in this case, one for John Doe's regular trading account and a second for John Doe's IRA account.
-The FDID for the trading account an order was received or originated for must be reported on all New Order Events.
-Unless a new account or entity identifier is assigned to a client or customer, each FDID must be unique and persistent for each trading account on any given day so that a single account may be tracked across time within a single broker-dealer. For example, if an Industry Member assigns a new account or entity identifier to a client or customer for any reason, such as due to a merger, acquisition or some other corporate action, then a new FDID may be created to identify the new account identifier/entity identifier in use at the Industry Member for the entity
-An actual account may not be used as the FDID for CAT reporting. See CAT Interpretive FAQ M2 for more information on the prohibition on use of actual account numbers.
-pubdate: February 28, 2019 effdate: N/A
- 2.3.3. Equity Symbols
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data, Equity Symbols
- Compliance User: Industry Members
- Keywords:
- Reportable Events,
- Eligible Securities,
- FINRA OTC Symbology,
-
- Industry Members must report Reportable Events related to listed equity Eligible Securities to CAT using the symbology of the primary listing exchange and must report Reportable Events related to OTC Equity Securities using FINRA OTC symbology.
-pubdate: February 28, 2019 effdate: N/A
- 2.3.3.1. CAT Symbol Master
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data, Equity Symbols, CAT Symbol Master
- Compliance User: Industry Members
- Keywords:
- Symbol,
-
- CAT will provide a start-of-day equity symbol master list at 6:00AM and an end-of-day equity symbol master list each day on www.catnmsplan.com.
-The symbol master file for Industry Members contains the following information:
-• the listing exchange,
-• the symbol in the symbology of the listing exchange, and
-• a flag indicating whether the symbol is a test symbol.
-pubdate: February 28, 2019 effdate: N/A
- 2.3.4. Option Symbols
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data, Option Symbols
- Compliance User: Industry Members
- Keywords:
- CAT NMS plan,
- CAT Symbology,
-
- As stated above, the CAT NMS Plan requires symbols to be reported to CAT in the symbology of the listing exchange. Standard option symbols established across exchanges as the result of the Option Symbology Initiative (OSI) should be used for any single-leg listed options.
-pubdate: February 28, 2019 effdate: N/A
- 2.3.4.1. Flex Percent Option Symbols
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data, Option Symbols, Flex Percent Option Symbols
- Compliance User: Industry Members
- Keywords:
- Flex Percent Options,
- CAT System,
-
- FLEX Percent options can only be uniquely identified using the OSI once their deterministic prices are known. When reporting the optionID for a FLEX Percent option, Industry Members must append "%" to the beginning of the standard OSI symbol. This will enable the CAT system to differentiate between a strike value that is expressed in percent terms from one that is expressed in dollars and cents.
-Thus, FLEX Percent option symbols expressed with percentage strike values will have 22 characters. For example, an option order with optionID %1AAPL 200131C00095000 indicates it is a Flex Percent option order on OSI symbol 1AAPL 200131C00095000.
-pubdate: February 28, 2019 effdate: N/A
- 2.3.5. Corporate Actions
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data, Corporate Actions
- Compliance User: Industry Members
- Keywords:
- Central Repository,
- FINRA OTC Equity Symbols,
- Data Distribution Service,
- Industry Members,
-
- The CAT System will maintain a historical symbology in the Central Repository that includes corporate actions.
-CAT will receive daily corporate action files and symbol updates from the various data sources (including equity and options listing exchanges, FINRA OTC Equity Symbols, Data Distribution Services from Options Clearing Corporation, etc.) and publish daily symbol master files to the Industry Members. The symbol changes impacted by corporate actions will be reflected in the daily symbol master files. Industry Members must use the updated symbol in Reportable Events from the effective date of the symbol change. Failure to report in the updated symbol would result in rejects of the record(s).
-Industry Members are not required to report order adjustments due to corporate actions, e.g., price or size changes. However, if an Industry Member chooses to report an adjustment resulting from a corporate action, the adjustment should be reported using the Order Modified event (or Order Adjusted event).
-pubdate: February 28, 2019 effdate: N/A
- 2.3.5.1. Options Intraday Listing or Delisting
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Reference Data, Corporate Actions, Options Intraday Listing or Delisting
- Compliance User: Industry Members
- Keywords:
- CAT,
- Industry Members,
-
- CAT accommodates intraday listing of options by exchanges. Industry Members must report the OSI symbol as the optionID, just like for previously listed options.
-CAT will maintain a historical record of option symbols, including symbols that have been delisted.
-Exchanges and the OCC will provide reference data to CAT for option symbols that are listed or delisted intraday.
-pubdate: February 28, 2019 effdate: N/A
- 2.4. Data Types
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Data Types
- Compliance User: Industry Members
- Keywords:
- CAT,
- Data Validation,
- Reporter Submitter,
- Data Submitted,
- Industry Members,
- JSON,
- CSV,
- SRO,
-
- CAT will accept two kinds of text-based files: JSON and CSV. The fundamental data types used throughout this document are described below. Other data types are defined in the Data Dictionary provided in Appendix G of this document.
-To support both JSON and CSV submissions, CAT will publish a JSON schema file on the CAT public website that describes each data type with required representation formats and a mapping that defines the position in a CSV representation that the data element would assume. A schema will be provided for each data object that can be reported in both JSON and CSV.
-Data Validation Based on Data Types
-All data submitted to CAT will be validated based on the defined data type of each item, including proper formatting and range checking. Examples of accepted values are detailed in the table below. Valid values for Choice fields are defined in the Data Dictionary for each data element. Valid data values, ranges, and formats will be specified in the record schema files, which will be used to validate submitted data element values. Records and values that fail validation will be marked as a failure and will be reported as feedback to the Reporter and Data Submitter as detailed in Section 7.
-Data Types
-
-
-
-
-
- pubdate: February 28, 2019 effdate: N/A
- 2.4.1. Name/Value Pairs
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Data Types, Name/Value Pairs
- Compliance User: Industry Members
- Keywords:
- Name Part,
- Value Part,
- JSON,
- CSV,
-
- Some fields are described as containing Name/Value pairs. This signifies a list of zero or more attributes, where each attribute is either a name with no value, or a name with an accompanying value such that the name and value are separated by a single equal sign (ASCII decimal 61, hex 3D). Multiple attributes, i.e., Name/Value Pairs, are separated by the pipe symbol (ASCII decimal 124, hex 7C). If an attribute is boolean in nature, it can optionally be represented as a name alone, where its value is implied by its presence (true) or absence (false).
-The Name part is the string up to the first pipe symbol or equal sign. Names must not contain commas (ASCII 44, hex 2C), pipes, equal-signs, or double-quotes (ASCII decimal 34, hex 22). If the name terminates with a pipe, it is a boolean value, and its presence indicates true. If the name terminates with an equal sign, the value must follow.
-The Value part is the string starting with the character just after the equal sign, up to either a pipe symbol or the end of the string. Values may contain an equal sign, but must not contain commas, pipes or double-quotes.
-For example, the following JSON represents a hypothetical name/value pair field, with a boolean attribute and a price attribute: { "data": "XYZ|ABC=12.55" }
-The above format works for both JSON and CSV data entry. However, when submitting data in JSON, a more native JSON style can optionally be used by assigning a JSON object as the value for a Name Value Pair attribute. Note, however, that boolean values must be explicitly set. The above example can alternatively be submitted as:
-{ "data": { "XYZ": true, "ABC": 12.55 } }
-pubdate: February 28, 2019 effdate: N/A
- 2.4.2. Required, Conditional, and Optional Fields
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Data Types, Required, Conditional, and Optional Fields
- Compliance User: Industry Members
- Keywords:
- Throughout this document, event types and their fields will be defined. Each field will be notated with the abbreviation R, C, O or A to represent whether it is required, conditionally required, optional or required for ATSs only. This codification will appear in the last column of each table describing an event.
-
- pubdate: February 28, 2019 effdate: N/A
- 2.5. Linkage Overview
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Linkage Overview
- Compliance User: Industry Members
- Keywords:
- CAT,
-
- This section describes the linkage keys that are used to create lifecycles in CAT and explains how the linkage keys are constructed via different data elements in respective Reportable Events.
-pubdate: February 28, 2019 effdate: N/A
- 2.5.1. CAT Linkage Keys
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Linkage Overview, CAT Linkage Keys
- Compliance User: Industry Members
- Keywords:
- CAT,
- Industry Members,
-
- All Reportable Events will be linked in CAT via the daisy chain approach. Below is the list of linkage keys that connect order events within an Industry Member and across Industry Members.
-• Order Key links together the events of the same order, within an Industry Member, e.g. linking an Order Route event to the Order Accepted event. The Order Key is constructed by date, reporter, symbol (or optionID) and orderID.
-• Prior Order Key links together the modified, cancel/replaced or internally routed order to the original order. For example, linking an Order Modified event to the Order Accepted event. Generally, the data elements to construct the Prior Order Key are date, reporter, symbol (or optionID), priorOrderID. However, the field names may vary depending on the order events. Please see each order events sections for more details.
-• Route Linkage Key links the order events by the Industry Member routing an order away and the Industry Member accepting the order. Please see Section 2.5.2 below for more detailed descriptions.
-• Trade Key: Each Trade event has a Trade Key (date, reporter, symbol (or optionID), tradeID), and each side of the trade has an Order Key that links to the order on side.
-• Fulfillment Key: date, reporter, symbol (or optionID), fulfillmentID
-• Prior Fulfillment Key: date, reporter, symbol (or optionID), priorFulfillmentID
-• Quote Key: date, reporter, symbol, quoteID
-Generally, the date used in the linkage key is the calendar date of the event (the date portion of the eventTimestamp). In the scenario when an order event needs to be linked to a prior event on a different date (e.g., modify a GTC order on a prior day), an additional field priorOrderDate is reported on the event and will be used in linking.
-pubdate: February 28, 2019 effdate: N/A
- 2.5.2. Reporting Responsibilities of Sender/Receiver in Order Route
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Linkage Overview, Reporting Responsibilities of Sender/Receiver in Order Route
- Compliance User: Industry Members
- Keywords:
- CAT,
- Industry Members,
- OATS,
-
- In Phase 2a, Industry Members are responsible for reporting routes, modifications, and cancellations in line with OATS guidance. Below are a list of sample scenarios and the reporting responsibilities of the sender (Broker A) and the receiver (Broker B).
-
-
- pubdate: February 28, 2019 effdate: N/A
- 2.5.3. Summary of Route Linkage Keys
-Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Linkage Overview, Summary of Route Linkage Keys
- Compliance User: Industry Members
- Keywords:
- CAT,
- Industry Members,
-
- The table below summarizes the required data elements to construct the route key for linking Route and Order Accepted events reported by different entities in CAT. The combination of the data elements must be unique. Data elements in the same row must always be equal values. Note that only the data elements used to create linkage are listed here.
-For Participant related event details, please refer to the CAT Reporting Technical Specifications for Participants.
-
-
- * Not required for manual order route/receipt.
-• session - The session field contains an ID string for the specific session used to route the order. Note that this differs from the trading session (e.g., pre-market, regular, post-market, etc.) Session can constitute an actual protocol session name, IP/port combination, unique login account, or some other means of identifying a particular API session. It must be reported as the same value by both the sending and receiving entities. When routing between two Industry Members, the session must be left blank by both the sending and receiving entities.
-• routedOrderID - When an order is routed away, it may be assigned another ID on the route - this is noted in the Order Route event as the routedOrderID (e.g., the ClOrdID in FIX, ClientOrderID for NYSE UTP direct users, etc). This ID must match the routedOrderID reported by the receiving entity in its Order Accepted event.
-Routing Between Industry Members
-For orders routed between Industry Members, the linkage between sender and receiver is established via a combination of:
-- Date, symbol (or optionID), session (must be blank), destination, senderIMID, and routedOrderID on the Order Route events reported by the sender; and
-- Date, symbol (or optionID), session (must be blank), receiverIMID, routingOrigin, and routedOrderID on Order Accepted event reporter by the receiver.
-• destination - The IMID of the destination receiving this routed order. It must equal the receiverIMID field on the Order Accepted event reported by the destination Industry Member. The sending and receiving firms must mutually agree on the IMID to be used if they have multiple SRO-assigned IMIDs.
-• senderIMID - The IMID of the sender that is routing out the order, known also by the destination. The destination has to report the same value on the routingOrigin field of the Order Accepted event.
-• receiverIMID - The IMID of the Industry Member receiving the routed order. It must match the destination field on the Order Route event reported by the sender.
-• routingOrigin - The IMID of the Industry Member from which the order is routed. It must match senderIMIDin the Order Route event reported by the routing entity.
-Routing to Exchanges
-When routing to exchanges, the destination must be the Exchange ID to which the order is routed. Hence, the linkage will be created by:
-- Date, symbol (or optionID), session, destination (ExchangeID), senderIMID, and routedOrderID on the Order Route event; and
-- Date, symbol (or optionID), session, exchange, routingParty, and routedOrderID on the Participant Order Accepted event to create linkages. See CAT Reporting Technical Specifications for Participants for more details.
-Note that, when using Order Route event to report a modification to an order that was previously routed to an exchange, the linkage key is created via the same set of data elements.2
-Routing to Foreign Destinations
-If the order is routed to a foreign non-CAT-reporting entity, the destinationType must be marked as N (Foreign). However, there is no requirement to report destination or routedOrderID, thus there is no subsequent linkage in CAT.
-Routing from an Exchange to the Exchange's Routing Broker
-When an Industry Member, that is an exchange routing broker, receives an order routed from the exchange, the routingOrigin field must be the Exchange ID from which the order is routed. Hence the linkage will be created by:
-- Date, symbol (or optionID), exchange, routedOrderID, session, routingParty on the Participant Order Route event (See CAT Reporting Technical Specifications for Participants for more details);
-- Date, symbol (or optionID), routingOrigin (Exchange ID), routedOrderID, session, receiverIMID on the Industry Member Order Accepted event.
-pubdate: February 28, 2019 effdate: N/A
- 3. Special Reporting Requirements
-Topic: CAT Reporting Technical Specifications for Industry Members, Special Reporting Requirements
- Compliance User: Industry Members
- Keywords:
- pubdate: February 28, 2019 effdate: N/A
- 3.1. Alternative Trading Systems (“ATSs”) Reporting
-Topic: CAT Reporting Technical Specifications for Industry Members, Special Reporting Requirements, Alternative Trading Systems (“ATSs”) Reporting
- Compliance User: Industry Members
- Keywords:
- ATSs,
-
- ATSs are required to submit additional information in applicable order events.
-pubdate: February 28, 2019 effdate: N/A
- 3.1.1. National Best Bid and Offer (NBBO)
-Topic: CAT Reporting Technical Specifications for Industry Members, Special Reporting Requirements, Alternative Trading Systems (“ATSs”) Reporting, National Best Bid and Offer (NBBO)
- Compliance User: Industry Members
- Keywords:
- ATSs,
- Industry Members,
- CAT,
- NBBO,
- BBO,
-
- ATSs are required to report to CAT NBBO prices, though such information is optional for other Industry Members. The quantities being bid or offered for the NBBO are optional for all Industry Members.
-The NBBO should be reported to CAT from the perspective of the Industry Member. An ATS is required to report, for orders, the NBBO (or relevant reference price) in effect at the time of the order event, and the timestamp of when the ATS captured the effective NBBO (or relevant reference price). In addition, the ATS must identify the market data feed (NBBO Source) it used to obtain the NBBO (or relevant reference price).
-If another reference price, such as the primary market's BBO, is used by the ATS, then the applicable reference price should be reported instead of the NBBO.
-pubdate: February 28, 2019 effdate: N/A
- 3.1.2. ATS Order Types
-Topic: CAT Reporting Technical Specifications for Industry Members, Special Reporting Requirements, Alternative Trading Systems (“ATSs”) Reporting, ATS Order Types
- Compliance User: Industry Members
- Keywords:
- ATSs,
- CAT,
-
- For events reported by ATSs, an additional field (in addition to orderType) - atsOrderType - is used to report ATS-specific order types. Note that orderType and atsOrderType are not mutually exclusive; ATSs must populate both of these fields with a value where they are present on Reportable Events.
-The field atsOrderType is defined as Name/Value Pairs where "name" must be equal to a unique code that has been provided to CAT by the ATS through the CAT web interface. All codes must be registered before any relevant order events are submitted. Specific instructions for registering atsOrderTypes will be published in a CAT Alert available on catnmsplan.com. All atsOrderTypes must be registered with CAT 20 business days prior to the order type becoming effective.
-pubdate: February 28, 2019 effdate: N/A
- 3.1.3. Sequence Number
-Topic: CAT Reporting Technical Specifications for Industry Members, Special Reporting Requirements, Alternative Trading Systems (“ATSs”) Reporting, Sequence Number
- Compliance User: Industry Members
- Keywords:
- ATSs,
-
- Alternative Trading Systems (ATSs) must also provide a sequence number assigned by the ATS’s matching engine on all reportable events.
-pubdate: February 28, 2019 effdate: N/A
- 3.2. Manual Orders
-Topic: CAT Reporting Technical Specifications for Industry Members, Special Reporting Requirements, Manual Orders
- Compliance User: Industry Members
- Keywords:
- CAT,
- NMS Plan,
-
- The CAT NMS Plan defines a Manual Order Event as “non-electronic communication of order-related information for which CAT Reporters must record and report the time of the event.” This version of the Technical Specifications addresses manual equity orders, which are reportable in Phase 2a, while manual option orders will be addressed in the Phase 2d Technical Specifications.
-pubdate: February 28, 2019 effdate: N/A
- 3.2.1. Manually Received Order Events Immediately Systematized
-Topic: CAT Reporting Technical Specifications for Industry Members, Special Reporting Requirements, Manual Orders, Manually Received Order Events Immediately Systematized
- Compliance User: Industry Members
- Keywords:
- Industry Members,
-
- Orders which are non-electronically communicated but immediately systematized (e.g., a broker received a call and directly enters the order into the order management system) must be marked as a manual event using the manualFlag. In this scenario, 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.3
-pubdate: February 28, 2019 effdate: N/A
- 3.2.2. Manual Order Events Followed by Separate Electronic Messages
-Topic: CAT Reporting Technical Specifications for Industry Members, Special Reporting Requirements, Manual Orders, Manual Order Events Followed by Separate Electronic Messages
- Compliance User: Industry Members
- Keywords:
- Manual order event,
- CAT,
- Industry Members,
-
- Manual order events must be reported to CAT marked as a manual event using the manualFlag and must include an electronic capture time if the manual event is captured in an order management or execution system.
-If an Industry Member routes or receives an order manually and then subsequently sends or receives an electronic message to represent the manual instruction, the following reporting requirements apply:
-• All material terms and conditions of a manually received or routed order, including time of route and receipt, must be reported to CAT on the required manual event, with all relevant timestamps representing when the manual order event occurred.
-• Additional electronic messages related to a manual order or route that do not change any material term or condition of the original order are not required to be reported to CAT as they represent a duplicate of the original order.
-• If the duplicate electronic message includes a routed order identifier that could be used to link the sender's route report to the receiver's new order, and the member has the ability to include this electronic information on the manual event (referred to as a "merged" event), the Industry Member should do so.
-• If the Industry Member is not able to merge the manual and electronic information in a single manual event and elects to report the duplicate electronic message independently, such messages must be reported with the electronicDupFlag = true. Further, the manualOrderID may be populated with the Order ID of the original manual order. This is optional in Phase 2a, but will be mandatory in Phase 2c.
-No linkage will be attempted for electronic duplicate events in Phase 2a.
-pubdate: February 28, 2019 effdate: N/A
- 4. Equity Events
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events
- Compliance User: Industry Members
- Keywords:
- Equity Events,
- SROs,
- Industry Members,
- ATS,
- Agency Order Crosses,
-
- This section describes Reportable Events for equities that are Eligible Securities. The following table lists each equity event type with its corresponding Message Type code.
-Events and data elements that are greyed out do not apply to Phase 2a.
-Equity Events
-
-
- pubdate: February 28, 2019 effdate: N/A
- 4.1. New Order Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, New Order Event
- Compliance User: Industry Members
- Keywords:
- Industry Members,
- CAT,
- New customer orders,
- Representative orders,
- Proprietary orders,
- non-reporting foreign broker-dealer,
- ATS,
-
- An Industry Member must report a New Order event to CAT when an order is received or originated. This includes:
-• New customer orders4
-• Representative orders5
-• Proprietary orders
-• Order(s) received from a non-reporting foreign broker-dealer or affiliate.
-Note that an order received from another CAT Reporter (US broker-dealer, ATS or an exchange) must be reported as an Order Accepted event.
-Phase 2a Representative Orders
-In Phase 2a, linkage is required between the representative street-side order and the customer order or client order being represented when the representative order was originated specifically to represent a single order and there is:
-• An existing direct electronic link in the Industry Member’s system between the order being represented and the representative order, and
-• Any resulting executions are immediately and automatically applied to the represented order in the Industry Member’s system.
-Phase 2c Representative Orders
-Any scenario that does not meet the definition of Phase 2a representative order will fall into this category. The Industry Member must report a New Order event for the creation of the representative order in Phase 2a and flag the New Order event properly to indicate that it is a representative order. It is not mandatory to report the linkage to the underlying orders (the aggregatedOrders field) until Phase 2c.
-Appendix C contains detailed descriptions of representative order scenarios and illustrates when marking of the representative order, linkage between the represented order and the representative order, and Order Fulfillment linkage is required in each phase.
-The representativeInd is used to show whether an order is originated to represent a customer/client order and whether the linkage is present. It is required for all New Order events.
-Note that all fields and values necessary to support Phase 2c linkages are included in this version of the specification and Industry Member Reporters may voluntarily report these linkages prior to the start of Phase 2c.
-New Order Event Field Specifications
-
-
-
- Linkage keys for this Reportable Event:
-• Order Key: date, reporter, symbol, orderID
-• Quote Key: date, reporter, symbol, quoteID (if applicable)
-• Order Key: date, reporter, symbol, aggregatedOrders.Name
-pubdate: February 28, 2019 effdate: N/A
- 4.2. New Order Supplemental Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, New Order Supplemental Event
- Compliance User: Industry Members
- Keywords:
- Supplement Event,
- Name/Value Pairs,
- CAT,
-
- The Supplement Event serves as a supplement to the New Order event. This event accommodates reporting in two scenarios:
-1) When the number of Name/Value pairs included under the aggregatedOrders field causes the New Order event to exceed the maximum allowed message length. Generally, this includes scenarios where so many orders are being aggregated together in a New Order that the number of Name/Value Pairs included in the field aggregatedOrders causes the message to exceed the allowed length.
-2) When there is no explicit linkage to disparate orders when a representative order is generated. This supplement event can be used to capture the relationship of representative and disparate orders and submitted to CAT separately as an addition to the original New Order event.
-This event can be submitted in the same file as the original New Order event or in a separate file, so long as it is submitted on the same date as the New Order event. One New Order event can have multiple New Order Supplement events. Multiple New Order Supplement events are considered as additions (not replacements or modifications). The aggregatedOrders field in the New Order Supplement event should only contain the additional Name/Value Pairs that have not been captured in the original New Order event (or another Supplement event for the same New Order).
-New Order Supplement Event Field Specifications
-
- Linkage keys for this Reportable Event:
-• Order Key: date, reporter, symbol, orderID
-• Order Key: date, reporter, symbol, aggregatedOrders.Name
-pubdate: February 28, 2019 effdate: N/A
- 4.3. Order Route
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Route
- Compliance User: Industry Members
- Keywords:
- Industry Member,
- foreign broker-dealer,
- Exchanges,
- FINRA,
- SEC Rule 201,
- ATS,
-
- An Industry Member must report to CAT an Order Route event when:
-• Routing to another Industry Member
-• Routing to foreign broker-dealers
-• Routing to exchanges
-• Routing between two IMIDs (e.g. two different FINRA MPIDs) attributed to the same legal entity (i.e. the same CRD)
-• Routing partial quantities of an order (assigned using routedOrderID in routing message)
-In order to maintain order lifecycle linkage, the orderID populated in the Order Route event must reflect any changes made to the orderID internally by the broker before routing the order. If, for example, an order was subject to a Cancel/Replace that changed the Order ID, then the value used for orderID in an Order Route event must reflect those changes - in other words, the most recent orderIDis used to reference the order.
-Handling Instructions on the Order Route
-The handling instructions included in this event should represent those on the routed order. If the handling instructions do not change from the Order Accepted or New Order associated with the order, Industry Members may use the handling instruction code "RAR" - routed as received, instead of repeating each individual handling instruction.
-Notes
-• Please note that internal routes to another desk or department within an Industry Member are not reported using the Order Route event; instead an Order Internal Route event is used. See the Order Internal Route section for more details.
-Order Route Event Field Specifications
-
-
-
- Linkage keys for this Reportable Event:
-• Order Key: date (from eventTimestamp if priorOrderDate is not present), reporter, symbol, orderID
-• Order Key: priorOrderDate (when present), reporter, symbol, orderID
-• Route Link Key: date, senderIMID, destination, symbol, session, routedOrderID
-pubdate: February 28, 2019 effdate: N/A
- 4.3.1. Order Modify Route (Potential Phase 2c Event)
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Route, Order Modify Route (Potential Phase 2c Event)
- Compliance User: Industry Members
- Keywords:
- SRO,
-
- <Deferred – event not required for Phase 2a or Phase 2b. SROs will evaluate need for a modified route event after reviewing Phase 2a/2b data and include event in Phase 2c, if necessary.>
-pubdate: February 28, 2019 effdate: N/A
- 4.3.2. Order Cancel Route (Potential Phase 2c Event)
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Route, Order Cancel Route (Potential Phase 2c Event)
- Compliance User: Industry Members
- Keywords:
- SRO,
-
- <Deferred – event not required for Phase 2a or Phase 2b. SROs will evaluate need for a canceled route event after reviewing Phase 2a/2b data and include event in Phase 2c, if necessary.>
-pubdate: February 28, 2019 effdate: N/A
- 4.4. Order Accepted
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Accepted
- Compliance User: Industry Members
- Keywords:
- CAT Reporter,
- Industry Member,
- ATS,
- CAT,
- foreign broker-dealer,
- FINRA,
- Equity Securities,
- FINRA Rule 5320.02,
- NBBO,
-
- When an Industry Member receives a routed order from another CAT Reporter (i.e., Industry Member, ATS or exchange), then an Order Accepted event must be reported to CAT by the Industry Member receiving the routed order. As described in Order Route event, if an Industry Member accepts a routed order from another IMID belonging to the same Industry Member, i.e., the same CRD, an Order Accepted event must be reported.
-Once all Industry Members are reporting to CAT, in all cases, the order reported with this event should have already been originated by another broker and reported upon origination with a New Order event. A New Order event represents the beginning of the order lifecycle in CAT, therefore a new customer order is represented with a New Order event - not an Order Accepted event. Similarly, orders received by an Industry Member from its non-broker-dealer affiliates or from a non-reporting foreign broker-dealer should be reported as a New Order event - NOT an Order Accepted event. (Note: At the start of Phases 2a and 2b, there will be some lifecycles beginning at Order Accepted event, as small Industry Members will not be required to report until a later phase).
-Order Accepted Field Specifications
-
-
-
- Linkage keys for this Reportable Event:
-• Order Key: date, reporter, symbol, orderID
-• Route Link Key: date, senderIMID, destination, symbol, session, routedOrderID
-pubdate: February 28, 2019 effdate: N/A
- 4.5. Order Internal Route
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Internal Route
- Compliance User: Industry Members
- Keywords:
- Industry Member,
- Order Accepted Event,
- New Order event,
- Child Order event,
- CAT,
-
- An Order Internal Route event must be reported when an order is passed to different departments or desks within the reporterIMID.
-Although multiple reporterIMIDs may be attributed to a single Industry Member, routes between different IMIDs attributed to the same Industry Member are not considered internal routes.
-Note that an Order Internal Route event does not follow the logic of sending / receiving two-sided reporting followed throughout the rest of these Industry M ember Technical Specifications. It is required to be reported from the perspective of the recipient desk. The Order Internal Route merely shows that an order was received by an internal destination and if a new orderID has been assigned to the order as a result of this Order Internal Route.
-• Order Internal Route may also represent the routing of partial quantities of an order internally, and the practice of assigning those slices new orderIDs. In this case, multiple internal routes may occur on the same original orderID reported in an Order Accepted event or New Order event. Similarly, if an order is routed internally and then subsequently multiple slices are routed to yet another destination internally, this event should represent the receiving desk, quantities, and new orderIDs of those routed slices as received by the subsequent internal destination. This approach will allow CAT to track changes in orderID within an Industry Member as an order is passed between internal entities or partial quantities are routed to internal entities as slices of another order.
-• The major difference between Order Internal Route and Child Order events is that Child Order event can only be used when no desk change or desk route happens. For example, some Industry Members may choose to first generate child orders using the Child Order event to represent slices of a parent order, then to route those slices internally to another desk (Order Internal Route event). This approach is also acceptable for CAT reporting and will not result in unlinked events.
-Order Internal Route Modified and Order Internal Route Canceled are not required to be reported until Phase 2c.
-pubdate: February 28, 2019 effdate: N/A
- 4.5.1. Order Internal Route
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Internal Route, Order Internal Route
- Compliance User: Industry Members
- Keywords:
- FINRA,
- OTC Equity Securities,
- FINRA Rule 5320.02,
-
- Order Internal Route event is used to report routing within a reporterIMID as described above.
-Internal Route Field Specifications
-
-
-
- Linkage keys for this Reportable Event:
-• Order Key: date, reporter, symbol, orderID
-• Prior Order Key: date, reporter, symbol, priorOrderID
-pubdate: February 28, 2019 effdate: N/A
- 4.5.2. Order Internal Route Modified (Phase 2c)
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Internal Route, Order Internal Route Modified (Phase 2c)
- Compliance User: Industry Members
- Keywords:
- <Deferred - Not Required Until Phase 2c>
-pubdate: February 28, 2019 effdate: N/A
- 4.5.3. Order Internal Route Canceled (Phase 2c)
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Internal Route, Order Internal Route Canceled (Phase 2c)
- Compliance User: Industry Members
- Keywords:
- <Deferred - Not Required Until Phase 2c>
-pubdate: February 28, 2019 effdate: N/A
- 4.6. Child Order
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Child Order
- Compliance User: Industry Members
- Keywords:
- CAT,
- Industry Members,
- Child Order event,
- FDID,
-
- CAT provides several ways to report parent/child order activity. The Child Order event is provided solely for the convenience of Industry Members to help model scenarios in which an order is split or sliced into smaller "child" orders that are handled independently of their parent order - in a way that best reflects each individual Industry Member’s system(s).
-For example, in the scenario when Industry Members create independent child orders with new orderIDs, if the Child Order event is reported, then the changes of order IDs are captured. Afterwards, the Industry Member can reference each individual child order in any subsequent event by the new order ID. However, if no Child Order event is reported, then the Industry Member can only reference the order at the parent level by the order ID of the parent. There is no scenario in which the use of Child Order event is mandatory.
-Notes:
-• Child Order event can only be used when an order is sliced and assigned new order IDs within the same desk. An Order Internal Route event must be reported when routed to another desk.
-• There is no limit to how many "generations" can be created through Child Order events. The parentOrderID will be the orderID of the most recent order, whether that was a New Order/Order Accepted or a previous Child Order.
-• Child Orders must belong to the same FDID as the parent orders. Child Orders should not be used to create representative orders. If the FDID changes, a representative New Order event must be used and not a Child Order.
-• Child Orders should not be used for equity legs of a multi-leg option order.
-• This event only includes the key data elements and fields that may be changed from the parent order or that are required for linkage, i.e., certain key data elements from the parent order may not be changed when creating Child Orders.
-pubdate: February 28, 2019 effdate: N/A
- 4.6.1. Child Order Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Child Order, Child Order Event
- Compliance User: Industry Members
- Keywords:
- FINRA,
- OTC Equity Securities,
- NBBO,
-
- Child Order Event
-
-
- Linakge keys for this Reportable Event:
-• Order Key: date, reporter, symbol, orderID
-• Prior Order Key: date, reporter, symbol, parentOrderID
-pubdate: February 28, 2019 effdate: N/A
- 4.6.2. Child Order Modified
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Child Order, Child Order Modified
- Compliance User: Industry Members
- Keywords:
- CAT,
- FINRA,
- OTC Equity Securities,
- Industry Members,
-
- When the price, quantity or any Material Terms of the child order has been changed, a Child Order Modified event must be reported to CAT. This modification event is only used when the child order creation is reported to CAT in a Child Order event. As such, modifying a partial quantity internal route can not be reported in this event.
-All attributes and Material Terms of the Order of a modified child order listed on this event should be reported when applicable, including the fields that remain unchanged.
-Child Order Modified Event Field Specifications
-
-
- Linkage keys for this Reportable Event:
-• Order Key: date, reporter, symbol, orderID
-• Prior Order Key: date, reporter, symbol, priorOrderID
-pubdate: February 28, 2019 effdate: N/A
- 4.6.3. Child Order Canceled
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Child Order, Child Order Canceled
- Compliance User: Industry Members
- Keywords:
- CAT,
- Industry Members,
-
- If a child order is canceled, a Child Order Canceled event must be reported to CAT by the Industry Member.
-Note that a partial cancellation can be reported either with a Child Order Modified event or Child Order Canceled event with leavesQty, depending on how it is handled by the Industry Member. If an actual Cancel message was used, the Industry Member should report a Child Order Canceled event to CAT. If a modify or cancel/replace message was used, a Child Order Modified event should be reported to CAT. This keeps the reported event in line with the action taken by the Industry Member.
-Child Order Canceled Event Field Specifications
-
- Linkage keys for this Reportable Event:
-• Order Key: date, reporter, symbol, orderID
-pubdate: February 28, 2019 effdate: N/A
- 4.7. Order Modified and Cancel/Replace Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Modified and Cancel/Replace Event
- Compliance User: Industry Members
- Keywords:
- Material Term,
- NBBO,
- ATS,
-
- When the price, quantity or any other Material Term of an order has been changed or when an order is cancel/replaced, an Industry Member must report an Order Modified event to CAT. This Order Modified event concerns both of the following scenarios:
-1) A new order is generated (with a new Order ID) during the modification and completely replaces the prior order. In this case, the orderID field must capture the identifier for the new order. Additionally, the new order must be linked to the prior one through priorOrderID.
-2) If the order ID remains the same during the modification, the priorOrderID must match orderID.
-Note that in the first scenario, if the order has been modified several times, the priorOrderID must refer to the most recent order ID prior to this modification, which may not always be the original order ID.
-Side is required to be reported, but side adjustments are only allowed for same-side changes (e.g., changes between short and long sell).
-All attributes and Material Terms of the modified order listed on this event should be reported when applicable, including the fields that remain unchanged.
-Order Modified and Cancel/Replace Event Field Specifications
-
-
-
-
- Linkage keys for this Reportable Event:
-• Order Key: date (from eventTimestamp), reporter, symbol, orderID
-• Prior Order Key: date (from eventTimestamp if priorOrderDate is not present), reporter, symbol, priorOrderID
-• Prior Order Key: priorOrderDate (when present), reporter, symbol, priorOrderID
-• Route Link Key: date, symbol, receiverIMID, routingOrigin, session, routedOrderID
-• Quote Key: date, reporter, symbol, quoteID
-pubdate: February 28, 2019 effdate: N/A
- 4.8. Order Modified (Cancel/Replace) Supplement Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Modified (Cancel/Replace) Supplement Event
- Compliance User: Industry Members
- Keywords:
- Order Modified event,
-
- The Order Modified Supplement event serves as a supplement to the Order Modified event, just as the Supplement Event serves as a supplement to the New Order event.
-Order Modified Supplement Event Field Specifications
-
- Linkage keys for this Reportable Event:
-• Order Key: date, reporter, symbol, orderID
-• Order Key: date, reporter, symbol, aggregatedOrders.Name
-pubdate: February 28, 2019 effdate: N/A
- 4.9. Order Adjusted Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Adjusted Event
- Compliance User: Industry Members
- Keywords:
- Order Modified event,
- Industry Member,
- FINRA,
- OTC Equity Securities,
- NBBO,
-
- The Order Modified event requires the full state of the order be reported to CAT for each modify. However, there are some common cases where only the price or quantity are modified. If such changes are initiated by the Industry Member, which can occur frequently, the Order Adjusted event can be used in these situations. However, Order Adjusted events may not be used if a price or quantity change is initiated by a routing Industry Member.
-The only types of modifications that are allowed to be reported with this event are changes to the side, price or quantity of the order.
-• Side adjustments are only allowed for same-side changes (e.g., changes between short and long sell). The side only needs to be reported if it changes.
-• If a price change is reported, then all three price fields (price, displayPrice, and workingPrice) must represent the current state of the order relative to price. The quantity fields can be omitted.
-• Likewise, if a quantity change is reported, then all three quantity fields must represent the current state of the order relative to quantity. The price fields can be omitted.
-When the display price or quantity changes as the result of a display ATS matching engine action and not from a customer instruction, an Order Adjusted event must be used (the Order Modified event cannot be used in this scenario).
-Any modification that cannot be fully represented in this Reportable Event must be reported via the Order Modified event.
-Order Adjusted Event Field Specifications
-
-
-
- Linkage keys for this Reportable Event:
-• Order Key: date, reporter, symbol, orderID
-• Prior Order Key: date, reporter, symbol, priorOrderID
-pubdate: February 28, 2019 effdate: N/A
- 4.10. Order Canceled
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Canceled
- Compliance User: Industry Members
- Keywords:
- Broker,
- Order Canceled Event,
- FINRA,
- OTC Equity Securities,
-
- The Order Canceled event is used in specific situations when an order is fully or partially canceled. Note:
-• Partial cancellation of an order may be reported to CAT using either an Order Canceled event or an Order Modified event.
-• This Order Canceled Event is only reported by the entity that performs the cancellation. Cancellations by away venues are not required to be reported. For example, if Broker B accepts an order from Broker A, and Broker B initiated a cancel on the order, then B is responsible for reporting the order canceled (not Broker A).
-• Implicit order cancellations are not required to be reported to CAT (e.g., cancellation due to expiration of Time in Force.)
-Order Canceled Event Field Specifications
-
- Linkage keys for this Reportable Event:
-• Order Key: date (from eventTimestamp if priorOrderDate is not present), reporter, symbol, orderID
-• Order Key: priorOrderDate (when present), reporter, symbol, orderID
-pubdate: February 28, 2019 effdate: N/A
- 4.11. New Quote
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, New Quote
- Compliance User: Industry Members
- Keywords:
- NMS Securities,
- OTC Equity Securities,
- Industry Member,
- NMS Plan,
- New Quote Event,
- Quote Modify event,
- FINRA,
- Symbol,
-
- In Phase 2a, the following quotations must be reported:
-• Quotes in NMS Securities sent to an exchange or the ADF
-• Quotes in OTC Equity Securities received by an Industry Member CAT Reporter operating an inter-dealer quotation system.
-• Quotes in OTC Equity Securities that meet the definition of bid or offer under the CAT NMS Plan sent by a broker-dealer to a quotation venue not operated by a CAT Reporter.
-Quotes in OTC equity securities sent to an inter-dealer quotation system operated by an Industry Member CAT Reporter must be reported in Phase 2c.
-The New Quote Event is used to report quotes in OTC equity securities. Quotes in NMS Securities sent to an exchange must be reported using the New Order and Route Events.
-For two-sided quotes - bidPrice, bidQty, askPrice, and askQty must all be populated. For one-sided quotes both a quantity and a price field must be populated for either the bid or the ask.
-Note that there is no Quote Modify event. The field priorQuoteID is used to report modifications to a previously reported New Quote. If the field priorQuoteID is populated with a value in the New Quote event, then this New Quote is considered to replace the quote described in the priorQuoteID field. In the case when quote ID does not change for a modified quote, the priorQuoteID and the quoteID (new) will have the same value.
-Otherwise, if the field onlyOneQuoteFlag = true, any New Quote event offered by the same reporterIMID to the same destination in the same symbol will be considered canceled by CAT.
-New Quote Event Field Specifications
-
-
-
- pubdate: February 28, 2019 effdate: N/A
- 4.11.1. Quote Received
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, New Quote, Quote Received
- Compliance User: Industry Members
- Keywords:
- Industry Member,
- Order Accepted Event,
-
- When Quotes are sent to another Industry Member, that receiving Industry Member must report their receipt of the quote. Note that Industry Members do not have to report the quotes that they do not accept.
-Quote Received Event Field Specifications
-
-
- pubdate: February 28, 2019 effdate: N/A
- 4.11.2. Quote Canceled
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, New Quote, Quote Canceled
- Compliance User: Industry Members
- Keywords:
- Industry Member,
- ATS,
- Quote Canceled events,
- FINRA,
- OTC Equity Securities,
-
-
- Quote Canceled Event Field Specifications
-
-
- pubdate: February 28, 2019 effdate: N/A
- 4.12. Trade
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Trade
- Compliance User: Industry Members
- Keywords:
- Trade Event,
- Industry Member,
- Reporting Exception Code,
- Trade Side Details,
- Internalized Trade,
- Negotiated Trade,
-
- Trade A Trade Event is used when the Industry Member acts as the executing broker and is required to report the trade for public dissemination purposes. When an Industry Member is not required to report the execution of a customer order for public dissemination purposes, an Order Fulfillment event must be used. See Section 4.13 Order Fulfillment for more details.
-Note there are two circumstances where a Reporting Exception Code (REC) will be required on a Trade Event. The first is when an Industry Member executes a trade between two desks or departments involving two proprietary accounts of the firm, but because there is no change in beneficial ownership, no trade is reported for public dissemination. In this instance a REC of “P” should be used on the Trade Event. The second is when an Industry Member executes a trade and must report the trade via Form T. In this instance a REC of “F” should be used on the Trade Event.
-Trade Side Details
-Trade events are generally two-sided, containing information on both sides of the trade (with the exception of negotiated trades and internalized trades). The details of each side are reported in buyDetails and sellDetails respectively. The buyDetails must contain the orderID of the buy side of the trade and the sellDetails must contain the orderIDof the sell side of the trade. Side Details may contain only one orderID per side. If a single order is crossed against multiple orders, a separate Trade Event must be reported for the execution of each individual order.
-Note that the data type Trade Side Details is described as a list of fields in the table immediately following the Trade event table. These are data elements such as an orderID associated with a side of the trade.
-Internalized Trade
-In the scenario where the Industry Member internalizes an order by filling it from a proprietary account, the Industry Member must report the orderID on the customer side and the FDID and the account type of the proprietary account on the firm side. No order ID is required on the firmSideDetails.
-Negotiated Trade
-If an execution occurs as the result of a negotiated trade between two Industry Members, both of the Industry Members, for CAT purposes, are considered to have executed the trade and must submit a Trade event with the negotiatedTradeSide marked appropriately. The negotiatedTradeSide indicates whether the Industry Member is performing a negotiated buy or negotiated sell in this execution. The Industry Member must capture the full details for its own side, while only the IMID of the contra-side.
-Trades that are executed by a market maker as the result of a displayed quotation must be reported using the Trade as Result of Quote Event. See Section 4.12.2 for the reporting requirements for trades executed by a market maker as the result of a quote.
-pubdate: February 28, 2019 effdate: N/A
- 4.12.1. Trade Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Trade, Trade Event
- Compliance User: Industry Members
- Keywords:
- Data Elements,
- FINRA,
- OTC Equity Securities,
- National Securities Exchange,
- NBBO,
- Order Accepted Event,
- New Order event,
-
- The tables below describe the data elements to report agency cross or internalized orders by filling them from a proprietary account.
-Trade Event Field Specifications
-
-
- Trade Side Details
-
-
- Linkage Keys for this Reportable Event:
-• Order Key: date, reporter, symbol, buyDetails.orderID
-• Order Key: date, reporter, symbol, sellDetails.orderID
-• Trade Key: date reporter symbol tradeID
-• TRF Key: date, reporter, symbol, tapeTradeID
-pubdate: February 28, 2019 effdate: N/A
- 4.12.2. Trade as the Result of a Quote
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Trade, Trade as the Result of a Quote
- Compliance User: Industry Members
- Keywords:
- FINRA,
- Quote event,
- OTC Equity Securities,
- National Securities Exchange,
-
- If a trade is the result of a quote displayed by a market maker on an inter-dealer quotation system where the market maker is the executing broker under FINRA trade reporting rules and required to report the trade to the FINRA ORF, the Trade as the Result of a Quote event must be used to report the trade. The market maker is required to report the Quote ID of the quote from the inter-dealer quotation in order to link the quote to the trade.
-Trade on a Quote Event Field Specifications
-
- Trade on a Quote Side Details
-
-
- Linkage Keys for this Reportable Event:
-• Order Key: date, reporter, symbol, buyDetails.orderID
-• Order Key: date, reporter, symbol, sellDetails.orderID
-• Order Key: date, reporter, symbol, buyDetails.quoteID
-• Order Key: date reporter symbol sellDetails.quoteID
-• Trade Key: date reporter symbol tradeID
-• TRF Key: date, reporter, symbol, tapeTradeID
-pubdate: February 28, 2019 effdate: N/A
- 4.13. Order Fulfillment
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Fulfillment
- Compliance User: Industry Members
- Keywords:
- Industry Member,
- CAT,
- Order Fulfillment event,
-
- The Order Fulfillment event is used to report the execution of a customer/client order that is not required to be reported for public dissemination purposes. Order Fulfillment reports are required for scenarios where a representative order was used to facilitate the execution of the customer/client order. Examples include orders executed on a riskless principal basis and orders executed on an agency basis via a representative agency order, such as in aggregation scenarios. An Order Fulfillment is also required when an order is routed to a foreign market and the resulting foreign execution is not captured by CAT. In this scenario, the Order Fulfillment is used to obtain the execution information for the customer order since such information is not otherwise available in CAT.
-The Order Fulfillment event is designed to capture the customer/client details and the firm side details, which reflect the representative order details for the order used to execute the customer/client order. In Phase 2a, not all scenarios require the firm side details to be populated.
-The field fulfillmentLinkType is used to indicate if the Industry Member (firm) side details are required. Below are the values allowed:
-• Y – Representative Order; linkage required
-• YF – Representative order; linkage required in future phase
-• YP – Fill from pre-existing Principal order; linkage required
-• FOR – No linkage required; Fulfillment on an order routed to a foreign destination
-• O - Options Order Fulfillment
-Appendix C contains detailed descriptions of representative order scenarios and illustrates when marking of the representative order, linkage between the represented order and the representative order, and Order Fulfillment linkage is required in each phase.
-pubdate: February 28, 2019 effdate: N/A
- 4.13.1. Order Fulfillment Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Fulfillment, Order Fulfillment Event
- Compliance User: Industry Members
- Keywords:
- Order Fulfillment event,
- FINRA,
- OTC Equity Securities,
- Industry Member,
- Order Accepted Event,
-
- Order Fulfillment Event Field Specifications
-
-
- Fulfillment Side Details
-
- Linkage Keys for this Reportable Event:
-• Order Key: date (from eventTimestamp if firmDetails.priorOrderDate is not present), reporter, symbol, firmDetails.orderID
-• Order Key: date (from eventTimestamp if clientDetails.priorOrderDate is not present), reporter, symbol, clientDetails.orderID
-• Order Key: firmDetails.priorOrderDate (when present), reporter, symbol, firmDetails.orderID
-• Order Key: clientDetails.priorOrderDate (when present), reporter, symbol, clientDetails.orderID
-• Fulfillment: date, reporter, symbol, fulfillmentID
-pubdate: February 28, 2019 effdate: N/A
- 4.14. Order Fulfillment Amendment
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Order Fulfillment Amendment
- Compliance User: Industry Members
- Keywords:
- Industry Member,
- Order Fulfillment,
- debit/credit,
- FINRA,
- OTC Equity Securities,
-
- If the order fulfillment is amended, an amendment event must be reported to CAT with required details. This Reportable Event must capture the entire state of the fulfillment after it has been amended, even though some of the data elements may remain unchanged.
-For example, an Industry Member has a trade correction from the exchange after the customer order has already been fulfilled. Subsequently, the Industry Member decided to amend the executed shares given back to the customer. In this scenario, both the original Order Fulfillment and Order Fulfillment Amendment events must be reported to CAT, even though they may happen on the same day. However, if the trade correction comes before any initial fulfillment has been made, and the Industry Member directly gives the corrected shares to the customer, then only one Order Fulfillment event is necessary to be reported.
-If an Industry Member makes a correction via a debit/credit to the customer's account instead of modifying the executed shares given back to the customer, then the Industry Member does not need to report an Order Fulfillment Amendment event.
-Note that the amendment reporting is only applicable to Order Fulfillment events, not the events reported to the TRF for media dissemination (which would have originally been reported as Trade events).
-Order Fulfillment Amendment Event
-
-
- Linkage Keys for this Reportable Event:
-• Order Key: date (from eventTimestamp if firmDetails.priorOrderDate is not present), reporter symbol firmDetails.orderID
-, , . • Order Key: date (from eventTimestamp if clientDetails.priorOrderDate is not present), reporter symbol clientDetails.orderID
-• Order Key: firmDetails.priorOrderDate (when present), reporter, symbol, firmDetails.orderID
-• Order Key: clientDetails.priorOrderDate (when present), reporter, symbol, clientDetails.orderID
-• Fulfillment Key: date, reporter, symbol, fulfillmentID
-• Prior Fulfillment Key: date, reporter, symbol, priorFulfillmentID
-pubdate: February 28, 2019 effdate: N/A
- 4.15. Post-trade Allocation (Phase 2c)
-Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, Post-trade Allocation (Phase 2c)
- Compliance User: Industry Members
- Keywords:
- <Deferred - Not Required Until Phase 2c>
-pubdate: February 28, 2019 effdate: N/A
- 5. Single Leg Option Events
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events
- Compliance User: Industry Members
- Keywords:
- Reportable Event,
- Industry Members,
- CAT,
- SROs,
-
- This section describes Reportable Events for single leg option transactions. The following table lists each option Reportable Event type with its corresponding Message Type code.
-Notes
-•In Phase 2b, Industry Members are required to report CAT Industry Member Data related to Eligible Securities that are options and meet the definition of Simple Electronic Option Orders6, excluding Electronic Paired Option Orders.
-Events and data elements that are greyed out do not apply to Phase 2b.
-• The greyed out order events will not be supported in Phase 2b; any submission on unsupported event types will generate an error.
-• If data elements are greyed out for Phase 2b on a supported order event, the fields will be supported7 though not required. The Industry Member may voluntarily report the elements in Phase 2b.
-Linkages in Phase 2b
-In Phase 2b, the definition of an electronic single option order will result in unlinked events within a single CAT Reporter. To address these expected unlinked events, two fields (priorUnlinked and nextUnlinked) are used as described below. The purpose of these fields is to identify that the immediately preceding or following event is not reportable in Phase 2b and is not present for linkage. An immediately preceding or following event may be a manual event, complex order event, or a paired order. The priorUnlinked and nextUnlinked fields have values to indicate why the immediately preceding or following event is not present.
-
- One or both of these fields will be on all options event types as conditional. If an event does not have this field populated, linkage will be attempted.
-Special circumstances of a complex order being represented as individual legs in Phase 2b
-In the special circumstance of an Industry Member sending (receiving) a complex order electronically as individual legs of the complex orders, the preferred method of reporting is to suppress the events associated with these messages. If an Industry Member cannot do this, the Industry Member must populate the handlingInstructions field with 'CMPX' to indicate that the order (route) is part of a complex option order in Phase 2b. In addition, such voluntarily reported single leg orders must include a priorUnlinked or nextUnlinked flag of 'C', as applicable, to indicate they will not link to a related order at the sending (receiving) firm.
-Summary of Option Order Events
-
-
- pubdate: February 28, 2019 effdate: N/A
- 5.1. New Option Order Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, New Option Order Event
- Compliance User: Industry Members
- Keywords:
- Industry Members,
- CAT,
- non-reporting foreign broker-dealer,
- CMTA trades,
-
- An Industry Member must report a New Option Order event to CAT when an order is received or originated. This includes:
-• New customer orders8
-• Representative orders
-• Proprietary orders
-• Order(s) received from a non-reporting foreign broker-dealer or affiliate.
-Note that an order received from another CAT Reporter (US broker-dealer, ATS, or an exchange) must be reported as an Option Order Accepted event.
-Representative Orders
-Phase 2b Representative Orders
-While there are fewer representative order scenarios for options than equities, to the extent they are used, representative orders will be treated the same as equity representative orders, including the phased reporting approach for such orders.
-Specifically, in Phase 2b, representative orders and linkage to the represented order is required for simple, electronic orders between the representative street-side order and the customer or client order being represented, when the representative order was originated specifically to represent a single customer/client order and there is:
-• An existing, direct electronic link in the Industry Member's system between the order being represented and the representative order, and
-• Any resulting executions are immediately and automatically applied to the represented order in the Industry Member's system.
-Any portion of a specific order handling scenario that involves a complex or paired order is not reportable until Phase 2d.
-See Appendix C for a detailed description of representative order reporting.
-Phase 2d Representative Orders
-Any scenario that does not meet the definition of Phase 2b representative order will fall into this category, including any scenario involving a manual or complex order.
-See the CAT Industry Member Reporting Scenarios document for detailed examples of how representative order scenarios for options are reported in Phase 2b.
-New Option Order Event
-
-
- Linkage keys for this Reportable Event:
-• Order Key: date, reporter, optionID, orderID
-• ComplexOrderKey: date, reporter, (complexOptionID), complexOrderID (Not applicable in Phase 2b)
-pubdate: February 28, 2019 effdate: N/A
- 5.2. Option Order Supplement Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Supplement Event
- Compliance User: Industry Members
- Keywords:
- <Deferred - Not Required Until Phase 2d>
-pubdate: February 28, 2019 effdate: N/A
- 5.3. Paired Option Order (Phase 2d)
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Paired Option Order (Phase 2d)
- Compliance User: Industry Members
- Keywords:
- <Deferred - Not Required Until Phase 2d>
-pubdate: February 28, 2019 effdate: N/A
- 5.4. Option Order Route
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Route
- Compliance User: Industry Members
- Keywords:
- Industry Members,
- CAT,
-
- Industry Members must report Option Order Route events to CAT when reporting the routing of option orders.
-pubdate: February 28, 2019 effdate: N/A
- 5.4.1. Option Order Route Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Route, Option Order Route Event
- Compliance User: Industry Members
- Keywords:
- CAT,
- Industry Members,
- foreign broker-dealers,
- Exchanges,
- FINRA,
- Order Accepted Event,
- foreign broker-dealer,
-
- An Industry Member must report to CAT an Option Order Route Event when:
-• Routing to other Industry Members
-• Routing to foreign broker-dealers
-• Routing to exchanges
-• Routing between two IMIDs (e.g. two different FINRA MPIDs) attributed to the same legal entity (i.e. the same CRD)
-• Routing partial quantities of an order (assigned using routedOrderId in routing message)
-In order for CAT to maintain order lifecycle linkage, the orderID populated in the Option Order Route event must reference the most recent internal ID of the order. For example, if an order was modified before routing out, the Route Event must use the ID assigned on the order modification.
-Internal routes to another desk or department within an Industry Member are not reported using the Option Order Route event; instead an Option Order Internal Route event is used. See the Option Order Internal Route section for more details.
-Handling Instructions on the Option Order Route
-The handling instructions included in this event should represent those on the routed order. If the handling instructions do not change from the Option Order Accepted or New Option Order associated with the order, Industry Members may use the handling instruction code "RAR" - routed as received, instead of repeating each individual handling instruction.
-Option Order Route Event Field Specifications
-
-
-
- Linkage keys for this Reportable Event:
-• Order Key: date (from eventTimestamp if priorOrderDate is not present), reporter, optionID, orderID
-• Order Key: priorOrderDate (when present), reporter, optionID, orderID
-• Route Link Key: date, senderIMID, destination, optionID, session, routedOrderID
-pubdate: February 28, 2019 effdate: N/A
- 5.4.2. Option Order Modify Route Event (Potential Phase 2d)
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Route, Option Order Modify Route Event (Potential Phase 2d)
- Compliance User: Industry Members
- Keywords:
- SROs,
-
- <Deferred – event not required for Phase 2a or Phase 2b. SROs will evaluate need for a modified route event after reviewing Phase 2a/2b data and include event in Phase 2d, if necessary.>
-pubdate: February 28, 2019 effdate: N/A
- 5.4.3. Option Order Cancel Route Event (Potential Phase 2d)
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Route, Option Order Cancel Route Event (Potential Phase 2d)
- Compliance User: Industry Members
- Keywords:
- SROs,
-
- <Deferred – event not required for Phase 2a or Phase 2b. SROs will evaluate need for a canceled route event after reviewing Phase 2a/2b data and include event in Phase 2d, if necessary.>
-pubdate: February 28, 2019 effdate: N/A
- 5.5. Option Order Accepted
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Accepted
- Compliance User: Industry Members
- Keywords:
- Industry Members,
- CAT,
- non-reporting foreign entity,
- CMTA trades,
-
- When an Industry Member receives a routed option order from another Industry Member or an exchange, then an Option Order Accepted event must be reported to CAT. As described in Options Order Route event, if an Industry Member accepts a routed order from another Industry Member, even though that IMID may attribute to the same Industry Member, i.e., the same CRD, an Order Accepted event must be reported.
-Once all Industry Member are reporting, in all cases, the order reported with this event should have already been originated by another Industry Member and reported upon origination with a New Option Order event. A New Option Order event represents the beginning of the order lifecycle in CAT, therefore a new customer order is represented with a New Option Order event - not an Option Order Accepted event. At the start of Phase 2b, there will be some lifecycles beginning at Option Order Accepted event, as Small Industry Members are not required to report until a later phase.
-Orders received from a non-reporting foreign entity or affiliate should be reported as a New Option event instead of an Option Order Accepted event.
-Option Order Accepted Field Specifications
-
-
-
- Linkage keys for this Reportable Event:
-• Order Key: date, reporter, optionID, orderID
-• Route Link Key: date, senderIMID, destination, optionID, session, routedOrderID
-pubdate: February 28, 2019 effdate: N/A
- 5.6. Option Order Internal Route
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Internal Route
- Compliance User: Industry Members
- Keywords:
- Industry Members,
- CAT,
- Child Option Order event,
-
- An Option Order Internal Route events must be reported when an order is passed internally to a different department or desk within a reporterIMID.
-Although multiple reporterIMIDs may be attributed to a single Industry Member, routes between different IMIDs attributed to the same Industry Member are not considered internal routes.
-Note that an Optional Order Internal Route event does not follow the logic of sending/receiving two-sided reporting followed throughout the rest of these Industry Member Technical Specifications. It is required to be reported from the perspective of the recipient desk. The Option Order Internal Route merely shows that an order was received by an internal destination and if a new orderID has been assigned to the order as a result of the Option Order Internal Route.
-• An Option Order Internal Route may also represent the routing of partial quantities of an option order internally, and the practice of assigning those slices new orderIDs. In this case, multiple slices are routed to yet another destination internally - this event should represent the receiving desk, quantities, and new orderIDs of those routed slices as received by the subsequent internal destination. This approach will allow CAT to track changes in orderID within an Industry Member as an order is passed between internal entities or partial quantities are routed to internal entities as slices of another order.
-• The major difference between Option Order Internal Route and Child Option Order events is that the Child Option Order event can only be used when no desk change or desk route happens. For example, some Industry Members may first choose to generate child orders using the Child Option Order event to represent slices of a parent order, then route those slices internally to another desk (Option Order Internal Route event). This approach is also acceptable for CAT reporting and will not result in unlinked events.
-Option Order Internal Route Modified and Option Order Internal Route Canceled are not required to be reported until Phase 2d.
-pubdate: February 28, 2019 effdate: N/A
- 5.6.1. Option Order Internal Route Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Internal Route, Option Order Internal Route Event
- Compliance User: Industry Members
- Keywords:
- Symbol,
-
- Option Order Internal Route event is used to report an order sent internally to another desk.
-Option Order Internal Route Field Specifications
- -Linkage keys for this Reportable Event:
-• Order Key: date, reporter, optionID, orderID
-pubdate: February 28, 2019 effdate: N/A
- 5.6.2. Option Order Internal Route Modify Event (Phase 2d)
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Internal Route, Option Order Internal Route Modify Event (Phase 2d)
- Compliance User: Industry Members
- Keywords:
- <Deferred - Not Required Until Phase 2d>
-pubdate: February 28, 2019 effdate: N/A
- 5.6.3. Option Order Internal Route Canceled Event (Phase 2d)
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Internal Route, Option Order Internal Route Canceled Event (Phase 2d)
- Compliance User: Industry Members
- Keywords:
- <Deferred - Not Required Until Phase 2d>
-pubdate: February 28, 2019 effdate: N/A
- 5.7. Child Option Order
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Child Option Order
- Compliance User: Industry Members
- Keywords:
- Industry Members,
-
- The Child Option Order event is provided solely for the convenience of Industry Members to help model scenarios in which an order is split or sliced into smaller "child" orders that are handled independently of their parent order - in a way that best reflects each individual Industry Member's system(s).
-For example, in the scenario when Industry Members create independent child orders with new orderIDs, if the Child Option Order event is reported, then the changes of order IDs are captured. Afterwards, the Industry Member can reference each individual child option order in subsequent events by the new order ID. However, if no Child Option Order event is reported, then the Industry Member can only reference the order at the parent level by the order ID of the parent. There is no scenario in which the use of a Child Option Order event is absolutely mandatory.
-Notes:
-• Child Option Order events can only be used when an order is sliced and assigned new order IDs within the same desk. An Option Order Internal Route event must be reported when routed to another desk.
-• There is no limit to how many "generations" can be created using Child Option Order events. The parentOrderID will be the orderID of the most recent order, whether that was a New Option Order/Option Order Accepted or a previous Child Option Order.
-• Child Option Orders must belong to the same FDID as the parent order.
-• Child Option Orders should not be used for single legs of a multi-leg option order.
-• This event only includes the key data elements and fields that may be changed from the parent order or that are required for linkage, i.e., certain key data elements from the parent order may not be changed when creating Child Option Orders.
-pubdate: February 28, 2019 effdate: N/A
- 5.7.1. Child Option Order Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Child Option Order, Child Option Order Event
- Compliance User: Industry Members
- Keywords:
- Industry Members,
- contracts,
- Reportable Event,
-
- Child Option Order Event Field Specifications
- -Linkage keys for this Reportable Event:
-• Order Key: date, reporter, optionID, orderID
-• Prior Order Key: date, reporter, optionID, parentOrderID
-pubdate: February 28, 2019 effdate: N/A
- 5.7.2. Child Option Order Modified Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Child Option Order, Child Option Order Modified Event
- Compliance User: Industry Members
- Keywords:
- CAT,
- Material Terms of the Order,
-
- When the price, quantity, or any Material Term of the child option order has been changed, a Child Option Order Modified event must be reported to CAT. This modification event is only used when the child option order creation is reported to CAT in a Child Option Order event. As such, modifying a partial quantity internal route cannot be reported in this event.
-All attributes and Material Terms of the Order of a modified child option order listed on this event should be reported when applicable, including the fields that remain unchanged.
-Child Option Order Modified Event Field Specifications
- -Linkage keys for this Reportable Event:
-• Order Key: date, reporter, optionID, orderID
-• Prior Order Key: date, reporter, optionID, priorOrderID
-pubdate: February 28, 2019 effdate: N/A
- 5.7.3. Child Option Order Canceled
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Child Option Order, Child Option Order Canceled
- Compliance User: Industry Members
- Keywords:
- Canceled event,
- Industry Member,
-
- If a child option order is canceled, a Child Option Order Canceled event must be reported to CAT by the Industry Member.
-Note that a partial cancellation can be reported either with a Child Option Order Modified event or Child Option Order Canceled event with leavesQty, depending on how it is handled by the Industry Member. If an actual cancel message was used, the Industry Member should report a Child Option Order Canceled event to CAT. If a modify or cancel/replace message was used, a Child Option Order Modified event should be reported to CAT. This keeps the reported event in line with the action taken by the Industry Member.
-Child Option Order Canceled Event Field Specifications
- -Linkage Keys for this Reportable Event:
-• Order Key: date, reporter, optionID, orderID
-pubdate: February 28, 2019 effdate: N/A
- 5.8. Option Order Modified and Cancel/Replace Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Modified and Cancel/Replace Event
- Compliance User: Industry Members
- Keywords:
- Material Terms of the Order,
- Industry Member,
- contracts,
- CMTA trades,
-
- When the price, quantity or any other Material Terms of the Order has been changed or when an order is cancel/replaced, an Industry Member must report an Option Order Modified event to CAT. This Option Order Modified event concerns both of the following scenarios:
-1) A new order is generated (with a new Order ID) during the modification and completely replaces the prior order. In this case, the orderID field must capture the identifier for the the order. Additionally, the new order must be linked to the prior order through priorOrderID.
-2) If the Order ID remains the same during the modification, the priorOrderIDmust match the event orderID.
-Note that in the first scenario, if the order has been modified several times, the priorOrderID must refer to the most recent orderID prior to this modification, which may not always be the original order ID.
-Side is required to be reported, but side adjustments are only allowed for same-side changes (e.g., changes between short and long sell).
-All attributes and Material Terms of the modified order listed on this event should be reported when applicable, including the fields that remain unchanged.
-Option Order Modified and Cancel/Replace Event
- -Linkage keys for this Reportable Event:
-• Order Key: date (from eventTimestamp), reporter, optionID, orderID
-• Prior Order Key: date (from eventTimestamp if priorOrderDate is not present), reporter, optionID, priorOrderID
-• Prior Order Key: priorOrderDate (when present), reporter, optionID, priorOrderID
-• Route Link Key: date, optionID, receiverIMID, routingOrigin, session, routedOrderID
-pubdate: February 28, 2019 effdate: N/A
- 5.8.1. Option Order Modified Supplement Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Modified and Cancel/Replace Event, Option Order Modified Supplement Event
- Compliance User: Industry Members
- Keywords:
- <Deferred - Not Required Until Phase 2d>
-pubdate: February 28, 2019 effdate: N/A
- 5.9. Option Order Adjusted Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Adjusted Event
- Compliance User: Industry Members
- Keywords:
- CAT,
- Option Order Modified event,
- Reportable Event,
-
- Industry Members must report to CAT the Option Order Modified event, which records the full state of the order reported to CAT on each modification. However, there are some common scenarios where only the order price and/or quantity of an order are modified. If such changes are initiated by the Industry member, the Option Order Adjusted event can be used. However, Option Order Adjusted events may not be used if a price or quantity change is initiated by a routing Industry Member.
-• Price change only - the price field and leavesQty must be reported to represent the current state of the order with respect to price. The two conditionally-required quantity fields (quantity, minQty) can be omitted.
-• Quantity change only - both conditionally-required quantity fields (quantity, minQty) and leavesQty must be reported. The price field can be omitted.
-• Both price and quantity change - If both price and quantity change, all fields must be reported.
-Any modification that cannot be fully represented in this Reportable Event must be reported via the Option Order Modified event.
-Option Order Adjusted Event Field Specifications
- -Linkage keys for this Reportable Event:
-• Order Key: date, reporter, optionID, orderID
-• Prior Order Key: date, reporter, optionID, priorOrderID
-pubdate: February 28, 2019 effdate: N/A
- 5.10. Option Order Canceled Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Canceled Event
- Compliance User: Industry Members
- Keywords:
- CAT,
- Broker,
- Industry Member,
-
- The Option Order Canceled event is used in specific situations when an options order is fully or partially canceled. Note:
-• Partial cancellation of an order may be reported to CAT using either an Option Order Canceled event or an Option Order Modified event.
-• This Option Order Canceled Event is only reported by the Industry Member that performs the cancellation. Cancellations by away venues are not required to be reported. For example, if Industry Member Broker B accepts an order from Industry Member Broker A, and Broker B initiated a cancel on the order, then B is responsible for reporting the order canceled (not Broker A).
-• Implicit order cancellations are not required to be reported to CAT (e.g., cancellation due to expiration of Time in Force).
-Option Order Canceled Field Specifications
- -Linkage keys for this Reportable Event:
-• Order Key: date (from eventTimestamp if priorOrderDate is not present), reporter, optionID, orderID
-• Order Key: priorOrderDate (when present), reporter, optionID, orderID
-pubdate: February 28, 2019 effdate: N/A
- 5.11. Option Order Fulfillment
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Fulfillment
- Compliance User: Industry Members
- Keywords:
- Industry Member,
- contracts,
- foreign non-reporting entity,
-
- The Option Order Fulfillment event is designed to show an execution given back to the original option order(s), informing its customer/client of the number of contracts executed and at what price, that is not required to be reported for public dissemination purposes.
-An Order Fulfillment event must be reported in the following scenarios:
-• When an aggregated order executes, and the Industry Member gives back executed contracts to each order that was part of the aggregated order. An Option Order Fulfillment event will be reported for each order that was part of an aggregated order.
-• When an Industry Member creates a “representative" multi-leg complex option order. If the representative order is executed, the Industry Member must report an Option Order Fulfillment event for each of the orders being represented.
-• When an order is routed to a foreign non-reporting entity, the Industry Member must report an Option Order Fulfillment to represent the outcome of the order.
-For the first two scenarios above, Phase 2b does not require explicit order linkage between the bunched or representative order and the "underlying" order. Prior to Phase 2d, the Order Fulfillment events only contain the clientDetails. The fulfillmentLinkType must be marked as "YF".
-In the scenario of routing to a foreign non-reporting destination, the fulfillment event is always one sided (customer order only) and the fulfillmentLinkType must be marked as "FOR".
-pubdate: February 28, 2019 effdate: N/A
- 5.11.1. Option Order Fulfillment Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Fulfillment, Option Order Fulfillment Event
- Compliance User: Industry Members
- Keywords:
- Industry Member,
- Option Order Accepted event,
-
- Option Order Fulfillment Event Field Specifications
- -Options Fulfillment Side Details
- -Linkage Keys for this Reportable Event:
-• Order Key: date (from eventTimestamp if firmDetails.priorOrderDate is not present), reporter optionID firmDetails.orderID
-• Order Key: date (from eventTimestamp if clientDetails.priorOrderDate is not present), reporter optionID clientDetails.orderID
-• Order Key: firmDetails.priorOrderDate (when present), reporter, optionID, firmDetails.orderID
-• Order Key: clientDetails.priorOrderDate (when present), reporter, optionID, clientDetails.orderID
-• Fulfillment: date, reporter, optionID, fulfillmentID
-pubdate: February 28, 2019 effdate: N/A
- 5.11.2. Option Order Fulfillment Amendment Event
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Order Fulfillment, Option Order Fulfillment Amendment Event
- Compliance User: Industry Members
- Keywords:
- Industry Member,
- CAT,
- Option Order Fulfillment event,
-
- If an order fulfillment is amended by an Industry Member on or after the trade date, an Option Order Fulfillment Amendment event is used. This Reportable Event must capture the entire state of the fulfillment after it has been amended, even though some of the data elements may remain unchanged.
-For example, if an Industry Member fulfills its customer's/client's order on an average price basis or work the order through representative or bunched orders. Afterwards, when a trade correction or trade break comes from the exchange and subsequently changes the price or quantity of the fulfilled contracts, both the original Option Order Fulfillment event and the Option Order Fulfillment Amendment event would be reported to CAT.
-The Option Order Fulfillment Amendment is not used in the following scenarios.
-• If a customer order is worked directly in an Agency capacity (without any representing or bunching) and filled print-for-print, when a trade break or trade correction occurs, the Industry Member does not need to report a Fulfillment Amendment event.
-• When a trade correction occurred same-day before the client order was fulfilled, only the Order Fulfillment event would be necessary to report to CAT, presuming it contained the updated (post-correction) average price.
-• When an Industry Member fulfills an order and receives a trade break from the exchange, it is possible that the Industry Member may choose to take the delta (e.g. using an error account) without amending the manner by which the order was fulfilled.
-Options Order Fulfillment Amendment Event Field Specifications
- -Linkage Keys for this Reportable Event:
-• Order Key: date (from eventTimestamp if firmDetails.priorOrderDate is not present), reporter optionID firmDetails.orderID
-• Order Key: date (from eventTimestamp if clientDetails.priorOrderDate is not present), reporter, optionID, clientDetails.orderID
-• Order Key: firmDetails.priorOrderDate (when present), reporter, optionID, firmDetails.orderID
-• Order Key: clientDetails.priorOrderDate (when present), reporter, optionID, clientDetails.orderID
-• Fulfillment Key: date reporter optionID, fulfillmentID
-• Prior Fulfillment Key: date, reporter, optionID, priorFulfillmentID
-pubdate: February 28, 2019 effdate: N/A
- 5.12. Linked Multi-Leg Option Order Events (Phase 2d)
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Linked Multi-Leg Option Order Events (Phase 2d)
- Compliance User: Industry Members
- Keywords:
- <Deferred - Not Required Until Phase 2d>
-pubdate: February 28, 2019 effdate: N/A
- 5.13. Option Post-Trade Allocations (Phase 2d)
-Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, Option Post-Trade Allocations (Phase 2d)
- Compliance User: Industry Members
- Keywords:
- <Deferred - Not Required Until Phase 2d>
-pubdate: February 28, 2019 effdate: N/A
- 6. Submission Process
-Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process
- Compliance User: Industry Members
- Keywords:
- CAT,
-
- In this section, information is provided regarding how to format submission files, submit to CAT (including a general data flow overview), the registration process, network and transport options, and CAT access and reporting hours.
-pubdate: February 28, 2019 effdate: N/A
- 6.1. File and Data Formats
-Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, File and Data Formats
- Compliance User: Industry Members
- Keywords:
- CAT,
- ISO-8859-1,
-
- All files sent from the CAT Reporter (or the third-party CAT Reporting Agent for the CAT Reporter) must be compressed, encrypted, and signed. However, the information in this section assumes, for the most part, that the file being described is the raw, unencrypted data (after being verified, decrypted, and uncompressed).
-All files submitted on a given date must have a unique file name, as defined in 6.1.1. The mechanism used for uploading files will prevent duplicate file names from being accepted into the CAT system.
-Archive files are not allowed to be submitted into the CAT System. Each set of records must be submitted as an individually compressed, encrypted, and signed file. For example: Do NOT zip, tar, or 7z all of the submitted files into one consolidated file. The files must be individually compressed, encrypted, and submitted.
-All data elements are submitted using ISO-8859-1 encoding. This is a one-byte-per-character encoding, with possible values in the range of [0, 255]. This encoding has the characteristic that the encoding character definitions are the same as the first 256 code points of UTF-8. However, only fully defined values will be accepted.
-According to the encoding specification, byte values in the ranges [0, 31] and [127, 159] are undefined. As a result, any record submitted with character values in those ranges will be rejected as invalid. In cases where data is echoed back in feedback files, invalid characters will be translated to a 3-character octal value, preceded by a backslash.
-pubdate: February 28, 2019 effdate: N/A
- 6.1.1. File Names
-Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, File and Data Formats, File Names
- Compliance User: Industry Members
- Keywords:
- CAT Reported ID,
- Encryption Extension,
-
- Files are to be named in the following manner:
-<CAT Reporter ID>_<Date>_[<Group>_]<File Kind>_<File Number>.<Extension>[.<Compression Extension>].<Encryption Extension>
-• CAT Reporter ID is the unique ID assigned to the reporter by CAT
-• Date is the calendar date for all events in the file in YYYYMMDD format - not the date the file was generated or reported
-• Group is an optional reporter-defined string. It must either be missing, or composed of up to 20 alphanumeric characters. The field exists solely for reporters’ convenience. Other than file name validation, it is ignored by the CAT processor
-• File Kind is “OrderEvents” for Industry Members
-• File Number is the sequence number of this file, 6-digits long, left-padded with zeros The tuple (CAT Reporter ID, Date, File Kind, File Number) must be unique. The File Number determines the order that a file will be processed within a File Kind.
-• Extension is the extension, representing the format of the data inside: json, csv
-• Compression Extension is the extension representing the compression used to compress the data file: gz, bz2, xz, zip. It is only needed if compression is done outside of the encryption process. If your OpenPGP tool handles compression, Compression Extension should be left off
-• Encryption Extension is the extension indicating that the file is encrypted and must be either .gpg or .pgp.
-pubdate: February 28, 2019 effdate: N/A
- 6.1.2. Metadata Files
-Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, File and Data Formats, Metadata Files
- Compliance User: Industry Members
- Keywords:
- CAT,
- Reported ID,
-
- For each data file that is uploaded to CAT, associated metadata must also be uploaded. Submitters may pair the metadata file one-to-one with the data file, so that when the "pair" is ready, both files can be moved and processed in a timely manner, or the submitter may choose to package multiple metadata "blocks" for multiple data files into one metadata file. But they must be for the same calendar date, reporter, on the same file version and by the same submitter. Each metadata "block" contains checksum and signing of the files that are submitted, which are needed to verify integrity and track provenance of the submissions.
-The metadata file must be named in the following manner:
-<CAT Reporter ID>_<Date>_[<Group>_]<File Kind>_<Metadata File Number>.<Extension>[.<Compression Extension>].<Encryption Extension>
-• CAT Reporter ID, Date (and Group) must be consistent with the data file(s)
-• Metadata file number is the sequence number of the metadata file, 6-digits long, left-padded with zeros The combination (CAT Reporter ID, Date, Metadata File Number) must be unique.
-• Extension is .meta
-• The metadata file must be first signed in cleartext, then compressed and then encrypted.
-An Industry Member may use multiple metadata files for a day. If an Industry Member is uploading multiple metadata files, the Industry Member should set the doneForDay flag as false until the last metadata file is submitted for the date with doneForDay = true. Once a metadata file with doneForDay = true is received, this signals that the files submitted by the Industry Member are ready for the linkage discovery processing stage. However, this will not "close" the submission process. If an Industry Member discovers it needs to make additional data submissions, the Industry Member may continue to submit the additional data files with a new metadata file. If no metadata files for a trading day are flagged doneForDay = true, the doneForDay flag(s) those files will be automatically set to true upon submission deadline at 8:00AM.
-The metadata file does not need to be compressed, but must still be encrypted and signed like the data file. The metadata file is in JSON format, and contains:
-Metadata Files
- -The hashes are to be submitted as 64-character hexadecimal string encodings of the hash value.
-
- If a metadata block in the file has an error, the erroneous block will be dropped, and proper corresponding feedback will be returned (see Section 7 for File Acknowledgment Feedback or Basic File Integrity Feedback). The rest of the "blocks" of the metadata file will continue to be processed. The reporter can resubmit the corrected metadata block in another metadata file.
-Reporters can include the metadata for original data files and for correction files into one metadata file, as long as they are for the same reporter, submitter and calendar day.
-pubdate: February 28, 2019 effdate: N/A
- 6.1.3. Data Files
-Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, File and Data Formats, Data Files
- Compliance User: Industry Members
- Keywords:
- JSON,
- CSV Records,
-
- All data files are either new-line delimited JSON objects, or new-line delimited CSV records. This means that for JSON, there is no top level object. Instead, the file acts as the top level container for each object. Each object is a normal JSON object, separated with a new-line (ASCII decimal 10, hex 0A). For CSV files, each record’s fields are separated with a comma (ASCII decimal 44, hex 2C).
-Each JSON object is terminated by a new-line, but the data in the object itself must not include new-lines. Specifically, each line in the file must contain exactly one complete record, no matter whether the submission format is JSON or CSV. In either case, the total maximum length of any line is 4095 bytes. The examples in the document include new-lines between elements for readability.
-pubdate: February 28, 2019 effdate: N/A
- 6.1.3.1. JSON Schema
-Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, File and Data Formats, Data Files, JSON Schema
- Compliance User: Industry Members
- Keywords:
- JSON,
- CAT,
-
- JSON schema files for each record type will be provided on the CAT public website. Industry Members will be able to download and use these schemas to format and validate their CSV and JSON data files prior to submission. These schemas will also allow Industry Members to translate their data files from JSON to CSV or from CSV to JSON formats, as desired.
-The schema files will be maintained by the Plan Processor and will be versioned as the message specifications change. The meta files submitted to CAT will contain a version identifier specifying which version of the schema the associated reference or order data was formatted in accordance with. This will allow the CAT System to perform a basic initial formatting validation of all submitted data.
-Provided here is an abbreviated example of a JSON schema containing only part of the equity New Order event and a couple definitions for Choice fields:
-
-
- Note that the file is not a typical "JSON schema" but a schema describing the Reportable Events in JSON.
-The field "JSONDataType" indicates the underlying JSON data type.
-The field "dataType" is the actual type, as indicated in this specification, with some further restrictions over the underlying JSON data type.
-The field "name" is the JSON field name. The "name" is also used as a lookup key to find valid values for a field of dataType "Choice."
-Each field of dataType "Choice" will contain a corresponding entry in the "choices" object, which contains the list of valid choices. The key is the value in the name field. If the name field contains a '.' (period), then the value is part of a nested JSON object and the key will be the trailing name. For example, if the field has a Choice field with the name "buyDetails.side" then the field "buyDetails" contains a JSON object with a member named "side" and "side" would be used as the key to lookup the valid choices for the element.
-The field "position" is the 0-based index where this field would be expected in a CSV version of the data.
-The field "required" indicates whether the field is "Required," "Conditional," or "Optional." If submitting in JSON, any conditional or optional field that is not provided must be omitted. If submitting in CSV, and conditional or optional field that it not provided must be an empty column (i.e., in the following example position 2 is considered to be omitted: zero,1,,three).
-Note that the Timestamp data type has two possible representations, so the JSONDataType is an array of choices: String for a formatted string and Number for nanoseconds since the epoch.
-pubdate: February 28, 2019 effdate: N/A
- 6.1.3.2. CSV Conversion
-Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, File and Data Formats, Data Files, CSV Conversion
- Compliance User: Industry Members
- Keywords:
- JSON Schema,
- CAT,
-
- The JSON schema defines valid data types, and mappings between JSON and CSV. Note that schemas can change with each specification version, and the authoritative schemas will be available on the CAT website. For this discussion, assume the following schema for an Equity Order Adjusted event. Provided here is an abbreviated example of a JSON schema containing only part of the Order Adjusted event and a couple definitions for Choice fields:
-
-
- The corresponding CSV would be:
-MEOJ,20170901T120201.123456,E,false,,,XYZ,T12346,T12345,Customer,Buy,,,,1100, 100,100,,,,,,,,
-pubdate: February 28, 2019 effdate: N/A
- 6.2. Connectivity and Registration
-Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, Connectivity and Registration
- Compliance User: Industry Members
- Keywords:
- Network Access,
- Industry Member Onboarding User Guide,
-
- CAT supports network access for reporting order events via VPN or direct connections (i.e., cross connects).
-More detailed information on connectivity and the registration process will be provided in the Industry Member Onboarding User Guide.
-pubdate: February 28, 2019 effdate: N/A
- 6.3. Transport Options
-Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, Transport Options
- Compliance User: Industry Members
- Keywords:
- Industry Member,
- Administrative Information,
-
- Industry Members may use different mechanisms (SFTP or the Reporter Web Portal) to send/obtain different types of information to/from CAT.
-Basic types of CAT information:
-1) Submissions (e.g. initial submission of files of order events, resubmission of files that were previously rejected, and corrections or deletions to previously accepted records;
-2) Feedback (e.g. upload status, rejections, and reporting statistics); and
-3) Administrative information.
- -SFTP submission allows file(s) only. If the submission is via the Reporter Web Portal, it may be sent by typing the information directly into the Web page or by submitting small files. The file size allowed via Reporter Web Portal is limited to 1GB before compression.
-pubdate: February 28, 2019 effdate: N/A
- 6.3.1. File Size, Encryption, and Compression
-Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, Transport Options, File Size, Encryption, and Compression
- Compliance User: Industry Members
- Keywords:
- File Compression,
- Encrypting,
- Metadata File,
-
- Any files transmitted via SFTP or Reporter Web Portal must be 1) compressed AND 2) encrypted AND 3) signed, for the purpose of security and efficient network usage. The following compression algorithms will be allowed:
-• ZIP (extension: zip)
-• Gzip (extension: gz)
-• BZip2 (extension: bz2)
-• LZMA2 (extension: xz)
-The size of files uploaded via SFTP is limited to 100GB per file, before compression and encryption. Resumable file upload is enabled for SFTP. The size limit for the Reporter Web Portal is 1GB per file, before compression and encryption.
-Submission of data to CAT requires a number of supporting requirements that include security, confidentiality, authentication, and provenance of the data submitted. To achieve this the standard capabilities of PGP will be utilized and will require encrypting, signing, and secure hashing of data. While these steps must be followed, Submitters have a choice of compression algorithms, passphrase selection and length, as well as what tools they use on their platform. When encrypting a metadata file, the CAT public encryption key must be used. This public key will be made available to reporters. The file may also be encrypted with the public key of the submitter and the public key of the reporter. Encrypted files can only be decrypted by the private key corresponding with the public key used to encrypt the file; including the optional public keys of Submitter and Reporter ensures that private key holders of CAT, Reporter, and Submitter can decrypt the encrypted file.
-Public/Private keys should be RSA with a bit length of at least 2048 (minimum and recommended), and up to 4096. Interested parties can read more at https://www.gnupg.org/faq/gnupg-faq.html Sections 13.3-4 are directly relevant. The cipher algorithm must be AES-256(recommended) or higher. When encrypting data files, the submitter may also sign the file with their private key. Metadata files must always be signed in cleartext, and then encrypted. All files must be compressed before, or with the encryption process. The digest algorithm used to sign the file must be SHA256. The signature should also be part of the encrypted file (i.e. no detached signatures). Once a file has been encrypted and/or signed, the extensions .pgp, .gpg, or .asc must be appended to the end of the filename; OpenPGP compliant tools will do this for you.
-pubdate: February 28, 2019 effdate: N/A
- 6.3.2. SFTP Upload Process
-Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, Transport Options, SFTP Upload Process
- Compliance User: Industry Members
- Keywords:
- STFP Upload,
-
- Each file that is uploaded must follow these basic steps.
-1. Upload the data file and the metadata file into the upload/transit directory, which will be at the base of the home directory for each sftp account.
-2. Upon successful upload of both file types (the metadata file as well as all the data files covered by the metadata file), move all files into the upload/complete directory. Note that all files should be uploaded before moving either to the complete directory.
-A file should never be directly uploaded into the upload/complete directory, as once a file has appeared there it is assumed to be the desired complete file submission. Only files that have a .pgp or .gpg extension will be processed.
-The Plan Processor will remove files from the upload/complete directory. The Submitter should never attempt to delete files from the upload/complete directory.
-pubdate: February 28, 2019 effdate: N/A
- 6.4. Accessing Feedback Information
-Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, Accessing Feedback Information
- Compliance User: Industry Members
- Keywords:
- CAT Feedback,
-
- pubdate: February 28, 2019 effdate: N/A
- 6.4.1. CAT Feedback
-Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, Accessing Feedback Information, CAT Feedback
- Compliance User: Industry Members
- Keywords:
- Receipts,
- Failure Reports,
- File Submission Status,
- Reporting Statistics,
-
- Multiple types of feedback will be provided to Industry Members through various mechanisms, dependent upon the type of feedback provided.
-• Receipts - receipt of a file or the arrival of a file at the next stage of processing is provided in a feedback file. A File Acknowledgement Feedback File will be provided when each file is first received. A separate file will be generated when the file reaches each stage of processing. Processing stages (and thus feedback file types) vary based on the type of file being processed. Feedback files will be available via sftp. Receipt and feedback information will also be available via the Reporter Web Portal.
-• Failure Reports - if records in a file are rejected, if an entire file is rejected, or if there are warnings generated by a file, the feedback file will detail which records were rejected, why they were rejected, and at which stage of processing they were rejected. Note that CAT will not completely reject a file at the INGESTION stage. (Please refer to Section 7 for more details on various processing stages and feedbacks.)
-• File submission status - current processing status (whether a file has been received, which stage of processing a file is in, etc.) will be made available via the Reporter Web Portal.
-• Reporting Statistics - reporting statistics will be made available via the CAT Reporter Web Portal on a daily basis, and are posted when processing for all files has completed. The daily statistics will include, at a minimum, the following information for order events and reference data:
-• CAT Reporter ID
-• Date of Submission
-• Number of files received
-• Number of files accepted
-• Number of files rejected
-• Number of total order events received
-• Number of order events accepted
-• Number of order events rejected
-• Number of each type of report received
-• Number of each type of report accepted
-• Number of each type of report rejected
-• Number of unknown accounts
-• Number of late submissions
-• Order-IDs rejected
-• Reasons(s) for rejection
-• Number of records attempted to be matched
-• Number of records matched
-• Percentage of records matched
-pubdate: February 28, 2019 effdate: N/A
- 6.5. CAT Reporting Hours
-Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, CAT Reporting Hours
- Compliance User: Industry Members
- Keywords:
- Sec Rule 613,
- CAT NMS plan,
-
- Submission of Order Events
-Pursuant to SEC Rule 613, the CAT NMS Plan requires Industry Members to record order events contemporaneously with the actual transactions themselves. Realtime reporting to CAT is not required. Data may be bulk uploaded at the end of the Trading Day, or may be broken into multiple batches and uploaded in pieces throughout the day. However, all Reportable Events for one Trading Day must be reported to CAT by 8:00 AM Eastern Time on the next Trading Day.
-Trading Day for Industry Members is defined as:
-• Start: immediately after 4:15:00PM and no fractions of a second Eastern Time on one trade date
-• End: exactly 4:15:00PM and no fraction of a second Eastern Time on the next trade date (T=Trading Day, a defined term)9
-Note that the Trading Day is only used to determine the reporting deadline of order events. It does not impact the date on the file name (calendar day) or the date used to create linkages (date on eventTimestamp). Additional details on reporting dates and deadlines are included in Appendix D.
-CAT accepts submissions (via SFTP and Reporter Web Portal) 24 hours per day, 7 days per week, other than during announced scheduled maintenance. Events that occurred during a particular Trading Day may be reported anytime between the time the event occurred and the reporting deadline, which is 8:00 AM Eastern Time on the following Trading day. Reports received after the deadline will be marked late by CAT.
-The table below gives some examples of the reporting deadline.
- -Deadline of Rejection Repair
-Rejections willbe provided to Industry Members in the following order:
-• File Format Validation Error
-• Syntax and Semantics Error
-• Context Issues
-Once rejections are available, repairs can be made immediately.
-In order to comply with the rule, all rejections that require repair should be repaired before 8AM Eastern Time on T+3 (transaction date + three Trading Days). Repairs received after the standard repair window will be classified as late.
-If corrections are not received by 8AM Eastern Time T+5 (transaction date + five Trading Days), Participants’ regulatory staff and the SEC will be notified. The Plan Processor shall notify the Participants’ regulatory staff and the SEC as to how corrections submitted after T+5 will be re-processed. The Operating Committee will be involved with decisions on how to re-process the data.
- -Deadline for Corrections and Deletions
-Sometimes an Industry Member will have occasion to correct a report that may have passed all data validation and integrity checks. All such corrections must be submitted within the same three day timeframe as provided for record repairs. Specifically, Industry Members will be provided the same T+3 window for submitting timely corrections to data.
-pubdate: February 28, 2019 effdate: N/A
- 6.6. Security
-Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, Security
- Compliance User: Industry Members
- Keywords:
- CAT,
- Industry Member,
- Submission or Correction,
-
- In recognition of the importance of security, CAT has strict mechanisms for security controls. This section describes the CAT security overview and data security standards, to make sure the data is secured both during in transit and while stored in CAT.
-Submission to CAT requires a valid user ID and password. Industry Members must obtain a master user ID and password combination during the CAT registration process.
-Industry Members will also be assigned a multi-factor authentication (MFA) token during the registration process. An MFA token is required for authentication when accessing SFTP and Reporter Web Portal.
-Order Submission or Correction via SFTP or Reporter Web Portal must be compressed and encrypted. All communication with the web portal is done through secure HTTPS, and all such activity is captured in system logs.
-Industry Members are not allowed to view or download the actual data files from SFTP or Reporter Web Portal after submission. Data will be deleted from SFTP in a predefined time window, after it has been successfully processed and loaded into CAT data store.
-pubdate: February 28, 2019 effdate: N/A
- 6.6.1. Data Security Standard
-Topic: CAT Reporting Technical Specifications for Industry Members, Submission Process, Security, Data Security Standard
- Compliance User: Industry Members
- Keywords:
- CAT,
- CAT Private Key,
-
- In addition to data transport security provided by TLS and SSH, CAT requires that the data be secure at rest. To achieve this, CAT recommends one of the supported, industry standard tools for encryption to be used. PGP, OpenPGP, and GPG (GNU Privacy Guard), in addition to OpenSSL may be used for both symmetric and asymmetric encryption and decryption.
-Asymmetric encryption will be accomplished by the Industry Member using the Industry Member's private key and the CAT public key. Upon retrieval by CAT, the CAT private key will be used to decrypt the files. Should the Industry Member desire to be able to decrypt the data at another time, the Industry Member should encrypt with both the Industry Member's public key, as well as the CAT public key.
-Automated systems are an anticipated component of CAT submission, error retrieval, and status monitoring, and automated access is permitted in limited roles.
-CAT provides restricted automated (role based) sub-accounts with restricted access. Please note that automated access accounts must be associated with a person. These accounts will be permitted to use public security keys from their registered location. Public security keys will be registered via the Web portal, and associated with the restricted functional account. Should a Participant desire HSM support, most HSM devices allow public key extraction using commonly available tools from OpenSSL and OpenSSH, utilizing the pkcs12, ssh-keygen modules.
-pubdate: February 28, 2019 effdate: N/A
- 7. Feedback and Corrections
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections
- Compliance User: Industry Members
- Keywords:
- CAT,
- Obtaining Feedback,
-
- This section describes the procedures for obtaining feedback and how to submit corrections, including different types of feedback messages, data elements, and formats of the correction reports. After data submission, CAT will conduct data validations, provide feedback to CAT Reporting Agents and Industry Members, and allow corrections to be submitted.
-Feedback will be made available via the Reporter Web Portal, both in the form of a user-centric webpage and a programmable API.
-For descriptions in this section, the CAT will consider a file to be successfully decrypted if and only if all of the decryption, decompression, and signature validation steps succeed.
-pubdate: February 28, 2019 effdate: N/A
- 7.1. Feedback Files
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Feedback Files
- Compliance User: Industry Members
- Keywords:
- Data file,
- JSON,
- CSV,
- Feedback File,
- Reject File,
-
- For each data file, there are two types of files generated at different stage of processing and returned to the Industry Member and CAT Reporting Agent as feedback - the feedback file and the reject file.
-The format of the files will match the format of the original file submission in JSON or CSV.
-These files will be available as soon as they are generated, and accessible under the corresponding directory on the feedback sftp server for both the CAT Reporting Agent and Industry Member. They will also be made available via the Reporter Web Portal. Note that the IP address of the sftp server where files are uploaded may differ from the IP address of the sftp server where receipts and rejects are placed.
-• Feedback File
-Receipts will be available as soon as they are generated in the form of a feedback file, accessible under a subdirectory of download/feedback in both the CAT Reporting Agent’s and Industry Member’s home directory on the feedback sftp server.
-The exact subdirectory on the sftp server where feedback files may be found is:
-download/feedback/<YYYYMMDD>/<CATReporterId>/
-Where YYYYMMDD is the calendar date of the events in the submitted file.
-Feedback from different stages of processing will have different file extensions. See the following sections for more details.
-If there are failures or warnings, they will be available in the feedback file. It is possible for a record to have multiple failures, which will be represented by multiple JSON objects or new-line delimited CSV records within the failures array with the same record indexes.
-• Reject File
-If any of the ingestion failures correspond to specific records, a reject file (with extension .reject) will also be generated in the download/failures directory in the home directory of both the submitter and reporter. The reject filename will be included with the feedback record under the field rejectFile. The reject file will be populated with Correction Records containing the original rejected records and record index, to make corrections easier to submit (as described in the Corrections section). The record index is the offset from the beginning of the file to the first byte of the record.
-Feedback files will have the same base name as the submitted file. The file name will be appended with an extension describing the feedback type and .pgp. It will be compressed, encrypted, and signed. Compression will be based on the compression preferences associated with the public keys used to encrypt the feedback file. The keys used will be the CAT Reporting Agent's key, Industry Member’s key (if different), and the CAT public key. It will be signed with the CAT private key. For example, if a file was submitted from CAT Reporter “MYID”, with the following name:
-MYID_20170101_OrderEvents_000123.csv.gz.pgp
-The following would be the filename for the acknowledgement feedback file:
-MYID_20170101_OrderEvents_000123.ack.pgp
-Filenames are considered unique using the base name of the file (i.e., after removing all suffixes). Thus, trying to upload files that differ only in extension would be considered an error for uploading files with duplicate filenames.
- -If multiple files are submitted with the same base name, but with different format or compression extensions, then a _<N> will be applied to the base name of the second and subsequent feedback file names, where N will be the iteration of the feedback file.
-If multiple files are submitted with the same base name or CAT needs to provide feedback when reprocessing a file feedback, an _<N> will be applied to the base name of the feedback files to avoid overwrite of any feedback files contained at that time in the download directories.
-Feedback files will be generated as each data file goes through various stages of processing. CAT will have four main processing stages, as described below:
-1. File Acknowledgement
-2. Basic File Integrity Check
-3. Order Events - Ingestion
-4. Order Events - Linkage Discovery
-Please see the following sections for details of each stage.
-Some stages will complete almost immediately, generating feedback shortly after the file has been uploaded (e.g. File Acknowledgement stage); other stages may take significant time, meaning that feedback could be delayed (either due to queuing behind other jobs, or because certain data elements are required to advance). For file acknowledgement, basic file integrity or ingestion stages, feedback will be provided as soon as the processing of each stage is completed. However, the feedback from linkage discovery phase, due to the dependency on other reporters' order events, will not be provided prior to noon on T+1, when all feedback is required to be returned.
-The minimum retention time for feedback files on the sftp server is 10 business days; after that time they may be removed from the server. Feedback will continue to be available after that time via the Reporter Web Portal.
-Failure codes are listed in Appendix E.
-pubdate: February 28, 2019 effdate: N/A
- 7.2. File Acknowledgement
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, File Acknowledgement
- Compliance User: Industry Members
- Keywords:
- Receipt of Acknowledgment,
-
- A receipt of acknowledgement will be generated for each file and metadata pair that appears in the upload/complete directory or uploaded via the Reporter Web Portal.
-The data and metadata file should be moved into the upload/complete directory within a reasonable timeframe of each other. If a file is rejected (e.g., because the filename is not in the correct format or there is a timeout without seeing the associated data/metadata file), the receipt will contain a status of Failure and one or more failure codes with descriptions.
-Files will be removed from the upload/complete directory after they are processed, though they may not be removed immediately after processing.
-pubdate: February 28, 2019 effdate: N/A
- 7.2.1. File Acknowledgement Feedback
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, File Acknowledgement, File Acknowledgement Feedback
- Compliance User: Industry Members
- Keywords:
- CAT SUbmtter ID,
- CAT Reporter ID,
- Timestamp of Receipt,
-
- An acknowledgement feedback file will have a .ack extension and will contain the following fields:
-• CAT Submitter ID (as determined from sftp or web portal username)
-• CAT Reporter ID (as determined from filename, if available)
-• Timestamp of Receipt - timestamp file is received and receipt is generated
-• Date (calendar date as submitted from filename, if available)
-• File Name
-• Feedback Version - the version of feedback file schema
-• Status - Success or Failure
-• Failures - a repeating group of failure codes and descriptions
-• Severity - WARNING or ERROR
-• Failure Code
-• Failure Description
-The following is an example JSON object for a successful file acknowledgement:
-
- CSV presentation of a successful file acknowledgement:
-Line 0 SUBID,MYID,20170307T153552.000001089,20170307, MYID_20170307_OrderEvents_000123.json.gz.pgp,0.1,Success
-The following is an example JSON object for an unsuccessful file acknowledgement:
-
- CSV presentation:
-Line 0 SUBID,MYID,20170307T153552.000001089, 20170307,MYID_20170307_OrderEvents_000123.json.gz.pgp,0.1,Failure
-Line 1 ERROR, FILE.TIMEOUT.001, Time out waiting for meta file
-pubdate: February 28, 2019 effdate: N/A
- 7.3. Basic File Integrity
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Basic File Integrity
- Compliance User: Industry Members
- Keywords:
- Metadata File,
-
- When all the data file(s) and associated metadata file have been received, basic validation will begin. If the metadata file cannot be decrypted, a failure will be generated, and no further attempt will be made to process the file until a valid metadata file is uploaded. If there is an error for one 'block' of metadata within the file, the 'block' with the failure is dropped from processing but the remaining metadata 'blocks' and associated files will still be processed. The Industry Member can submit another metadata file with the corrected 'block' to complete processing.
-pubdate: February 28, 2019 effdate: N/A
- 7.3.1. Basic File Integrity Checks
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Basic File Integrity, Basic File Integrity Checks
- Compliance User: Industry Members
- Keywords:
- Matching Date,
- Submitter,
- Reporter,
- Encrypted Size,
- Encrypted Hash,
- Decryption,
- Compressed Hash,
- Data Hash,
-
- The values contained in the metadata file will be checked against properties of the corresponding data file. The following properties will be checked:
-• Matching Date - the date part of the filename must match the metadata Date
-• Submitter - metadata CAT Submitter ID must be the same as actual submitter (as determined from sftp or web portal username)
-• Reporter - the CAT Reporter ID part of the filename must match the metadata CAT Reporter ID
-• Encrypted Size - metadata Encrypted Byte Count must equal size of encrypted, received file
-• Encrypted Hash - metadata Encrypted Hash must equal computed SHA256 of encrypted, received file
-• Decryption - the data file must be successfully decrypted
-• Compressed Hash - computed SHA256 must equal metadata Compressed Hash, if provided
-• Data Hash - computed SHA256 must equal metadata Raw Hash, if provided
-One or both of the Compressed Hash and Data Hash must be provided. If neither are provided, then the file will be rejected.
-Note that all data elements in the metadata file are validated during this stage except Record Count, which will be validated when the file is actually processed.
-pubdate: February 28, 2019 effdate: N/A
- 7.3.2. Basic File Integrity Feedback
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Basic File Integrity, Basic File Integrity Feedback
- Compliance User: Industry Members
- Keywords:
- CAT SUbmtter ID,
- CAT Reporter ID,
- Timestamp of Receipt,
- Feedback Version,
- Status,
-
- A basic file integrity feedback file will have a .integrity extension and will contain the following fields:
-• CAT Submitter ID (as determined from sftp or web portal username)
-• CAT Reporter ID (as determined from filename)
-• Timestamp of Receipt - timestamp when receipt was generated
-• Date
-• Feedback Version - the version of feedback file schema
-• Status - Success or Failure
-• Failures - a repeating group of failure codes and descriptions
-• Severity - WARNING or ERROR
-• Failure Code
-• Failure Description
-The following is an example JSON object for a successful integrity check:
-
- CSV conversion
-Line 0 SUBID,MYID,20170307T153552.000001089,20170307,0.1,Success
-The following is an example JSON object for an unsuccessful integrity check:
-
- CSV conversion
-Line 0 SUBID,MYID,20170307T153552.000001089,20170307,Failure
-Line 1 ERROR,INT.META.001,Encrypted SHA does not match SHA in meta file.
-pubdate: February 28, 2019 effdate: N/A
- 7.4. Order Event Files
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Order Event Files
- Compliance User: Industry Members
- Keywords:
- Records,
- Order Event File,
-
- Order Event files are composed of many different types of records. Any record determined to be malformed or otherwise invalid will be rejected as a failure.
-• If the number of records in the file does not match the Record Count in the metadata file or metadata block, the entire file will be rejected.
-• If an Order Event file contains anything other than expected order event messages, the entire file will be rejected.
-Each field of the order event will be checked and validated, resulting in one of three states for the record: success, error, or warning. An error will prevent the record from being processed. A warning will not prevent the record from being processed, but may indicate that a record will be subject to errors during a later stage or processing. Depending on the type of warning, the record may be processed and ignored, or processed and applied to the data set. A record with only warning(s) but without error(s) do not require corrective action from the Industry Member.
-For example, there are occasions where symbols are “delisted” late and may already have been referenced by some Industry Members (most likely in stage two). CAT allows incremental uploads throughout the day. Thus, their order event reports may contain opens and/or cancels for those symbols. Instead of rejecting these records, CAT will generate warnings for benign order actions and silently ignore them. Execution events for such symbols, however, will generate errors.
-The system is backward compatible when there is a change or transition to a new version of reporting specifications. In such cases where the latest/preferred method is detectable, but not detrimental, a warning may be generated to inform the reporter on the details, but the record will still be accepted and processed by the system.
-pubdate: February 28, 2019 effdate: N/A
- 7.4.1. Order Event Feedback
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Order Event Files, Order Event Feedback
- Compliance User: Industry Members
- Keywords:
- Ingestion,
- Linkage Discovery,
-
- The act of processing order events has multiple stages: ingestion and linkage discovery.
-During the ingestion phase, each record will be checked for proper formatting (JSON field names and values, CSV values in proper columns, etc) and data contents. The defined JSON schemas for each record type will be used to validate every field of each record. The schema defines the format of each record and the data types and acceptable ranges of each value. In addition, it defines which fields are mandatory.
-Fields whose value depends on context (and are not defined in the schema) will be validated by explicit rules to make sure that all requirements for their processing are followed.
-Order events will be checked for both internal consistencies and valid relationships when referencing other orders or events from the same reporter.
-The full lifecycle will be generated from the full set of order events, and any order that is not fully linked will be flagged as an error.
-CAT will not completely reject a file at the ingestion or linkage discovery stage (once it passes the record count validation). Any file that passes the basic file integrity check will be fully scanned, and feedback will be provided for each of the records in the file.
-Receipts will be generated for each phase. The feedback files will have the following extensions for each stage:
-• INGESTION - .ingestion
-• LINKAGE DISCOVERY - .linkage
-The feedback files will contain the following fields:
-• CAT Submitter ID
-• CAT Reporter ID
-• Timestamp of Receipt
-• Date - Calendar date of the events/file
-• Stage - INGESTION or LINKAGE_DISCOVERY
-• Status - Success if all records in the file were accepted, Failure if some or all records were rejected, or Warning if some or all records have warnings
-• Number of Accepted Records - this stage only
-• Number of Rejected Records - this stage only
-• Reject Filename - if present, contains the relative name of the file in the downloads/failures directory containing records that were rejected.
-• Feedback Version - the version of feedback file schema
-• Failures - a repeating group, each containing:
-• Severity - WARNING or ERROR
-• Failure Code
-• Failure Description
-• Original Record Index - if applicable, the 0-based byte index of the record in the submitted file
-• Reject Record Index - if applicable, the 0-based byte index of the record in the Reject Report
-• Firm ROEID - the value reported in the firmROEID field in the original Order Event if populated (otherwise blank)
-The following is an example JSON object for a successful OrderEvents ingestion:
-
- CSV presentation:
-Line 0 SUBID,MYID,20170307T153552.000001089,20170307,INGESTION,Success,21 4513134,0,0.1
-The following is an example JSON object for an unsuccessful OrderEvents normalization:
-
- CSV presentation:
-Line 0 SUBID,MYID,20170307T153552.000001089,20170307,INGESTION,Failure,21 4513132,2,MYID_20170307_OrderEvents_000002.rejects.pgp,0.1
-Line 1 ERROR, OE.INGEST.014,Invalid value for TIF,123456,DESKP123456
-Line 2 WARNING,OE.INGEST.009,Symbol has been delisted,654321,1234, DESKC56789
-pubdate: February 28, 2019 effdate: N/A
- 7.5. Co rrectio ns
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections
- Compliance User: Industry Members
- Keywords:
- correction data files,
-
- Corrections may be made manually via the web portal or uploading correction data files. If the entire file was rejected, then corrections should be submitted as repair records.
-Corrections are due by T+3 at 8AM, where T is the CAT Trading Day. However, corrections may be made at any time, even if beyond the error correction timeframe.
-pubdate: February 28, 2019 effdate: N/A
- 7.5.1. Repair Records
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections, Repair Records
- Compliance User: Industry Members
- Keywords:
- correction data files,
- Repair of Data Files,
- Reject Files,
-
- Repair records may be submitted to correct or delete a previously submitted record. Both records that have been previously rejected and records that have already been accepted may be repaired.
-Repair records should be submitted in a repair file in the same format (JSON or CSV) as the original file requiring corrections. (Reporters will not be allowed to submit a JSON repair file if the original file was submitted in CSV and vice versa.) The repair file may contain repair records from multiple original files, as long as all repair records for the same calendar date. The repair filename must contain the same Reporter ID, date (calendar date) and marked as "OrderEvents"', with the string "Corrections" appended, as well as the sequence number of the correction file. For example, if the original filenames with errors were MYID_20170101_OrderEvents_000123.[json|csv]and MYID_20170101_OrderEvents_000130.[json|csv] then the repair filename may be MYID_20170101_OrderEvents_Corrections_000001.[json|csv].
-Metadata for the repair file may be submitted as its own meta file or as a metadata 'block' within a combined metadata file.
-Metadata for the repair record should be valid for the repair record file, not the original files being repaired. For example, the Encrypted Hash and Encrypted Size should be the hash and size of the repair record file.
-Each repair record will uniquely identify a record to repair using the 0-based index of the original record, combined with the original file number. If the record to be repaired cannot be identified, the repair record will be rejected. If a feedback file has a failure file associated with it, then the index will be pre-populated on Correction Records in the failure file to ease repair submissions. Otherwise, if correcting or deleting non-rejected records, the submitter will need to populate these fields itself.
-Reject files (as indicated by the rejectFile field on some feedback records) can be used to submit corrections. Since the files are pre-populated with Correction Records, a file only needs to be downloaded, the appropriate changes to the contents of the record(s) made, and the file submitted with the appropriate file name.
-Repair record files may contain delete and correction records only. If an invalid record type is detected in the file, then the entire file will be rejected.
-pubdate: February 28, 2019 effdate: N/A
- 7.5.2. Submitter Created Repair File Structure
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections, Submitter Created Repair File Structure
- Compliance User: Industry Members
- Keywords:
- Original Data File,
-
- In order to locate the original data file(s) to be corrected, the Reporter must list the original file numbers (of the original data file being corrected) in the metadata of the correction files. For example, if the correction file (correction file name: MYID_20170307_OrderEvents_Corrections_000001.JSON) contains the corrections or deletions for the following original data files:
-• origFileName:"MYID_20170307_OrderEvents_000123.json"(origFileNumber=000123)
-• origFileName:"MYID_20170307_OrderEvents_000130.json"(origFileNumber=000124)
-Then metadata for this correction file must include "origFileNumber": [000123,000124]
-For example:
-
- The repairs records in the correction file are organized in a record change list. The repairs should be grouped by original file number.
-
- In the CSV presentation, origFileNumber will be flattened into the first column of each line, and the repairRecords will be starting from the next columns. For the examples above, the CSV presentation will look like below.
-Line 0 000123,DEL,456
-Line 1 000123,DEL,5098
-Line 2 000124,DEL,9005
-Line 3 000124,DEL,12345
-pubdate: February 28, 2019 effdate: N/A
- 7.5.2.1. Delete Record
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections, Submitter Created Repair File Structure, Delete Record
- Compliance User: Industry Members
- Keywords:
- Record Type,
- Original Record Index,
-
- A delete record must contain the following fields:
-• Record Type - DEL
-• Original Record Index - the 0-based index of the record in the original file
-The following is an example delete record:
-
- pubdate: February 28, 2019 effdate: N/A
- 7.5.2.2. Correction Record
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections, Submitter Created Repair File Structure, Correction Record
- Compliance User: Industry Members
- Keywords:
- Record Type,
- Original Record Index,
- Replacement Record,
-
- A correction record must contain the following fields:
-• Record Type - COR
-• Original Record Index - the 0-based index of the record in the original file
-• Replacement record - the corrected record
-The following is an example correction record:
-
- pubdate: February 28, 2019 effdate: N/A
- 7.5.2.3. Repair File Sample
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections, Submitter Created Repair File Structure, Repair File Sample
- Compliance User: Industry Members
- Keywords:
- JSON,
-
- Please see a sample of a repair file in JSON below:
-
- CSV presentation:
-Line 0 000123,DEL,456
-Line 1 000123,DEL,457
-Line 2 000124,COR,567,MENO,CORO98765,20170801T143031.123456,false,,, XYZ,O12345,N,O,,Buy,10.01,500,,LMT,DAY,REG,,false,PROP456,O,,, false,N,,,,,,,,,,,
-pubdate: February 28, 2019 effdate: N/A
- 7.5.3. rejectFile (CAT Provided) Format
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections, rejectFile (CAT Provided) Format
- Compliance User: Industry Members
- Keywords:
- CAT Provided Format,
-
- The rejectFile that can be accessed in downloads/failures will be pre-populated with Correction Records. Below is an example of the rejectFile:
-
- In the example above, two correction records are included and pre-populated with the original records as they were submitted. The submitter or reporter may simply modify the erroneous data elements, rename the file and submit it to CAT as the correction file.
-Below is the CSV format presentation.
-Line 0 COR,567,MENO,DESK98765,20170801T143031.123456,false,,,XYZ,O12345, N,O,,Buy,10.01,500,,LMT,DAY,REG,,false,PROP456,O,,,false, N,,,,,,,,,,,
-Line 1 COR,8965,MENO,DESK12345,20170801T143035.123456,false,,,ABC,O56789, N,O,,Buy,100.01,200,,LMT,DAY,REG,,false,PROP456,O,,,false, N,,,,,,,,,,,
-pubdate: February 28, 2019 effdate: N/A
- 7.5.4. Repair Record Feedback
-Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections, Repair Record Feedback
- Compliance User: Industry Members
- Keywords:
- Record Files,
-
- Repair record files will receive the same types of feedback as the file being repaired. Feedback for the repair records will be provided no later than noon T+3.
-Note that if one record needs to be corrected more than once, all corrections must refer to the original record by the original file number (origFileNumber) and record index (recordIdx). If multiple corrections are submitted for one original record, the most recent correction - the correction file with the highest file number - will be treated as the valid version.
-For example, if the Reporter submits a correction for original file MYID_20170307_OrderEvents_000123 (fileNumber = 000123, recordInd = 456) in a correction file MYID_20170307_OrderEvents_Corrections_000001. And later the Reporter desires to correct the same record again that overwrites the previous correction. Then the second correction (correction file name: MYID_20170307_OrderEvents_Corrections_000009) must still reference to the original file number and record index - fileNumber 000123 and recordInd 456. Between the two correction files, the one with larger file number (000009) will be treated as the most recent valid version of the record.
-pubdate: February 28, 2019 effdate: N/A
- 8. Testing
-Topic: CAT Reporting Technical Specifications for Industry Members, Testing
- Compliance User: Industry Members
- Keywords:
- CAT,
- Industry Member,
- CAT System,
-
- CAT will provide an environment for testing that mirrors the current functionality of the CAT production environment, as well as including functionality for the next release version of the CAT environment when available. The CAT testing environment will automatically determine which specification version Industry Members and CAT Reporting Agents are using for submissions. If error reporting formats change, Industry Members and CAT Reporting Agents will receive feedback in the current and new specification via ftp, as well as have access to current/new web portal urls for specification changes that impact the web portal. Current/new connectivity changes will also be supported concurrently.
-The testing environment performs lifecycle linkage, and Industry Members and CAT Reporting Agents are encouraged to coordinate testing with their counterparties so as to test lifecycle linkage with their counterparties. Without simultaneous contra-party reporting in the test environment, Industry Members and CAT Reporting Agents will not be able to test linkage with their counterparties.
-Industry Members and CAT Reporting Agents should test their submissions using the testing environment before they begin submitting to the production environment.
-The test environment is available 24 hours a day, 6 days a week. Refer to the CAT website for contact information and hours of operation for support.
-Industry Members and CAT Reporting Agents connect to the test environment in the same manner they would connect to the production environment. However, for the connection to the test environment, one or more alternate IP/domains may be used.
-Testing does not relieve an Industry Member of its responsibilities to submit production data to the CAT System.
-pubdate: February 28, 2019 effdate: N/A
- 9. Additional Information
-Topic: CAT Reporting Technical Specifications for Industry Members, Additional Information
- Compliance User: Industry Members
- Keywords:
- Public Website,
-
- pubdate: February 28, 2019 effdate: N/A
- 9.1. Public Website
-Topic: CAT Reporting Technical Specifications for Industry Members, Additional Information, Public Website
- Compliance User: Industry Members
- Keywords:
- www.catnmsplan.com,
-
- The CAT Public Website, www.catnmsplan.com, is available via the public internet, and is hosted outside the CAT secure network. The CAT Public Website provides information about the CAT, such as a link to SEC Rule 613, Technical Specifications, FAQs, training materials, and CAT Help Desk contact information.
-Web announcements will be made available on the public website (www.catnmsplan.com). You can also subscribe to receive email notifications regarding changes to the website. These announcements are used to post information related to the operation of CAT.
-Please contact CATNMSIO@deloitte.com for any questions and/or feedback regarding this document.
-pubdate: February 28, 2019 effdate: N/A
- Appendix
-Topic: CAT Reporting Technical Specifications for Industry Members, Appendix
- Compliance User: Industry Members
- Keywords:
- Change Release Management Process,
- Clock Synchronization Requirement,
- Representative Order Linkages,
- CAT Date Definitions and Reporting Guidelines,
- Failure Codes,
-
- A. Change Release Management Process
-Following publication of version 1.0, changes to this Industry Member Technical Specification will be released as follows:
-• All proposed amendments to the Technical Specifications will be made in accordance with the CAT NMS Plan, including being approved or deemed approved (as applicable) by the CAT NMS, LLC Operating Committee.
-• Prior to the go-live date for any system changes set forth in the Technical Specifications:
-o A new Technical Specifications will be posted to the CAT Public Website, www.catnmsplan.com.
-o A notice will be posted on the CAT NMS Plan Public website with a summary of changes, the go-live date for the changes and links to relevant information.
-o One or more email alerts will be sent to CAT Reporters with a summary of changes set forth in the revised Technical Specifications, the go-live date for the changes and links to relevant information.
-o Industry Members will be permitted to perform testing of the revised Technical Specifications in advance of the go-live date for the changes. [Information on such testing will be set forth in the notices and alerts described above.]
-o As the go-live date approaches, Industry Members will be able to conduct testing and will receive support from the Plan Processor to prepare for production reporting using the revised Technical Specifications format. The revised Technical Specifications will include a summary list of changes as well as a table listing the specific areas of the document where the changes have been made.
-B. Clock Synchronization Requirement
-In previous sections, details are described regarding Order Events and data elements. Timestamp, as one of the required data elements for each order event, must be correctly reported by Industry Members at predefined granularity. This section provides an overview of the corresponding clock synchronization requirements applicable to Industry Members.
-In order to comply with applicable requirements of Clock Synchronization and correctly record the Timestamp fields for order events. Industry Members are required to synchronize Business Clocks at a minimum to within 50 milliseconds of the time maintained by the National Institute of Standards and Technology (NIST) and to maintain such synchronization. Business clocks that are solely used for Manual Order Events or for the time of allocation on Allocation Reports must be synchronized at a minimum to within a one second tolerance.
-The tolerance includes:
-• The difference between the NIST standard and a time provider’s clock;
-• Transmission delay from the source; and
-• The amount of drift in the Participant's clock.
-To ensure the accuracy of timestamps for Reportable Events, Industry Members must document and maintain their synchronization procedures for Business Clocks. Industry Members must keep a log of the time when they synchronize their Business Clocks and the results of the synchronization process. This log should include notice of any time a Business Clock drifts more than the applicable tolerances specified above. Such log must include results for a period of time 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 Rule if less than five years. Industry Members must also certify their compliance with these clock synchronization requirements and report violations according to requirements established by the Operating Committee.
-Any time provider and technology may be used for clock synchronization as long as the Business Clocks are in compliance with the accuracy requirement.
-If additional details are needed, please refer to the Clock Sync User Guide to be published, or to Participants' applicable rules.
-Note: The tolerance for clock synchronization does not impact the amount of time allowed for CAT reporting. CAT does NOT require Industry Members to report order information within 50 milliseconds of receiving an order.
-C. Representative Order Linkages
-The CAT NMS Plan requires that customer orders be linked to representative orders created in firm accounts for the purpose of facilitating the execution of a customer order. This Appendix outlines reporting requirements for creating linkages between customer and representative orders.
-Phase 2a Requirements
-1. Representative Order Reporting
-In Phase 2a, representative orders must be reported to CAT and marked as a representative order. Representative orders are identified using the representativeInd field on New Order events.
-Allowed values for this field include:
-Y Representative order, linkage required
-YS Representative order, linkage required; details in supplement event
-YF Representative order, linkage required in future phase
-YP Representative order, pricing guarantee, linkage not required
-N Not a representative order
-O Options Combined Order
-2. Representative Order Linkages
-In Phase 2a, linkage is required between the representative street side order and the order being represented when the representative order was originated specifically to represent a single order (received from a customer or another broker-dealer) and there is:
-1) an existing direct electronic link in the Industry Member's system between the order being represented and the representative order, and
-2) any resulting executions are immediately and automatically applied to the represented order in the Industry Member's system
-Linkages are required between the customer/clients order and the representative order for both executed and unexecuted orders. Executed orders must also have a link between the Order Fulfillment Event for the customer/client order and the representative order from which the fill came.
-The following fields are used in the linkage process:
-At the Order Level
-• representativeInd indicates if an order was originated to represent a customer/client order
-• aggregatedOrders specifies the original order IDs and quantities being consolidated in the representative order
-At the Order Fulfillment Level
-• orderID contains the firm side order that was used to fill the customer order
-• fulfillmentLinkType indicates whether there is order level and trade level linkage, only trade level linkage (e.g., fill from the pre-existing customer order), or why the firm side details are not present
-Representative Order Marking and Linkage Requirements by Phase
-Single Order Scenarios
-The table below details requirements for both linkage and marking of a Representative Order in Single Order scenarios. These requirements are NOT applicable in situations where an electronic link does not exist between the Industry Member's OMS and EMS. Please refer to Data Dictionary for relevant field values. Pease refer to the CAT Industry Member Reporting Scenarios document for further information on how the relevant field values should be populated for each scenario.
-
-
- Aggregated Order Scenarios
-[Placeholder for Phase 2c. Aggregated Order Reporting will be finalized and included in future version of the specification.]
-D. CAT Date Definitions and Reporting Guidelines
-The following key date terms are used throughout the document for reporting instructions:
-• eventTimestamp: The time of the order handling or execution pursuant to Section 6.8 of the CAT NMS Plan (e.g. origination, receipt, etc., depending on the respective order event). The time is reported as per the calendar date of the order event.
-• date (Linkage Keys): The date used for linkage keys is the date portion of the eventTimestamp (calendar date)10.
-• date (File Name): The date used to create file names is the calendar date for all events in the file. The file must only contain records with the same calendar date as the file name.
-• CAT Trading Day: Trading Day for Industry Members is defined as beginning immediately after 4:15:00PM and no fractions of a second Eastern Time on one trade date and ending at exactly 4:15:00PM and no fractions of a second Eastern Time on the next trading date.
-• CAT Reporting Due By Date: All events that occurred by 4:15PM on one Trading Day must be reported by 8:00AM the following Trading Day.
-Order Event Times and Reporting Deadlines
-The table below illustrates the reporting deadlines for Order Events across multiple calendar days and CAT Trading Days.
-
- Order IDs must be unique within the same calendar date. In the table above, the orderID in row 1 and 2 are distinct since both orders have a calendar date of 9/12. The Trading Day is not used for determining orderID uniqueness, as illustrated in rows 5 and 6.
-The Trading Day for Industry Members is defined as starting 1 millisecond after 4:15PM on one trade date and ending 4:15PM on the next trade date. As shown in rows 1 and 2, events with a timestamp after 4:15PM (row 2) are considered to be the following trading date and are not due until T+1 at 8:00AM. Alternatively, Industry Members may submit one file one file per calendar day (the orders on rows 1 and 2 can both be submitted on a 9/12 file). The Trading Day only exists to determine the reporting deadline of an event, it does not impact the date used to create linkage or the file name.
-Weekends are excluded from Trading Days. Events from 4:15PM on a Friday to 4:15PM the follow Monday are the same Trading day, but files must be separated by the calendar date (see rows 4, 5, and 6).
-Holidays are also excluded from Trading Days. Hypothetically, if Monday 9/17 were are holiday in the example, the next available Trading Day becomes Tuesday 9/18.
-
- E. Failure Codes11
-The failure code is a machine-parseable string of why a file or record was rejected.
-Each failure code is divided into a failure category, sub-category and value, joined together by a period.
-<category>.<sub-category>.<value>
-• Category and sub-category are defined as the table below. Each category corresponds to the stage of processing at which a file or record was rejected.
-• Value will be an alphanumeric (12) code that represents a specific error or warning. The list of values will be refined and a complete list of codes and descriptions will be provided.
-
- A failure code may be used for warnings or errors, distinguished by the severity field in the failure report. The failure code itself does not distinguish between a warning (in which a record is accepted but still shows up in the feedback report) and an error (which causes a record to be rejected).
-A failure description is a human readable field returned with a failure code that informs a user which field failed, the value which was submitted (if applicable to the error), and why it is incorrect. The failure descriptions are specific to the type of field that has a failure and the original value used by the reporter.
-For example, the following failure code tells the user the severity is an error, the failure was identified on an Order Event file during the ingestion stage, and the field originalOrderID is missing from the record.
-
- The following failure code example was also identified on an Order Event file during the ingestion stage. The description informs the user that the value submitted is invalid as it was more than 40 characters in length.
-
- Below is a sample of Failure Codes/Descriptions.
-Not that this is not the final list nor a complete list. The code values will be refined to lower granularities.
-
- F. Glossary
- -G. Data Dictionary
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- | fn |
- 1 Customers are defined in SEC Rule 613(j)(3) as: (i) the account holder(s) of the account at a registered broker-dealer originating the order; and (ii) any person from whom the broker-dealer is authorized to accept trading instructions for such account, if different from the account holder(s). - |
| fn |
- 2 In order to create the linkage key between Industry Member Order Route Event (potentially Order Modify Route Event in 2c) and Participant Order Modified event, a change is planned for future phases of the Participant reporting - adding routingParty, session and routedOrderID to Participant Order Modified event. - |
| fn |
- 3 Please see FAQ G4 (https://www.catnmsplan.com/faq/#faqManOrd) for additional information. - |
| fn |
- 4 Note - this document refers to orders received from CAT Reporters as "client orders," and orders received from non-CAT Reporters, including non-US broker-dealers, as "customer orders." - |
| fn |
- 5 A representative order is an order originated in a firm owned or controlled account for the purpose of working a customer/client order. Please see FAQ F1 (https://www.catnmsplan.com/faq/#faqRepOrd) for additional information. - |
| fn |
- 6 “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. “Electronic Paired Option Orders” mean electronic option orders that contain both the buy and sell side that is routed to another Industry Member or exchange for crossing and/or price improvement as a single transaction on an exchange. 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. -For more details, please refer to the CAT FAQ K2 (https://www.catnmsplan.com/faq/#faqOpt). - |
| fn |
- 7 For Industry Members reporting in CSV, the greyed out data elements will take empty columns if not populated. - |
| fn |
- 8 Note - this document refers to orders received from CAT Reporters as "client order," and orders received from non-CAT Reporters, including non-US broker-dealers, as "customer orders." - |
| fn |
- 9 Note that the Trading Day definition for Participants is different. It starts on 1 millisecond from 12:00AM of T, and ends at 12:00AM of T+1. - |
| fn |
- 10 In the scenario when an order event needs to be linked to a prior event on a different date - e.g. modify a GTC order on a prior day - an additional field “priorOrderDate” is reported on the event and will be used in linking. However, it doesn’t impact the eventTimestamp or date in file name of the event itself. - |
| fn |
- 11 Note that this section provides the structure of how failure codes are generated and concatenated. A final list of specific values and descriptions will be published when finalized. - |
SEC RULE 613 ROLLOUT PLAN
+Event: CAT Processor Selected by NMS Plan Participants
+Implementation Date: Within two months after effectiveness of the approved NMS Plan (January 17, 2017)
+Event: Business Clock Synchronization for SROs and Broker-dealers
+Implementation Date: Within four months after effectiveness of the approved NMS Plan (March 15, 2017)
+Event: SROs begin submitting data to the central repository
+Implementation Date: Within one year after the effectiveness of the approved NMS Plan (November 15, 2017)
+Event: SROs must implement enhanced surveillance using CAT data
+Implementation Date: Within 14 months after effectiveness of the approved NMS Plan (January 15, 2018)
+Event: SRO members, except small members, must being submitting data to central repository
+Implementation Date: Within two years after effectiveness of the approved NMS Plan (November 15, 2018)
+Event: Small SRO members must begin submitting data to the central repository
+Implementation Date: Within three years after effectiveness of the approved NMS Plan (November 15, 2019)
jurisdiction: US
regulatory_authority: US/SEC
- content_type: periodic
- document_title: CAT NMS, LLC Advisory Committee
- document_type: Advisory
- source: US/SEC/Advisory/LLC Advisory Committee
- source_type: LLC Advisory Committee
+ content_type: compilation
+ document_title: CAT Participant Technical Specifications v1.7.1
+ document_type: Specifications
+ source: US/SEC/Specifications/Technical Specifications
+ source_type: Technical Specifications
language: English
citation: N/A
- pubdate: February 28, 2019 effdate: N/A
- CAT NMS, LLC Advisory Committee
-Topic: CAT NMS Plan, News, CAT NMS, LLC Advisory Committee
- Compliance User: Broker-dealers
+ pubdate: September 09, 2018 effdate: N/A
+ CAT Participant Technical Specifications v1.7.1
+Topic: CAT Participant Technical Specifications v1.7.1
+ Compliance User: Self-Regulatory Organizations
Keywords:
- SRO,
- CAT NMS Plan -Section 4.3,
+ Consolidated Audit trail,
CAT NMS plan,
- Role,
- Member,
- Organization,
+ Sec Rule 613,
- The CAT NMS Plan requires the establishment of an Advisory Committee to advise the SROs on the implementation, operation, and administration of the CAT, including items such as technical specifications, reporting functionality, and the possible expansion of the CAT to other securities.
-The SROs have selected the following individuals, as per section 4.13 of the CAT NMS Plan, to serve on the Advisory Committee:
- +CAT Reporting Technical
+Specifications for
+Participants
+09/09/2018
+Version 1.7.1
+pubdate: September 09, 2018 effdate: N/A
+ Executive Summary
+Topic: CAT Participant Technical Specifications v1.7.1, Executive Summary
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT NMS plan,
+ Sec Rule 613,
+
+ The CAT is a Consolidated Audit Trail that tracks orders throughout their lifecycle and identifies the exchanges and broker-dealers handling them, thus allowing regulators to more efficiently and accurately track activity in eligible securities — those under the jurisdiction of the Securities and Exchange Commission (the "SEC") — throughout the U.S. markets. The CAT is created by a joint plan (CAT NMS Plan) of the Plan Participants or simply "Participants."
+Participants are required to report order events into CAT. Reportable order events include, but are not limited to: accepted orders, routes, replaced orders, canceled orders and executions. All Participants are responsible to submit reference information, including the symbols that are active for the exchange on a particular day, and the Participants' member list.
+This document provides Participants with information to understand their responsibilities to comply with SEC Rule 613 and CAT NMS Plan, and describes the requirements for reporting data to CAT, including detailed information about data elements and file formats of each reportable event. It also describes how Participants should submit files to CAT, including access instructions, network and transport options, and testing requirements.
+This document does not include information for Industry Members. A separate document, CAT Reporting Technical Specifications for Industry Members, will be published to provide technical specifications for Industry Members.
+Contents and Structure
+
+ Revision / Change Process
+
+ pubdate: September 09, 2018 effdate: N/A
+ 1. Introduction
+Topic: CAT Participant Technical Specifications v1.7.1, Introduction
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT Reporting Technical Specifications,
+ Industry Members Reporting Order Events,
+
+ This document provides Participants with the necessary information to fulfill their reporting obligations to CAT in compliance with SEC Rule 613 and the CAT NMS Plan.
+The document is structured as follows:
+Section 1 Introduction provides an overview of the document, rules and requirements, compliance dates, and change release management processes. In addition, it provides descriptions of identifiers and data types referenced in this document.
+Section 2 Reference Data describes details for reporting member information, equity symbols, options symbols and corporate actions.
+Section 3 Special Data Elements and Common Events provides detailed descriptions of reportable data elements that are common to multiple events, and how linkages and lifecycles are created.
+Section 4 Events for Stock Exchanges provides details regarding the data which must be reported to CAT by each stock exchange Participant. In particular, it details out the Reportable Order Events, explains what data elements are necessary and how those elements are to be collected and reported to CAT.
+Section 5 Events for Options Exchange provides details regarding the data which must be reported to CAT by each options exchange Participant. In particular, it details out the Reportable Order Events, explains what data elements are necessary and how those elements are to be collected and reported to CAT.
+Section 6 Other Reporting provides reporting requirements and data elements for events that are not covered in sections 4 and 5 (e.g., TRF reporting).
+Section 7 Stock Exchange Examples and Section 8 Option Exchange Event Examples provide a representative sample of reporting scenarios and examples for both stocks and options. In each scenario, a detailed description is provided of the reportable order events, which data elements should be reported in each event and how the files are formatted. These sections are intended to provide reporters with a set of examples regarding reportable data elements and formats.
+Section 9 CAT Submission Process provides information regarding data formats and how to submit information and files to CAT. It includes a general data flow overview, registration process, network and transport options, and CAT feedback access and reporting hours. Additionally, an overview of CAT data security standards is provided. In this section, reporters can get detailed instructions of how to connect and submit information to CAT.
+Section 10 Feedback and Corrections describes the procedures for reporters to obtain feedback following data submission, and how to submit corrections if necessary. This section addresses feedback files, file acknowledgement, basic file integrity, and feedback for reference data and order events. It also describes information on how to submit corrections and repairs to CAT.
+Section 11 Testing describes the technical details of the test environment and testing procedures required of reporters. All reporters are required to test their submissions thoroughly before submitting to the CAT Production environment.
+Section 12 Additional Information provides descriptions about the CAT public website and how to get help from the Service Desk.
+Appendix sections provide important supplemental details including:
+A. Clock Synchronization Requirements provide information on how each Participant is expected to maintain the required granularity and accuracy of the Business Clock.
+B. Failure Messages will come in the form of a machine-parseable description of why a file or record was rejected
+C. Corporate Action Formats will be reported by each exchange as-is. Examples from various exchanges are listed in this section.
+D. FINRA Trade Reporting Facility ("TRF") Fields
+E. Market Move Scenarios which includes use cases for symbol renames and movement between exchanges
+F. Encryption Example which provides an example of how to submit encrypted files
+G. Data Dictionary that includes detailed explanations and definitions of each data reference used throughout the technical specifications.
+pubdate: September 09, 2018 effdate: N/A
+ 1.1. Rule Overview / Requirements
+Topic: CAT Participant Technical Specifications v1.7.1, Introduction, Rule Overview / Requirements
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Rule 613,
+ Securities Exchange Act of 1934,
+ Self-Regulatory Organizations,
+ National Market System (‘NMS’) plan,
+
+ As previously stated, this document does not include information for Industry Member reporting. A separate document - CAT Reporting Technical Specifications - Industry Members Reporting Order Events - will be provided for this purpose.
+pubdate: September 09, 2018 effdate: N/A
+ 1.1.1. SEC Rule 613
+Topic: CAT Participant Technical Specifications v1.7.1, Introduction, Rule Overview / Requirements, SEC Rule 613
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT NMS plan,
+
+ The Securities and Exchange Commission approved to adopt Rule 613 under the Securities Exchange Act of 1934 to require national securities exchanges and national securities associations (Self-Regulatory Organizations or SROs) to submit a national market system (‘NMS’) plan to create, implement, and maintain a consolidated order tracking system, or consolidated audit trail, with respect to the trading of reportable securities — all NMS securities and over the counter ("OTC") Equity securities under SEC jurisdiction — that would capture customer and order event information for orders in reportable securities, across all markets, from the time of order inception through routing, cancellation, modification, or execution.
+Refer to SEC Rule 613, available at: https://www.sec.gov/News/PressRelease/Detail/PressRelease/1365171483188 for more details.
+pubdate: September 09, 2018 effdate: N/A
+ 1.1.2. CAT NMS Plan
+Topic: CAT Participant Technical Specifications v1.7.1, Introduction, Rule Overview / Requirements, CAT NMS Plan
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT Public Website,
+
+ After a series of amendments since the initial CAT NMS Plan was filed on September 30, 2014, the Commission unanimously approved the CAT NMS Plan on November 15, 2016.
+As per the Plan, Participants must begin reporting to CAT by November 15, 2017.
+For additional information, please refer to CAT NMS Plan at http://www.catnmsplan.com/.
+pubdate: September 09, 2018 effdate: N/A
+ 1.2. Change Release Management Process
+Topic: CAT Participant Technical Specifications v1.7.1, Introduction, Change Release Management Process
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT,
+
+ Changes to this technical specification will be released as follows:
+• Prior to the go-live date for system changes
+- A new specification will be posted to the CAT Public Website
+- A notice will be posted on the website with a summary of changes and links to relevant information.
+- One or more email alerts will be sent to reporting firms with a summary of changes and links to relevant information.
+- In some cases, CAT may accept production reporting using the new specification in advance of the go-live date.
+- Firms that have not conducted testing or production reporting using the new technical specification format will receive support from CAT as the go-live date approaches.
+• The new technical specification will include a summary list of changes as well as a table listing the specific areas of the document where the changes have been made.
+pubdate: September 09, 2018 effdate: N/A
+ 1.3. CAT Identifiers
+Topic: CAT Participant Technical Specifications v1.7.1, Introduction, CAT Identifiers
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT Reporter ID,
+
+ CAT uses a number of identifiers, many of which readily convey their meaning from the context in which they are used. The subsections below include terms associated with the entities that will report data into the CAT and their respective roles. As shown in the diagram below, Exchange ID is a subset of Participant ID, which is a subset of Reporter ID.
+
+ pubdate: September 09, 2018 effdate: N/A
+ 1.3.1. Reporter ID
+Topic: CAT Participant Technical Specifications v1.7.1, Introduction, CAT Identifiers, Reporter ID
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Participant ID,
+
+ Each entity which reports into CAT will be assigned a unique identifier: a CAT Reporter ID. This ID will uniquely identify each reporter, including plan participants, participant members, and associated reporting facilities. The database of CAT Reporter IDs will be made available both as a downloadable file on the CAT website and through the web portal API.
+pubdate: September 09, 2018 effdate: N/A
+ 1.3.2. Participant ID
+Topic: CAT Participant Technical Specifications v1.7.1, Introduction, CAT Identifiers, Participant ID
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Exchange ID,
+
+
+ The Participant ID is an ID assigned by CAT to each plan participant. The value will be the same as the participant's Reporter ID. However, the use of Reporter ID could be any CAT reporter, while the use of Participant ID means the Reporter ID of a plan participant only.
+pubdate: September 09, 2018 effdate: N/A
+ 1.3.3. Exchange ID
+Topic: CAT Participant Technical Specifications v1.7.1, Introduction, CAT Identifiers, Exchange ID
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ SRO,
+ CAT,
+ Member Alias,
+ CAT Reporter ID,
+
+ The Exchange ID is an ID assigned by CAT to each stock/options exchange. The actual value will be the same as the exchange Participant ID and Reporter ID, but, as indicated in the diagram, Exchange ID is a subset of Participant ID, which is a subset of Reporter ID.
+pubdate: September 09, 2018 effdate: N/A
+ 1.3.4. Member Alias
+Topic: CAT Participant Technical Specifications v1.7.1, Introduction, CAT Identifiers, Member Alias
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ ASCII decimal 61, hex 3D,
+ ASCII decimal,
+ 124, hex 7C,
+ ASCII 44, hex 2C,
+ ASCII decimal 34, hex 22,
+
+ Each SRO will assign unique IDs to its industry members. These IDs are essentially aliases for CAT reporters so that reporting firms can use existing identifiers when reporting market events to CAT. It is important that both the member and SRO are aware of the assigned IDs and when they should be used in various reports to CAT.
+Each SRO has autonomy in assigning their IDs, and the same ID could possibly be assigned to different industry members across SROs. Furthermore, a particular member may have multiple aliases assigned by the same SRO. Thus, the alias is only valid in combination with the SRO that assigned the ID. Specifically, when an exchange receives a routed order from one of its members, both the routing member and the exchange must report the same Member Alias in their reports to CAT in order to properly link the reports to the same order lifecycle.
+An industry member can wind up having the same alias value assigned by multiple SROs. This is fine because when an alias is used, it is always used in a manner that identifies the SRO that assigned the alias (either by explicit designation, or implicitly by context).
+For example, consider three firms (Firm A, Firm B, and Firm C) and three SRO participants (Participant A, Participant B, and Participant C), and the following table of SRO-assigned member IDs.
+ +Note that Member Alias FRMA is assigned to Firm A by both Participant A and Participant C, and Member Alias FRMB is assigned to two different firms by two different participants. While the same alias is used multiple times, these are valid mappings because the same alias is not assigned multiple times within a participant. Also note that Firm B is not a member of Participant B, and so there is no corresponding mapping.
+Thus, each firm will have at least one alias for each SRO in which they have membership. The value may or may not be the same across all participants. When Participant A refers to Firm C, it will use the alias FRMC. Likewise, when Firm C refers to itself in relation to Participant A, it will use the alias FRMC.
+Note that industry members can have multiple Member Aliases, but they will also be assigned a unique CAT Reporter ID. CAT will handle mapping the various SRO-assigned Member Alias values to synchronize them to the same unique CAT Reporter ID assigned to the member firm. Further, note that member dictionary entries apply to data uploaded for the same business date as the member dictionary itself (values do not have to be the same from day to day).
+pubdate: September 09, 2018 effdate: N/A
+ 1.4. Name Value Pairs
+Topic: CAT Participant Technical Specifications v1.7.1, Introduction, Name Value Pairs
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT,
+ JSON,
+ CSV,
+
+ Some fields are described as containing name/value pairs. This means a list of zero or more attributes, where each attribute is either a name with no value, or a name with an accompanying value such that the name and value are separated by a single equal sign (ASCII decimal 61, hex 3D). Multiple attributes are separated by the pipe symbol (ASCII decimal 124, hex 7C). If an attribute is boolean in nature, it can optionally be represented as a name alone, where its value is implied by its presence (true) or absence (false).
+The name part is the string up to the first pipe symbol or equal sign. Names must not contain commas (ASCII 44, hex 2C), pipes, equal-signs, or double-quotes (ASCII decimal 34, hex 22).
+If the name terminates with a pipe, it is a boolean value, and its presence indicates true. If the name terminates with an equal sign, the value must follow.
+The value part is the string starting with the character just after the equal sign, up to either a pipe symbol or the end of the string. Values may contain an equal sign, but must not contain commas, pipes or double-quotes.
+In some cases, the names are free-format, in that they are not defined in the specification. This means that both the name and any value are left up to the discretion of the reporter and the contents are not validated by CAT. Most common, however, is that both the name and the expected values are known, documented in this specification, and validated by CAT.
+For example, the following JSON represents a hypothetical name/value pair field, with a boolean attribute and a price attribute: { "data": "XYZ|ABC=12.55" }
+The above format works for both JSON and CSV data entry. However, when submitting data in JSON, a more native JSON style can optionally be used by assigning a JSON object as the value for a Name Value Pair attribute. Note, however, that boolean values must be explicitly set. The above example can alternatively be submitted as:
+{ "data": { "XYZ": true, "ABC": 12.55 } }.
+pubdate: September 09, 2018 effdate: N/A
+ 1.5. Fundamental Data Types
+Topic: CAT Participant Technical Specifications v1.7.1, Introduction, Fundamental Data Types
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT,
+ Section 10,
+
+ CAT will accept two kinds of text-based files: JSON and CSV. The fundamental data types used throughout this document are described below. Other data types are defined in the Data Dictionary.
+To support both JSON and CSV submissions, CAT will publish a JSON schema file which describes each data type with required representation formats, and a mapping that defines the position in a CSV representation that the data element would assume.
+A schema will be provided for each data object that can be reported in both JSON and CSV.
+When a data field is marked as either optional or conditional, some records may not provide values for that field. In such a case, the field is simply not reported as part of the JSON record, or reported as an empty column of a CSV record.
+Data Types
+
+ 
+ pubdate: September 09, 2018 effdate: N/A
+ 1.5.1. Data Validation
+Topic: CAT Participant Technical Specifications v1.7.1, Introduction, Fundamental Data Types, Data Validation
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ supplemental data,
+
+ All data submitted to CAT will be validated based on the defined data type of each item, including proper formatting and range checking. Examples of accepted values are detailed in the above table in section 1.5. Valid values for Choice fields are defined in the Data Dictionary for each data element. Valid data values, ranges, and formats will be specified in the record schema files, which will be used to validate submitted data element values. Records and values which fail validation will be marked as a failure and will be reported as feedback to the Submitting Member as detailed in section 10.
+pubdate: September 09, 2018 effdate: N/A
+ 2. Reference Data
+Topic: CAT Participant Technical Specifications v1.7.1, Reference Data
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ SRO,
+ CAT,
+ CAT web GUI,
+ Member Alias,
+
+ This section describes the various pieces of reference or supplemental data required to be reported by each participant.
+pubdate: September 09, 2018 effdate: N/A
+ 2.1. Member Information
+Topic: CAT Participant Technical Specifications v1.7.1, Reference Data, Member Information
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT,
+ OTC equities,
+ FINRA,
+ JSON,
+
+ Each SRO must submit to CAT a directory of information for each industry member with which it has a reporting relationship. Each dictionary entry identifies a specific industry member, and assigns one or more IDs to that member. These IDs may be used by the SRO and/or the member when reporting order events to CAT. In general, the industry members listed in the dictionary will also be participant members of the SRO, but this is not always the case. For example, each industry member that submits an order to an exchange must be a registered member of that exchange. However, the exchange may route orders to an industry member that is not a member of that exchange. In either case, the exchange must give at least one Member Alias to each industry member which may appear in any of the order events reported to CAT.
+Furthermore, certain internal systems or non-industry members may need to be reported to CAT with known identifiers. Such entities will be registered via the CAT web GUI. At the time of registration, a unique ID will be issued for that system, which can be used in the daily membership dictionary.
+Each member may have multiple aliases, but a specific Member Alias may only be assigned once per SRO. Note that the member dictionary is loaded each day, and the values only apply to that trading day. Thus, Member Aliases could be reassigned on subsequent trading days.
+The data will be uploaded as a file of newline-delimited JSON objects, one object per member entry. The member dictionary is necessary to process other file uploads, and must be uploaded to CAT no later than 6:00AM Eastern, with entries sufficient to support all reports submitted on that trading day (this is a same-day upload requirement whereas order events are required to be reported by 8:00AM Eastern the following trading day).
+Member Dictionary Entry
+
+ 
+ The Inactive status can be used if a Participant wants to report a member who may have been temporarily deactivated. If a member is removed, the member may be reported as Inactive or may be not reported at all.
+The following example shows a potential member dictionary for exchange Exch1 where the first entry represents an industry member that is also a member of the reporting SRO, the second entry represents an industry member that is not a member of the reporting SRO, and the third entry represents the SRO itself, with various facilities that have been given Member Alias values.
+{
+"type": "MDE",
+"reporter": "Exch1",
+"ID": "1234567",
+"status": "Active",
+"memberAliases": [ "FRMA", "FRMA1", "FRMA:U01", "FRMA:U02" ]
+}
+{
+"type": "MDE",
+"reporter": "Exch1",
+"ID": "7654321",
+"status": "NonMember",
+"memberAliases": [ "FRMB" ]
+}
+{
+"type": "MDE", "reporter": "Exch1", "ID": "123xyz", "status": "Internal", "memberAliases": [ "XXX" ]
+}
+{
+"type": "MDE", "reporter": "Exch1", "ID": "123abc", "status": "Internal", "memberAliases": [ "ZZZ" ]
+}
+The next example shows a potential member dictionary for exchange Exch2. Note how the same entities are members of both Exch1 and Exch2, but they may or may not have different Member Alias values with each SRO.
+{
+"type": "MDE",
+"reporter": "Exch2",
+"ID": "1234567",
+"memberAliases": [ "FRMZ", "FRMZ:U01", "FRMZ:U02" ],
+"status": "Active"
+}
+{
+"type": "MDE",
+"reporter": "Exch2",
+"ID": "7654321",
+"memberAliases": [ "FRMB" ],
+"status": "Active"
+}
+pubdate: September 09, 2018 effdate: N/A
+ 2.2. Equity Symbols
+Topic: CAT Participant Technical Specifications v1.7.1, Reference Data, Equity Symbols
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT,
+ CAT Symbol ID,
+
+ CAT will maintain a symbol master for all exchange-listed and OTC equities. Each listing exchange (and FINRA) must provide appropriate updates to the symbol master either through the CAT web user interface, or daily file uploads.
+Each change to the symbol is persisted as a change event. All normal updates can be accomplished via the file upload mechanism. However, some types of corrections/updates may cause validation conflicts, and must be done via the GUI (and may require a manual override from the help desk). This is done to prevent faulty uploads from erroneously correcting historical events.
+Note that corporate actions are reported and maintained separately and are not used to maintain the CAT internal symbol master. Thus, the CAT symbol master must be updated explicitly via the web GUI or a daily file upload.
+The data items for a symbol are represented as a JSON object with the following fields, where the effective range of the date is defined as an inclusive range [beginDate, endDate].
+Note that the listing symbol upload process applies only to participants responsible for index or listed/OTC equities. See the Market Move Scenarios section in the appendix for discussion about specific examples when an issue is moved from one participant to another.
+pubdate: September 09, 2018 effdate: N/A
+ 2.2.1. Adding a New Issue
+Topic: CAT Participant Technical Specifications v1.7.1, Reference Data, Equity Symbols, Adding a New Issue
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT,
+ Symbol Master Restatement,
+
+ To add a new issue, an Add Symbol Entry record is submitted. Note that this record is for adding a brand new symbol only - one that has never existed in the CAT system.
+Add Symbol Entry
+
+ This record type is to be submitted when a symbol is assigned to a brand new issue for the very first time. The symbol must not be assigned to any other participant in the beginDate, endDate range. The symbol will be brand new, and will be assigned a new and unique internal CAT Symbol ID. It will not be linked to any other symbol.
+Once a symbol has been added to the database, it cannot be removed via the API. A request must be made to the CAT support desk to perform such an operation. Even then, a symbol will only be removed if it was a clear error, and the symbol was never activated.
+pubdate: September 09, 2018 effdate: N/A
+ 2.2.2. Restating an Issue
+Topic: CAT Participant Technical Specifications v1.7.1, Reference Data, Equity Symbols, Restating an Issue
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ SRO,
+ CAT Symbol ID,
+ Symbol Master Transfer,
+
+ An existing symbol can be restated, providing an explicit check that the exchange and CAT have the same information for the symbol. This is accomplished by submitting a Symbol Master Restatement. The fields for a restatement are identical to those for an add. However, it makes explicit the understanding that the symbol is expected to already be present in the system.
+The values presented in the restatement must exactly match what is in the CAT database, or the record will be rejected.
+Symbol Master Restatement
+
+ pubdate: September 09, 2018 effdate: N/A
+ 2.2.3. Updating an Issue
+Topic: CAT Participant Technical Specifications v1.7.1, Reference Data, Equity Symbols, Updating an Issue
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Symbol Master Transfer,
+ Update Symbol Entry record (USE),
+ CAT,
+
+ An issue is updated when any field of an existing issue needs to be changed. Two Symbol Entry objects are passed. The first represents the expected current state of the symbol entry before being updated, and the second represents the new values for the fields that will be updated. The current state of the database must match the expected symbol entry or the update request will be rejected (when comparing name value pairs, the order in which the name/values appear is not considered). If successful, the database will be changed to reflect the updates requested, and the response will contain a complete updated entry.
+Update Symbol Entry
+
+ The SRO requesting the update must be the current "owner" (i.e., listing participant) of the symbol. All updates are kept, and the history of updates can be queried for a given CAT Symbol ID or a symbol name. Note that an update request will not allow the listing participant to be changed. To change the listing participant of a symbol, submit a Symbol Master Transfer record.
+pubdate: September 09, 2018 effdate: N/A
+ 2.2.4. Transferring an Issue
+Topic: CAT Participant Technical Specifications v1.7.1, Reference Data, Equity Symbols, Transferring an Issue
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ daily file upload,
+
+ To transfer an existing issue from one listing participant to another, the new ownership participant must submit a Symbol Master Transfer request. The request will be validated for data accuracy, and once validated, a transfer will be scheduled inside the system.
+Symbol Master Transfer
+
+ Transfer requests should be submitted prior to the effectiveDate, in which case the transfer will be scheduled for the night before the effectiveDate. If the effectiveDate is the same date as the record submission, then the request will be applied immediately instead of being scheduled. This use pattern may be necessary at times, but is discouraged as it does not leave much time for review of the changes by all parties and opens a potential race condition window.
+Current owners are encouraged to release the symbol prior to transfer by submitting an Update Symbol Entry record (USE), and setting the endDate to be the last day they are responsible for the issue. This is especially important if there may be a gap between the time the symbol is delisted and resisted by another exchange.
+If the current owner has not submitted an update to their endDate when the transfer is applied, then the current owner's endDate will be automatically updated to be one day prior to the effectiveDate in the transfer request.
+When a transfer is applied, then new endDate will always be 99991231, effectively assigning the symbol to the new listing participant until it is changed.
+If an optional field is present, that field will be changed to the new value when the transfer has taken place. Otherwise that field will retain its value after the transfer.
+The submitted record may be rejected when submitted. Among these reasons:
+• the submitted record contains malformed fields
+• the listingParticipant is not the participant submitting the request
+• the combination of ownershipDate, ownershipParticipant, and ownershipSymbol does not reference a valid symbol in the CAT database
+• the effectiveDate is in the past
+A report will be available each day, in conjunction with the symbol master report, that contains all activated and pending transfers.
+If a transfer must take place, but can't be entered into the system for some reason (e.g., the request is being rejected, or it was not submitted in time), then the the resolution can be accomplished by contacting the CAT help desk.
+pubdate: September 09, 2018 effdate: N/A
+ 2.2.5. Daily File Uploads
+Topic: CAT Participant Technical Specifications v1.7.1, Reference Data, Equity Symbols, Daily File Uploads
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ symbol master database,
+
+ Additions, restatements, updates, and transfers can be included in the same file, or they can be submitted in separate files. For an update to be successful, the participant uploading the update must be the owning listing participant, and the "expected" data must exactly match the current state of the system.
+Order is important within the daily file upload, as each action will be performed in the order in which it appears in the file.
+For example, a file with the following entries would
+• Add the brand new listed symbol ABCD
+• Restate the currently listed symbol BBBB
+• Change the endDate for symbol CCCC
+• Transfer ownership of symbol DDDD
+{
+"type": "ASE",
+"listingParticipant": "Exch1",
+"issueType": "NMS",
+"symbol": "ABCD",
+"beginDate": 20170101,
+"endDate": 99991231,
+"companyName": "The Absolute Best Company Description",
+"lotSize": 100,
+"IPO": false,
+"test": false,
+"attributes": "TPG=TG1"
+}
+{
+"type": "SMRST",
+"listingParticipant": "Exch1",
+"issueType": "NMS",
+"symbol": "BBBB",
+"beginDate": 20170101,
+"endDate": 99991231,
+"companyName": "Bob's Big Bad Burgers",
+"lotSize": 100,
+"IPO": false, "test": false
+}
+{
+"type": "USE",
+"expected": {
+"listingParticipant": "Exch1",
+"issueType": "NMS",
+"symbol": "CCCC",
+"beginDate": 20170101,
+"endDate": 99991231,
+"companyName": "Chattanooga Choo Choo Chocolates",
+"lotSize": 100,
+"IPO": false,
+"test": false
+},
+"update": {
+"endDate": 20170515
+}
+}
+{
+"type": "SMXFR",
+"ownershipDate": 20170214,
+"ownershipParticipant": "Exch4",
+"ownershipSymbol": "D",
+"listingParticipant": "Exch1",
+"issueType": "NMS",
+"symbol": "DDDD",
+"effectiveDate": 20170525
+}
+pubdate: September 09, 2018 effdate: N/A
+ 2.2.6. Query the Master List
+Topic: CAT Participant Technical Specifications v1.7.1, Reference Data, Equity Symbols, Query the Master List
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ master symbol list,
+ CAT,
+ SRO,
+
+ After each file upload, the entire contents of the symbol master database will be sent as feedback. Thus, submitting a symbol master file with zero records would result in a feedback file with the current database contents.
+pubdate: September 09, 2018 effdate: N/A
+ 2.2.7. CAT Symbol Master
+Topic: CAT Participant Technical Specifications v1.7.1, Reference Data, Equity Symbols, CAT Symbol Master
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ NYSE,
+ CAT,
+ JSON,
+
+ CAT will provide a start-of-day equity master symbol list at 6:00AM each day. The same master list can be obtained by querying the web API. If modifications to the list are reported during the day (possibly due to corrections or missed additions), the downloadable master list will be updated throughout the day to reflect any such changes. Each file will be named according to the following pattern: EquityMaster_<YYYYMMDDHHMMSS>.json, where YYYYMMDDHHMMSS is the date and time that the file was created. The most recent file for the day will also be accessible via the name EquityMaster_<YYYYMMDD>.json.
+Each listing participant is expected to have made appropriate updates to the CAT symbol master database by 4:00AM. If such changes have not been made, a ticket must be entered with the CAT help desk so CAT and the SRO can initiate appropriate steps to resolve any issues in time for delivering the master list by 6:00AM.
+The symbol master file made available to participants will contain all fields for each entry. In particular, it will contain three different record types: Symbol Master Listings, Pending Transfers, and Applied Transfers. Here are examples of each.
+{
+"type":"SM", "catSymbolID": 12345,
+"listingParticipant":"Exch1", "issueType":"NMS",
+"symbol":"ABCD", "beginDate":"2017-01-01", "endDate":"9999-12-31",
+"companyName":"The Absolute Best Company Description",
+"test":false, "lotSize":100, "IPO":false, "attributes":"TPG=TG1"
+}
+{
+"type":"PXFR", "catSymbolID": 11111,
+"listingParticipant":"Exch1", "ownershipDate": 20170214,
+"ownershipParticipant": "Exch4", "ownershipSymbol": "X",
+"listingParticipant": "Exch1", "issueType": "NMS",
+"symbol": "XXXX", "effectiveDate": 20170525
+}
+{
+"type":"AXFR", "catSymbolID": 22222,
+"listingParticipant":"Exch1", "ownershipDate": 20170214,
+"ownershipParticipant": "Exch4", "ownershipSymbol": "Y",
+"listingParticipant": "Exch1", "issueType": "NMS",
+"symbol": "YYYY", "effectiveDate": 20170522,
+"dateApplied": 20170521
+}
+The symbol master file made available to industry members will only contain basic information for each symbol in the database: the listing exchange, the symbol in the symbology of the listing exchange, and a flag indicating whether the symbol is a test symbol.
+pubdate: September 09, 2018 effdate: N/A
+ 2.2.8. Daily Symbol Dictionary
+Topic: CAT Participant Technical Specifications v1.7.1, Reference Data, Equity Symbols, Daily Symbol Dictionary
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT,
+ unique ID,
+
+ Most symbols are known universally as the same symbol name. However, some symbols have different kinds of extensions, and are represented differently by different venues. For example, a symbol listed on NYSE as FOO.A could be known elsewhere as FOO/A, FOO A, FOOA, or possibly some other symbology. Different agencies (and CAT reporters) use different symbology formats for internal distribution and generating external reports.
+CAT processes symbols in the symbology of the listing exchange. Thus, in the previous example, the only symbol accepted by CAT would be FOO.A. If a reporter uses a different symbology internally, each of those symbols will have to be converted to the symbology of the listing exchange.
+However, to help ease reporting, each reporter can upload a symbol dictionary that allows the reporter to report symbols in whatever symbology is used internally. This means that symbol conversion only has to occur once - in the symbol dictionary - rather than in every reportable event.
+For example, assume an exchange receives an order for a symbol in the symbology ABC.B, and then routes it to an away exchange, but the away exchange requires the symbol to be represented as ABC B. This exchange would have to process its routing logs to convert each use of ABC B to ABC.B. However, if it loaded a symbol dictionary with a set of aliases, then it could report events with both ABC.B and ABC B and CAT would determine that they meant the same thing.
+Note that the symbol dictionary is completely optional. If each symbol will be reported in all events in its native symbology, then the reporter would not need to upload a symbol dictionary.
+Symbol Dictionary Entry
+
+ In the following example, the reporter (MYID)has three internal mappings for the symbol FOO.A: an internal symbol number (345), and two different symbology values (FOO/A and "FOO A").
+{
+"type": "SDE",
+"reporter": "MYID”,
+"listedSymbol": "FOO.A",
+"listingParticipant": "Exch2",
+"symbolAliases": [ "FOO/A", "345", "FOO A" ]
+}
+Thus, in reports submitted from this reporter, any events that reported a symbol using symbology FOO.A, 345, FOO A, or FOO/A would all reference the same actual symbol, namely FOO.A, listed by participant Exch2.
+The symbol dictionary is uploaded as a file of newline delimited JSON objects.
+pubdate: September 09, 2018 effdate: N/A
+ 2.2.9. Options Dictionary
+Topic: CAT Participant Technical Specifications v1.7.1, Reference Data, Equity Symbols, Options Dictionary
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT,
+ unique ID,
+
+ Naming conventions for options can vary among exchanges and trading firms. To reduce confusion and simplify reporting, CAT will allow reporters to submit options reports using a unique ID of type Text(40), as defined by the reporter, for each option. However, this means that each reporter must upload a dictionary every day for which it reports any option quote/ order events. The dictionary is valid only for events reported on the same business day.
+The options dictionary will include simple option entries and complex option entries, to cover all options utilized in any report submitted to CAT by that reporter on a given date. This file is composed of a series of dictionary entries for each option, with the Option ID that will be used by the reporter for all option reports done on that day.
+Each Option ID defined in the dictionary must be unique for that reporter on that day, across all simple and complex options. As for reportable order events, Options Dictionary entries can be uploaded throughout the day. When uploaded files are processed, symbol dictionary files and option dictionary files are processed before any order event files for the same uploaded timeframe. Thus, entries can be added dynamically throughout the day.
+Note that this is not the product definition, but a universal way to reference an options product for the purposes of reporting order events to CAT.
+The options dictionary is uploaded as a file of newline delimited JSON objects.
+pubdate: September 09, 2018 effdate: N/A
+ 2.2.9.1. Option Series Dictionary Entry
+Topic: CAT Participant Technical Specifications v1.7.1, Reference Data, Equity Symbols, Option Series Dictionary Entry
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT,
+ unique ID,
+
+ The dictionary mapping for an option series (flex or simple) will contain the following information, which allows options events to be reported using the Option ID reported in the dictionary entry.
+Simple Option Series Dictionary Entries
+
+ For example, the following dictionary entry would be for the January 19, 2018 150.0 Put for BRK class B. Note that the primary deliverable is reported in NYSE symbology because BRK.B is listed on NYSE.
+{
+"type": "OSDE",
+"reporter": "MYID",
+"optionID": "12345",
+"kind": "Standard",
+"optionsSymbol": "BRKB",
+"primaryDeliverable": "BRK.B",
+"underlyingType": "Equity",
+"expirationDate": 20180119,
+"strikePrice": 150.00,
+"putCall": "Put",
+"exerciseStyle": "American",
+"settlement": "PM"
+}
+pubdate: September 09, 2018 effdate: N/A
+ 2.2.9.2. Option Symbol Changes
+Topic: CAT Participant Technical Specifications v1.7.1, Reference Data, Equity Symbols, Option Symbol Changes
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Symbols,
+
+ Changes to symbols stemming from corporate actions can be handled by reporters using Dictionary Entries. Each options exchange should ensure that on the effective date for a corporate action, its Dictionary Entries accurately reflect option symbols with the appropriate numerical suffix when applicable, and it includes any new option symbols created as the result of the corporate action. A detailed corporate action example follows:
+Stock ABCD undergoes a 2 for 1 stock split on June 1, 2018. All strike prices are halved, the deliverable remains 100 and the symbol is unchanged. On August 1, 2018 stock ABCD spins off company EFGH, 10 shares per 100 ABCD owned. On the market opening at ex-date all open interest in ABCD corp. is moved to symbol ABCD1 delivering 100 shares of ABCD and 10 shares of EFGH. Option symbol ABCD1 = 100 ABCD + 10 EFGH. Subsequently, ABCD and EFGH shares are each listed in the underlying cash market and their prices are used in the valuation of options ABCD1 respectively. The options exchanges list new option contracts for each underlying that deliver 100 shares using symbols ABCD and EFGH (assuming listing criteria is met). Options symbols ABCD and EFGH begin trading (independently) and each delivers 100 shares of the corresponding stock upon exercise. On November 1, 2018 ABCD undergoes a 3 for 2 stock split. Option contracts in ABCD and ABCD1 are affected. Contracts in ABCD become ABCD2 delivering 150 shares of underlying stock ABCD. Option symbol ABCD2 = 150 ABCD. Contracts in ABCD1 remain ABCD1 and deliver 150 shares ABCD and 10 shares EFGH. Option symbol ABCD1 = 150 ABCD + 10 EFGH. The exchange will again list a new ABCD delivering 100 shares of ABCD stock upon exercise.
+Considering the example above, the two entries below demonstrate the values before and after the first corporate action event:
+Stock ABCD undergoes a 2 for 1 stock split on June 1, 2018. All strike prices are halved, the deliverable remains 100 and the symbol is unchanged.
+Before 2:1 Stock Split on June 1, 2018
+"type": "OSDE",
+"reporter": "MYID",
+"optionID": "4322",
+"kind": "Standard",
+"optionSymbol": "ABCD",
+"primaryDeliverable": "ABCD",
+"underlyingType": "Equity",
+"expirationDate": 20181221,
+"strikePrice": 45.00,
+"putCall": "Call",
+"exerciseStyle": "American",
+"settlement": "PM"
+}
+After 2:1 Stock Split on June 1, 2018
+{
+"type": "OSDE",
+}
+"reporter": "MYID",
+"optionID": "4322",
+"kind": "Standard",
+"optionsSymbol": "ABCD",
+"primaryDeliverable": "ABCD",
+"underlyingType": "Equity",
+"expirationDate": 20181221,
+"strikePrice": 22.50,
+"putCall": "Call",
+"exerciseStyle": "American",
+"settlement": "PM"
+The next entries demonstrate the impact of the second corporate action event – the spinoff on August 1, 2018.
+On August 1, 2018 stock ABCD spins off company EFGH, 10 shares per 100 ABCD owned. On the market opening at ex-date all open interest in ABCD corp. is moved to symbol ABCD1 delivering 100 shares of ABCD and 10 shares of EFGH. Option symbol ABCD1 = 100 ABCD + 10 EFGH. Subsequently, ABCD and EFGH shares are each listed in the underlying cash market and their prices are used in the valuation of options ABCD1 respectively. The options exchanges list new option contracts for each underlying that deliver 100 shares using symbols ABCD and EFGH (assuming listing criteria is met). Options symbols ABCD and EFGH begin trading (independently) and each delivers 100 shares of the corresponding stock upon exercise.
+Before Spinoff - Note that at this time, EFGH is still part of ABCD.
+{
+"type": "OSDE",
+"reporter": "MYID",
+"optionID": "4322",
+"kind": "Standard",
+"optionSymbol": "ABCD",
+"primaryDeliverable": "ABCD",
+"underlyingType": "Equity",
+"expirationDate": 20181221,
+"strikePrice": 45.00,
+"putCall": "Call",
+"exerciseStyle": "American",
+"settlement": "PM"
+}
+After Spinoff – three Dictionary Entries would now be reported as the result of this corporate action:
+{
+"type": "OSDE",
+"reporter": "MYID",
+"optionID": "4322",
+"kind": "Non-Standard",
+"optionsSymbol": "ABCD1",
+"primaryDeliverable": "ABCD",
+"underlyingType": "Equity",
+"expirationDate": 20181221,
+"strikePrice": 22.50,
+"putCall": "Call",
+"exerciseStyle": "American",
+"settlement": "PM"
+}
+{
+"type": "OSDE",
+"reporter": "MYID",
+"optionID": "99123",
+"kind": "Standard",
+"optionsSymbol": "EFGH",
+"primaryDeliverable": "EFGH",
+"underlyingType": "Equity",
+"expirationDate": 20181221,
+"strikePrice": 5.00,
+"type": "Call",
+"exerciseStyle": "American",
+"settlement": "PM"
+}
+{
+"type": "OSDE",
+"reporter": "MYID",
+"optionID": 99124,
+"kind": "Standard",
+"optionsSymbol": "ABCD",
+"primaryDeliverable": "ABCD",
+"underlyingType": "Equity",
+"expirationDate": 20181221,
+"strikePrice": 17.50,
+"putCall": "Call",
+"exerciseStyle": "American",
+"settlement": "PM"
+}
+The pre- and post-Spinoff JSON Dictionary Entries shown above are also shown in table format below.
+
+ 
+ A final example demonstrates the impact of the third corporate action event – the stock split on November 1, 2018.
+On November 1, 2018 ABCD undergoes a 3 for 2 stock split. Option contracts in ABCD and ABCD1 are affected. Contracts in ABCD become ABCD2 delivering 150 shares of underlying stock ABCD. Option symbol ABCD2 = 150 ABCD. Contracts in ABCD1 remain ABCD1 and deliver 150 shares ABCD and 10 shares EFGH. Option symbol ABCD1 = 150 ABCD + 10 EFGH. The exchange will again list a new ABCD delivering 100 shares of ABCD stock upon exercise.
+Before 3:2 Stock Split -- ABCD delivers 100 shares of ABCD. ABCD1 options deliver 100 shares of ABCD + 10 shares EFGH.
+{
+"type": "OSDE",
+"reporter": "MYID",
+"optionID": "4322",
+"kind": "Non-Standard",
+"optionsSymbol": "ABCD1",
+"primaryDeliverable": "ABCD",
+"underlyingType": "Equity",
+"expirationDate": 20181221,
+"strikePrice": 22.50,
+"putCall": "Call",
+"exerciseStyle": "American",
+"settlement": "PM"
+}
+{
+"type": "OSDE",
+"reporter": "MYID",
+"optionID": "99124",
+"kind": "Standard",
+"optionsSymbol": "ABCD",
+"primaryDeliverable": "ABCD",
+"underlyingType": "Equity",
+"expirationDate": 20181221,
+"strikePrice": 22.50,
+"putCall": "Call",
+"exerciseStyle": "American",
+"settlement": "PM"
+}
+After 3:2 Stock Split - ABCD becomes ABCD2 and delivers 150 shares of ABCD. Symbol ABCD1 remains, though now delivers 150 shares ABCD and 10 shares EFGH. The exchange lists new, standard ABCD options that deliver 100 shares of ABCD.
+{
+"type": "OSDE",
+"reporter": "MYID",
+"optionID": "4322",
+"kind": "Non-Standard",
+"optionsSymbol": "ABCD1",
+"primaryDeliverable": "ABCD”,
+"underlyingType": "Equity",
+"expirationDate": 20181221,
+"strikePrice": 22.50,
+"putCall": "Call",
+"exerciseStyle": "American",
+"settlement": "PM"
+}
+{
+"type": "OSDE",
+"reporter": "MYID",
+"optionID": "99124",
+"kind": "Non-Standard",
+"optionsSymbol": "ABCD2",
+"primaryDeliverable": "ABCD",
+"underlyingType": "Equity",
+"expirationDate": 20181221,
+"strikePrice": 22.50,
+"putCall": "Call",
+"exerciseStyle": "American",
+"settlement": "PM"
+}
+{
+"type": "OSDE",
+"reporter": "MYID",
+"optionID": 100501,
+"kind": "Standard",
+"optionsSymbol": "ABCD",
+"primaryDeliverable": "ABCD",
+"underlyingType": "Equity",
+"expirationDate": 20181221,
+"strikePrice": 15.00,
+"putCall": "Call",
+"exerciseStyle": "American",
+"settlement": "PM"
+}
+pubdate: September 09, 2018 effdate: N/A
+ 2.2.9.3. Complex Option Dictionary Entry
+Topic: CAT Participant Technical Specifications v1.7.1, Reference Data, Equity Symbols, Complex Option Dictionary Entry
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Dictionary Mapping,
+
+ The dictionary mapping for a complex option will contain the following information. Each complex option can contain multiple legs, where each leg is either an option leg or a stock leg (stock leg will generically refer to equity/exchange-traded fund "ETF").
+Complex Option Dictionary Entries
+
+ The Option ID must be unique. Duplicate dictionary entries are ignored. Entries that have the same Option ID, but different details are rejected. Any entry which defines the opposite side of an existing entry will be rejected. For example, a complex option dictionary entry to Buy one (1) contract of option 1234 and Sell two (2) contracts of option 4321 is considered to be the "opposite side" of an entry to Sell one (1) contract of option 1234 and Buy two (2) contracts of 4321. Thus, if both were submitted the second would be rejected.
+JSON Example
+{
+"type": "CODE",
+"reporter": "MYID",
+"kind": "Complex",
+"optionID": "98765",
+"legs": [
+{
+"legType": "Option",
+"side": "Buy",
+"ratio": 1,
+"optionID": "121345"
+},
+{
+"legType": "Equity",
+"side": "Buy",
+"ratio": 100,
+"symbol": "ABCD"
+}
+]
+}
+JSON Example of reject
+{
+"type": "CODE", "reporter": "MYID", "kind": "Complex",
+"optionID": "98765",
+"legs": [
+{ "legType": "Option", "side": "Buy",
+"ratio": 1, "optionID": "121345"
+},
+{ "legType": "Option", "side": "Sell",
+"ratio": 2, "optionID": "99999"
+}
+]
+}
+{
+"type": "CODE", "reporter": "MYID", "kind": "Complex",
+"optionID": "56789",
+"legs": [
+{ "legType": "Option", "side": "Sell",
+"ratio": 1, "optionID": "121345"
+},
+{ "legType": "Option", "side": "Buy",
+"ratio": 2, "optionID": "99999"
+}
+]
+}
+In this case, the second entry is being defined from the opposite side of the first entry, and would be rejected as a duplicate.
+pubdate: September 09, 2018 effdate: N/A
+ 2.2.10. Corporate Actions
+Topic: CAT Participant Technical Specifications v1.7.1, Reference Data, Equity Symbols, Corporate Actions
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Options Clearing Corporation,
+
+ Similar to equity symbols or option dictionary entries, corporate actions for equities are reported to CAT on a daily basis. Details for corporate actions impacting listed options will be retrieved from the Options Clearing Corporation ("OCC"). An entry must be uploaded for each known corporate action every day by the listing exchange of the affected symbol. SROs must report an entry for a corporate action every day from its declared date through its effective or payment date. For example, if a dividend is declared on Dec 1, 2016 with a payment date on Aug 8, 2017, then an entry must be uploaded to CAT for that dividend every day within that period. Entries for the current trading day must be submitted everyday before 4:00 AM Eastern. For dually-listed securities, an entry must be uploaded by each of the listing exchanges.
+CAT will accept corporate action entry reporting in the format of each SRO. SROs may use their existing CSV file formats for uploading corporate actions entries to CAT. CAT considers corporate actions to be reportable daily beginning with their declared date through their effective, payment, or cancel date. Some examples:
+• Cash Dividend
+• Stock Dividend
+• Stock Split
+• Reverse Stock Split
+• Rights Issue
+• Warrants Issue
+• Spin-Off
+• Delisting
+• Name Change
+• New Listing
+• Symbol Change
+• Share Issue
+In addition to daily corporate actions lists, some exchanges also publish supplementary intraday reports on these corporate actions. CAT only requires that daily entries be uploaded for each known corporate action.
+Exchanges also publish cancellations of known corporate actions to their daily lists. These entries are reportable as well to CAT and should be reported within the same 4:00AM Eastern deadline for a given trading day.
+SRO-specific CSV formats for daily corporate action entries are included in this document in Appendix C. These are the CSV formats known to CAT. CAT must be alerted to any change in these formats at least 30 days in advance of the change taking affect, and changes to the CSV format must also be propagated to this document.
+pubdate: September 09, 2018 effdate: N/A
+ 3. Special Data Elements and Common Events
+Topic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Data Elements,
+
+ This section describes some data elements that are common to most order events, including timestamps, sequence numbers, symbols, material terms of an order, and elements used during the CAT process of creating order lifecycles.
+Events that are universal, or common, are also described in this section.
+pubdate: September 09, 2018 effdate: N/A
+ 3.1. Timestamps and Sequence Numbers
+Topic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events, Timestamps and Sequence Numbers
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Time Stamps,
+ Sequence Number,
+
+ All order events from a given reporter contain a timestamp. Timestamps are required to be reported in the greatest granularity in use by the reporter's trading platform, up to nanoseconds. Ideally, that timestamp would uniquely sequence every event. However, if the granularity of the reported timestamp is insufficient, multiple events could have the same timestamp. This means that there is no way to confidently sequence those events by timestamp. Thus, if it is possible for multiple events to have the same timestamp (from the same reporter, on the same day, in the same symbol), then an event sequence number must also be attached to each event. The sequence number is required to be strictly increasing, and must guarantee proper sequencing of events in the order in which they originally occurred (sequence number requirement is by reporter, date, and symbol). Technically, the sequence number is used to break ties when events have the exact same timestamp.
+The sequence number does not help sequence events across multiple reporters with the same timestamp, but it does assist sequencing events from a given reporter. Note that the sequence number may be globally unique, in which case it provides sequencing unilaterally. However, this is not required. The main requirement of the sequence number is that it can provide sequencing between events from the same reporter, on the same date, in the same symbol, with the same reported timestamp.
+If the timestamp of a given event provides the ability to order within reporter/date/symbol, the Event Sequence Number does not have to be reported.
+pubdate: September 09, 2018 effdate: N/A
+ 3.1.1. Sequence Number Subsystems
+Topic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events, Timestamps and Sequence Numbers, Sequence Number Subsystems
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Subsystem IDs,
+ Sequence Number,
+
+ The purpose of the sequence number is to allow regulators to break ties when multiple events have the same timestamp. However, reports for the same reporter/date/symbol may originate from multiple systems, and it may be difficult to coordinate a sequence number that is unique among all subsystems.
+In such cases, a sequence number subsystem (seqNumSub) can be optionally reported along with the sequence number. This value can be examined to better determine ordering characteristics of the events that have the same timestamp value.
+Note that the only time the sequence number is really important is when multiple events for the same reporter/date/symbol have the same timestamp. If a system guarantees that such reports can't happen, then no sequence number is ever needed. If a system can meet the guarantee without using multiple subsystem IDs, then the subsystem IDs are unnecessary.
+pubdate: September 09, 2018 effdate: N/A
+ 3.1.2. Time of Order Receipt
+Topic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events, Timestamps and Sequence Numbers, Time of Order Receipt
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Order-ID,
+
+ The time of order receipt means the time which an exchange Participant assigns an Order-ID to an incoming message.
+pubdate: September 09, 2018 effdate: N/A
+ 3.2. Symbology
+Topic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events, Symbology
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT,
+ Option ID,
+
+ When reporting events for equities, the symbol must be reported in the symbology of the listing exchange. Optionally, the reporter can submit their reports using an alternate symbology, provided that a symbol dictionary is uploaded to CAT each day an alternate symbology will be used. Thus, any time a symbol is reported, it is always required to be in the symbology of the listing exchange, or to be a valid symbol dictionary alias.
+Any reporter who reports options events must submit an option dictionary to CAT. All options are identified using the Option ID, as provided to CAT in the reporter's option dictionary.
+pubdate: September 09, 2018 effdate: N/A
+ 3.3. NBBO
+Topic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events, NBBO
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ NBBO,
+
+ The NBBO is provided with each relevant order event (i.e. when available). This is the NBBO from the perspective of the reporter at the time of the event, but not including the effect that the event would have on the NBBO. For example, if the NBBO were 100@10.10 x 100@10.15, and a new order arrived at the exchange to BUY 100@10.10, the reported NBBO would be 100@10.10 x 100@10.15, even though the immediate effect of the order would be to change the best bid to 200@10.10.
+Note that the bid/ask prices are required, but the quantities being bid or offered are optional.
+There exist some special cases where the NBBO is unavailable or nonexistent. In those cases, the NBBO values should be reported with a zero price and zero quantity. An entry with both the price and quantity of zero will indicate that the data was either unavailable or not applicable for that particular event. Note that the values can't just be reported as unavailable because it is hard to acquire them. They must truly be unavailable or not applicable to that particular event.
+pubdate: September 09, 2018 effdate: N/A
+ 3.4. Order Linkage and Lifecycle
+Topic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events, Order Linkage and Lifecycle
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT Reporters,
+ Order Linkages,
+ Routed Order ID,
+
+ When all members have submitted their reports to CAT for a given trading day, CAT will link all reportable events in such a way as to create a complete lifecycle of each order. A key part of being able to connect the orders is recognizing and connecting the daisy chain of orders across all CAT reporters. In order to accomplish this, both the reporter routing an order away and the reporter accepting the order must report the exact same details about the order.
+Of particular interest to reporting participants, the data elements important to creating cross-reporter order linkages are: Exchange ID, Date, Symbol/Option, Routing Party, Routed Order ID, and Session ID.
+When an order is routed to an exchange, each communication protocol specifies a way to uniquely identify that order (e.g., FIX protocol calls it ClOrdId, OUCH calls it Order Token). However, the uniqueness guarantees differ from protocol to protocol. Some exchanges may assign a unique Member Alias for each account, and require uniqueness based on the account ID and order ID alone. Others may issue special identifiers for each API session that the member uses to connect into the exchange. Since there is no universally accepted method, CAT has decided to use a combination of several different attributes that provide flexibility in ensuring globally unique order IDs across all known supported protocols.
+Both the routing firm — once industry member reporting has commenced — and the exchange will submit certain pieces of information to CAT in their Order Route and Order Accepted reports. Of particular importance are the Routed Order ID, Routing Party, and Session ID as those fields must match identically between exchange and industry member in order for CAT to accomplish the linkage process.
+The Routed Order ID is the unique order identifier sent in the API message going from the routing entity to the destination entity.
+The Routing Party is a text string that the exchange has assigned to the firm routing the order. Complexity arises when a member is assigned multiple values by the exchange. The determination as to which value is used by both parties depends on protocol-specific information. The text string can be a Member Alias, but there is no restriction that it must be a Member Alias. It can be any string, so long as both the sender of the order and the exchange agree on using the same string for their orders.
+The Session ID is also exchange-assigned, usually a unique login account, an actual protocol session name, IP/port combination, or some other means of identifying a particular API session. The Session ID identifies the specific session used to route the order. Even in cases where there is only one session in use between reporters, the same non-empty value must be reported in the session field by both parties.
+CAT, in cooperation with each exchange, will determine how the Routing Party, Routed Order ID, and Session ID are derived for each API supported by the exchange. This guidance will be documented and published on the CAT website.
+
+ pubdate: September 09, 2018 effdate: N/A
+ 3.5. Material Terms of an Order
+Topic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events, Material Terms of an Order
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Material Terms,
+ CAT,
+
+ The material terms of an order include several well-known fields: price, quantity, side, order type, open/close indicator (for options), time in force, and any special handling instructions. Each order event includes fields for each of these.
+However, each exchange offers significant distinguishing features and instructions to describe how orders are to be handled. These differences are captured mainly in the possible values for the order type and any special handling instructions. The CAT system is generally agnostic to these values, and their primary utility is in how they are interpreted and used in surveillance activities.
+In order to provide utility in using the reported data for surveillance purposes, both the reporters and the users must have well known definitions of the data being reported. In addition, without specific definitions, the submitted data cannot be checked for integrity in those fields that comprise the material terms of an order.
+Thus, every possible value for each field must be explicitly defined both in this specification and the separate specification document for industry members (since they must also report the material terms of the order on their route reports). While this will serve to make the system more friendly to regulatory users, it places the burden of accuracy on each reporter.
+First, every value that could possibly be reported must be well-defined in the technical specifications. Second, CAT must maintain the technical specifications for both the participants and industry members to reflect changes to order types and/or handling instructions over time. Third, each exchange must provide guidance to CAT on how these values are determined for each of their system interfaces, with lead time sufficient to allow CAT to update the specifications for both participants and industry members.
+While the advance notice requirement may represent an incumbrance, it bears noting that exchanges must go through a regulatory approval process in order to make changes to order types, so there is already lead time required before implementing new order types and attributes. Communication to CAT can occur within this lead time to minimize the impact of the advance notice requirement.
+pubdate: September 09, 2018 effdate: N/A
+ 3.5.1. Order Types
+Topic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events, Material Terms of an Order, Order Types
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Order Type,
+ CAT,
+
+ The Order Type for each order must be assigned with exactly one value from a predefined set of choices. These choices are documented in the data dictionary entry for Order Type. CAT, in cooperation with each exchange, has defined a list of acceptable values for this field, however additional order types may be added to accommodate future market needs.
+The CAT website contains guidance on how these choices can be determined for each exchange API.
+pubdate: September 09, 2018 effdate: N/A
+ 3.5.2. Order Handling Instructions
+Topic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events, Material Terms of an Order, Order Handling Instructions
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Sec Rule 613,
+ CAT Processor,
+ Handling Instructions,
+
+ The Handling Instructions field defines special instructions as to how the order should be handled by the exchange. Neither SEC Rule 613, nor the CAT NMS Plan dictate the special handling instructions that must be supported. Furthermore, each exchange may use different names and values to describe how orders are handled, and there can be numerous customized special handling instructions. While the CAT processor must be able to support any instructions which are required to be reported, mandating specific instructions is beyond the scope of the CAT processor as that information is only known by the exchanges and the appropriate surveillance and regulatory entities. Thus, the specification of this field aims to be flexible in providing support for a wide array of special handling instructions.
+Similar to the Order Type field, each possible Order Handling Instructions value must be documented in the data dictionary of this technical specification, and guidance must be provided to CAT by reporters for how these values can be determined based on each exchange API (such guidance will be subsequently posted on the CAT website).
+However, unlike Order Type, the Handling Instructions field can specify as many special handling instructions as apply for that order (or be empty if no such instructions apply). Thus, the handling instructions field will be a list of name/value pair.
+Note that the full intent of the order is reportable to CAT. At minimum, every term and/or instruction for an order that is communicated to the exchange must be reported to CAT. It can be reported as part of the standard set of material terms, or via one of the defined name/ value pairs as defined in the Handling Instructions section of the Data Dictionary. Reporters cannot choose which order instructions to report: they must report every instruction applicable to each order.
+It bears noting that the Order Handling Instructions field is marked as 'conditionally required' in the event definitions, because its existence is not enforced by the system. If the order does not have any characteristics that are reportable to CAT, then the field does not have to be provided. However, if there are any explicit or implied handling instructions for the order, then this effectively becomes a required field, as all instructions must be reported.
+For example, assume two hypothetical handling instructions: AON and WDS=<percent>; where AON means all-or-none and WDS means a discretion price is allowed to be less than or equal to some percentage of the spread. If an order were to be placed as all-or-none, with a discretion of up to 50 percent of the spread, then the Order Handling Instructions field would contain "AON|WDS=50" as its value.
+This approach provides flexibility for exchanges enabling them to represent a wide array of handling instructions, while also enabling CAT to validate submitted data and providing regulators a defined structure for interpretation of the data.
+pubdate: September 09, 2018 effdate: N/A
+ 3.6. Optional, Required, and Conditional Fields
+Topic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events, Optional, Required, and Conditional Fields
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Optional,
+ Required,
+ Conditional,
+
+ Subsequent sections describe event types and their fields. Each field will be notated with the abbreviation R, O, C, or r to represent whether it is required, optional, conditional, or required conditionally. This codification will be present in the last column of each table describing an event.
+
+ pubdate: September 09, 2018 effdate: N/A
+ 3.7. Common Events
+Topic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events, Common Events
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Note Event,
+ Self-Help Declarations,
+ Supplemental Trade Event,
+
+ pubdate: September 09, 2018 effdate: N/A
+ 3.7.1. Note Event
+Topic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events, Common Events, Note Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Order ID,
+ Quote ID,
+ Note Event,
+
+ The Note Event is a generic event that accommodates reporting for certain events that are not defined with explicit events. For example, there could be certain events that occur in the process of handling an order on the floor of an exchange that may be desired to be included in the trail of events for a particular order, but don't fit into an explicitly defined reportable event. Or, there could be a certain process that the order goes through as part of its handling that does not constitute a change in terms of the order, but may be beneficial as part of the order's audit trail.
+The Note event requires either an Order ID or a Quote ID (but not both), so that the notation can be appropriately linked by CAT to the associated order/quote. If the note relates to a stock order, then both orderID and symbol are required. If the note relates to an option order/quote then both optionID and orderID/quoteID are required.
+Note Event
+ +The Note Type and Defined Note Data fields are well-defined and must conform to the permitted values as described in this specification. The Undefined Note Data can
+accommodate any attributes, as long as the field conforms to the format for a list of name/ value pairs.
+Thus, Note Events, while generic in nature, can be parsed and evaluated by both humans and computer programs.
+Lifecycle keys for this event:
+• Order Key: date, reporter, symbol, orderID
+• Order Key: date, reporter, optionID, orderID
+• Quote Key: date, reporter, optionID, quoteID
+pubdate: September 09, 2018 effdate: N/A
+ 3.7.2. Self-Help Declarations
+Topic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events, Common Events, Self-Help Declarations
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Self-Help,
+ CAT,
+
+ “Self-help” declarations allow market participants to disregard the protected quotations of trading centers that are experiencing systems problems such as failure, material delay, or malfunction.
+Participants must report to CAT any self-help declarations they make. If a self-help declaration is carried over to the next day, it must be reported again on that day. The following data is required to be reported for Self-Help declarations:
+Self-Help Declaration
+
+ Both the declared and revoked timestamps can be reported in one single event by including both declaredTimestamp and revokedTimestamp. Alternatively, the declaration and revocation can be reported independently by just including the relevant timestamp in separate events.
+pubdate: September 09, 2018 effdate: N/A
+ 3.7.3. Supplemental Trade Event
+Topic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events, Common Events, Supplemental Trade Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Trade Event,
+ Stock and Option,
+
+ Each trade event (stock and option) contains some information which may not be readily available when generating the trade event. Thus, an independent event can be submitted to augment the information in the trade event. These events can be submitted in the same file as other events or in a separate file.
+These events will not be recorded as separate events in CAT. Rather, the information in these events will be merged with the appropriate trade event to provide data that may have been missing in the original trade event. Currently, only the saleCondition can be reported in this way.
+This event is used for stock and option trades. If the trade references a stock, then the symbol field must be provided. If the trade references an option, then the optionID field must be provided.
+The description uses "trade" in a general manner. If the event references a trade, the tradeID field is required. If the event references a fill, the fillID and side are required.
+Supplemental Trade Event
+
+ Lifecycle keys for this event:
+• Trade Key: date, exchange, symbol, tradeID
+• Trade Key: date, exchange, optionID, tradeID
+• Fill Key: date, exchange, symbol, fillID
+• Fill Key: date, exchange, optionID, fillID
+pubdate: September 09, 2018 effdate: N/A
+ 4. Events for Stock Exchanges
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Stock Exchanges
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Technical Specification,
+
+ Within this Technical Specification, events for stock exchanges, options exchanges, and the trade reporting facilities are documented in separate sections. This section describes reportable events for stock exchanges.
+Events for Stock Exchanges
+ +pubdate: September 09, 2018 effdate: N/A
+ 4.1. Order Accepted Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Stock Exchanges, Order Accepted Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Order Accepted,
+ Order ID,
+
+ When an exchange receives and accepts a routed order, an Order Accepted event is reported to CAT. If the order is rejected (i.e., not received and successfully processed by the matching engine), then an event is not reported to CAT.
+Some systems will outright reject messages if they are malformed or contain a duplicate order ID. Other systems will silently ignore certain malformed messages (e.g., the OUCH protocol specifically states that new orders containing duplicate order tokens are silently ignored). However, all current systems will send some sort of positive acknowledgement when an order has been finally accepted into the system. Some systems will send an acknowledgement from the gateway upon receipt of the request, but the order could still possibly be rejected instead of accepted by the matching engine. Such protocols have a prescribed way of notifying the sender whether or not their order was actually accepted.
+The basic rule is that orders rejected by the gateway are not reportable, but any order reaching the matching engine is reportable.
+Note that for the order accepted event, the firm that sends the order to the exchange will be referred to as the routing firm. In the next event, order route event (section 4.2), the routing broker dealer will also be referred to as the routing firm.
+The Order ID that is used in orders must be globally unique when combined with the date, exchange, symbol and general side, where the general side is either Buy or Sell.
+Order Accepted
+
+ Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, orderID
+• Route Link Key: date, symbol, routingParty, routedOrderID, session, exchange
+pubdate: September 09, 2018 effdate: N/A
+ 4.2. Order Route Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Stock Exchanges, Order Route Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Order Route,
+ Routing Firm,
+
+ The following Order Route event is used to report when an exchange routes an order through a routing broker dealer.
+When an order is routed, some exchanges create a derived order (with a different order ID), to represent the order being routed away. Others just route the order (or part of the order) straight to the routing broker without changing the Order ID. In either case, CAT must be able to link the internal order on the exchange with the internal order at the routing BD. Thus, both the report from the exchange and the report from the routing BD must have the same identifiers for the routed order. This is very similar to the process described earlier related to the Accepted event.
+Note that for an order route event, the routing broker is referred to as the routing firm.
+The Order Route event reported by the exchange needs three key pieces of information: the Routing Firm receiving the routed order, the Session ID through which the order is being routed, and the Routed Order ID, which is the order ID sent to the routing firm.
+The Routing Firm must be represented by an entry in the exchange's member dictionary (though not necessarily a member of the exchange). Furthermore, as explained in the linkage section, both the exchange and the Routing Firm must know which Member Alias is to be reported to CAT because both will have to report the same Member Alias (the exchange in their Route event, and the firm in their Accepted event). Either both sides must use a constant value, or there must be some way to derive the value being used (via session configurations or in the message itself).
+If the exchange creates a derived order, and passes that order ID to the firm via its API, then the Routed Order ID will be the order ID of the derived order. If, however, there is no derived order and the exchange passes its own internal order ID to the routing broker, then the internal order ID will also be assigned as the Routed Order ID. In this case, both the order ID and the routed order ID are populated with the same value.
+Order Route
+
+ Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, orderID
+• Route Link Key: date, symbol, exchange, routedOrderID, session, routingParty
+pubdate: September 09, 2018 effdate: N/A
+ 4.3. Internal Order Route Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Stock Exchanges, Internal Order Route Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT,
+
+ In some cases, an exchange may have multiple internal subsystems involved in handling orders. In such cases, and order may be accepted by one internal system, and then routed to one or more internal systems for processing. Routes within an exchange are not required to be reported to CAT. However, there are cases where it is difficult for an exchange to report the entire status of an order to CAT when its internal processing is handled on multiple systems. Specifically, ensuring that the events contain the same order identifiers would require substantial post processing.
+Thus, an internal route event may be reported to CAT, indicating that an order is being passed from one internal system to another. This will allow CAT to link events that are related to the same order within an exchange, even if the exchange has changed the identifiers on the order as it moves between internal systems.
+Internal Order Route
+
+ Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, orderID
+• Route Link Key: date, symbol, exchange, routedOrderID, session, routingParty
+pubdate: September 09, 2018 effdate: N/A
+ 4.4. Order Modified Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Stock Exchanges, Order Modified Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Original Order ID,
+ Order Modified,
+
+ When the material terms of an order have been changed, an Order Modified event must be reported to CAT. For example, the automatic price adjustment of a peg order due to market move is reportable to CAT. However, changes on fields that are not considered material (e.g., change memo field) should not be reported to CAT.
+Some times, during the course of an order modification, a new internal order is generated (with a new order ID) and completely replaces the previous order (though the new order will be linked to the original order). Both of these cases are handled by the Order Modified event. If the order ID remains the same, then the Original Order ID field will be the same. If the order ID changes, then the Order ID field will contain the new internal ID of the order, and the Original Order ID will contain internal ID of the order prior to being replaced.
+When a modification is reported, the full state of the order is reported, including those fields which have not changed.
+Order Modified
+
+ Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, orderID
+• Previous Order Key: date, exchange, symbol, originalOrderID
+pubdate: September 09, 2018 effdate: N/A
+ 4.5. Order Adjusted Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Stock Exchanges, Order Adjusted Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Order Modified,
+ Adjustments,
+
+ The Order Modified event requires the full state of the order be reported to CAT on each modify. However, there are some common cases where the only change is to price, quantity, or side. The Order Adjusted event can be used in these situations.
+The only types of modifications that are allowed to be reported with this event are changes to the side, price or quantity of the order.
+Side adjustments are only allowed for same-side changes (e.g., changes between short and long sell). The side only needs to be reported if it changes.
+For changes in price, both price and workingPrice are required (i.e., either both are reported or neither are reported).
+For changes in quantity, both quantity and leavesQty are required (i.e., either both are reported or neither are reported).
+If either the displayPrice or the displayQty change, they both need to be reported. The only exception is if the displayQty changes from non-zero to zero. In such a case, the displayQty would be reported, but the displayPrice would not be reported since there is no display quantity.
+This event is meant to capture the most common simple adjustments to orders (e.g., reduction in shares, short-to-long sell, price-only changes). Any modification that cannot be fully represented in this event must be reported via the Order Modified event.
+Order Adjusted
+
+ Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, orderID
+• Previous Order Key: date, exchange, symbol, originalOrderID
+pubdate: September 09, 2018 effdate: N/A
+ 4.6. Order Canceled Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Stock Exchanges, Order Canceled Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Exchanges,
+ Cancelled Order,
+
+ When an exchange cancels an order, in part or in whole, the event must be reported to CAT. Note that an explicit Canceled Event is required for every order that is canceled, even orders that have implicit "execute or cancel" instructions like IOC orders.
+A Canceled event should be used anytime any part of an order is cancelled. For example, an order can be partially reduced either with a cancel message or a modify (cancel/replace) message. If an actual cancel is processed by the exchange, a Canceled event would be reported. If a modify and/or cancel/replace was sent to the exchange, a Modified event would be reported. This keeps the reported event in line with the original intent.
+Some protocols only allow full cancels; partial cancels must be accomplished via a cancel/ replace. In such cases, partial cancels would always be reported as Modified events.
+Order Canceled
+
+ Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, orderID
+pubdate: September 09, 2018 effdate: N/A
+ 4.7. Order Trade Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Stock Exchanges, Order Trade Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Two-sided Transactions,
+
+ All trade events are reported to CAT as two-sided transactions, with a single event.
+Each order trade event is represented with the following details. The details in the table Order Trade Side Details must be populated for each side of the trade.
+Order Trade Event
+
+ Order Trade Side Details
+
+ 
+ Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, buyDetails.orderID
+• Order Key: date, exchange, symbol, sellDetails.orderID
+• Trade Key: date, exchange, symbol, tradeID
+pubdate: September 09, 2018 effdate: N/A
+ 4.8. Order Fill Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Stock Exchanges, Order Fill Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Order Fill Event,
+ Identifier,
+ Description,
+ Data Type,
+ Field Name,
+
+ When a routed order executes, the routing firm acquires the position. The exchange will report the fill with the order on one side, and the routing firm on the other side.
+Order Fill Event
+
+ Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, orderID
+• Fill Key: date, exchange, symbol, fillID
+• Route Link Key: date, symbol, exchange, routedOrderID, session, routingParty
+pubdate: September 09, 2018 effdate: N/A
+ 4.9. Bulk Print Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Stock Exchanges, Bulk Print Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT,
+ Blue Print Event,
+ Field Name,
+ Data Type,
+ Description,
+
+ Certain types of executions happen in a batch and not as order-to-order trades (e.g., opening and closing cross). The Bulk Print event is designed to enable reporting of those types of matches.
+Each batch execution needs an identifier (bulkPrintID) which is unique for that set of executions, by date, reporter, and symbol. An event will be reported to CAT for every order that participated in the batch execution.
+For example, if the opening cross matched 1,000,000 shares of symbol ABCD across 5,000 buy orders and 4,000 sell orders, then there would be 9,000 Bulk Print Event reports sent to CAT for that cross. Each event would contain the same bulkPrintID, which would uniquely identify that particular cross event. The total of all buy-orders execution quantities should be equal to the total total of all sell-orders execution quantities (in this example, 1,000,000 shares).
+Bulk Print Event
+
+ Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, orderID
+pubdate: September 09, 2018 effdate: N/A
+ 4.10. Order Cancel Route Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Stock Exchanges, Order Cancel Route Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Cancel Request,
+ Field Name,
+ Data Type,
+ Description,
+
+ When an exchange initiates a cancel request on an order it has previously routed away, it must report its intent to cancel, using a Cancel Route Event.
+Order Cancel Route
+
+ Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, orderID
+• Route Link Key: date, symbol, exchange, routedOrderID, session, routingParty
+pubdate: September 09, 2018 effdate: N/A
+ 4.11. Order Modify Route Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Stock Exchanges, Order Modify Route Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Cancel or Replace Request,
+ Modify Route Event,
+
+ When an exchange initiates a modify or cancel/replace request on an order it has previously routed away, it must report its intent to modify the order, using a Modify Route Event.
+If the request does not change the routed order ID, then both routedOrderID and routedOriginalOrderID must be the same.
+Modify Route
+
+ Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, orderID
+• Route Link Key: date, symbol, exchange, routedOrderID, session, routingParty
+• Previous Route Link Key: date, symbol, exchange, routedOriginalOrderID, session, routingParty
+pubdate: September 09, 2018 effdate: N/A
+ 4.12. Order Restatement Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Stock Exchanges, Order Restatement Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Restated Orders,
+ Order Key,
+ Previous Order Key,
+
+ Orders that persist across business days (e.g., GTC orders) must be restated each day before any other activity is reported for that symbol. The restatement is an explicit confirmation that the order is still active in the reporter’s order book, and also provides an opportunity to use per-day unique order IDs for all orders.
+The attributes of the order will be restated in terms of the order's current state, after any corporate actions have been processed (e.g., if a 2:1 split occurred, the quantity and price would reflect the resulting change).
+Order Restatement
+
+ Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, orderID
+• Previous Order Key: originalOrderDate, exchange, symbol, originalOrderID
+pubdate: September 09, 2018 effdate: N/A
+ 4.13. Trade Break Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Stock Exchanges, Trade Break Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Broken Trade,
+ Trade Key,
+
+ When a trade is broken, an event is reported to CAT with the appropriate information. Note that CAT adds the event to the history of the order. The broken trade is not removed from the history, as it is something that actually happened and should be recorded.
+Order Trade Break
+
+ Lifecycle keys for this event:
+• Trade Key: tradeDate, exchange, symbol, tradeID
+pubdate: September 09, 2018 effdate: N/A
+ 4.14. Trade Correction Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Stock Exchanges, Trade Correction Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Corrected Trade,
+ Order Key,
+ Trade Key,
+
+ If a trade is corrected in any way, a correction event must be reported to CAT with all details of the trade, after having been corrected. This event must capture the entire state of the trade after having been corrected.
+As with trade breaks, CAT will still keep the original trade, adding the correction to the audit trail of the trade being corrected.
+Order Trade Correction
+ +Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, buyDetails.orderID
+• Order Key: date, exchange, symbol, sellDetails.orderID
+• Trade Key: date, exchange, symbol, tradeID
+pubdate: September 09, 2018 effdate: N/A
+ 4.15. Lifecycle Keys
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Stock Exchanges, Lifecycle Keys
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Lifecycle Keys,
+ Equity Events,
+
+ The lifecycle keys for each event are summarized in the following table.
+Lifecycle Keys for Equity Events
+
+ pubdate: September 09, 2018 effdate: N/A
+ 5. Events for Options Exchanges
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Options Exchanges
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Options Exchanges,
+ Modify Option Route,
+
+ These events are specific for options exchanges.
+Events for Options Exchanges
+
+ pubdate: September 09, 2018 effdate: N/A
+ 5.1. Market Maker Quotes
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Options Exchanges, Market Maker Quotes
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT NMS plan,
+ CAT,
+ Quotes,
+
+ Quotes issued by market makers to options exchanges must be reported to CAT. This section will describe the types of attributes that are used to model quote events, and the types of quote events that should be reported to CAT. CAT supports both one-sided and two-sided quotes.
+While some exchanges create quotes and orders the same way, CAT considers them distinct from a reporting perspective, and they must be reported distinctly. First, market makers are exempt from reporting their quotes to CAT (Section 6.4(d)(iii) of the CAT NMS Plan). Instead, the exchange is fully responsible for submitting the quotes they receive from market makers. Second, the market makers must inform the exchange of the time that they sent each quote, so the exchange can report it to CAT along with the quote (though the MMs are not required to do so until 2018). Third, quotes require fewer data elements than orders.
+Each quote must have a unique Quote ID. Specifically, when a trade occurs with a MM quote on one side, the Quote ID in the trade will identify the exact quote. The combination of Exchange ID, Date, Option ID, and Quote ID should be globally unique.
+Furthermore, each quote update must also have a unique Quote ID (different from the Quote ID for the quote being updated). If the exchange only supports a single quote per market maker, the event can be so noted, and the Quote ID for the quote that is being replaced is not necessary. Otherwise, the update must also include the Quote ID for the quote that is being updated/replaced by the new quote.
+The exchange must guarantee uniqueness of quote IDs throughout the day.
+There are two types of quote events in CAT:
+• Quote Event: Used to report a new quote or a quote replacement. When a quote is replaced, the Original Quote ID will identify the quote being replaced, and the Quote ID will provide the new ID for the updated and replaced quote (or note in the event that the market maker can only have one quote active at any given time).
+• Quote Cancel: Reported when a quote is canceled.
+For block quotes, each quote in the block would be reported to CAT as a separate quote, with a separate unique Quote ID. In such a case, the quote Sent Timestamp would be the same for each quote from the same block because they were all sent at the same time by the market maker. However, the combination of Event Timestamp and Event Sequence Number must be unique for each quote.
+Similarly, when a bulk cancel is requested, a separate quote cancel event is required for each quote that is canceled by such a request.
+On some exchanges, quotes are allowed to be sent before the trading system is ready to process them. For example, there may be an established protocol where the API documents that quotes sent before a particular time are ignored. Or, a protocol may send a "Now Accepting Quotes" message to market makers, and any quotes sent before that time are ignored. In such cases, those ignored quotes are not processed, so they should not be reported to CAT.
+Note that all pre-open quotes are still reportable to CAT. This exception is explicitly for those cases where the exchange allows quotes to be sent before they are officially accepted - but those quotes are neither processed, nor entered into the book, nor accepted for participating in the opening nor any other trading session.
+Once the system has started accepting quotes (either because a set time has arrived, or it has sent out a message indicating that quotes are now being accepted), then all quotes must be reported. CAT does not have rules in place for when exchanges start accepting quotes, but it seems that all exchanges start accepting quotes at least five minutes before the start of trading.
+For example, in the following diagram, an exchange ignores quotes until they send their "Now Accepting Quotes" message. Thereafter all quotes are processed and reported to CAT.
+
+ Similarly, if a quote is rejected and neither accepted nor booked, then the quote should not be reported to CAT.
+pubdate: September 09, 2018 effdate: N/A
+ 5.1.1. Quote Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Options Exchanges, Market Maker Quotes, Quote Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Quote Events,
+ Reported Quote Events,
+ Quote Key,
+ Previous Quote Key,
+
+ The following data elements are to be reported with all quote events. For two-sided quotes, all bid/ask/price/qty values are required. For one-sided quotes, both the price and quantity fields are required, but only for one side.
+Quote Events
+
+ Lifecycle keys for this event:
+• Quote Key: date, exchange, optionID, quoteID
+• Previous Quote Key: date, exchange, optionID, originalQuoteID
+pubdate: September 09, 2018 effdate: N/A
+ 5.1.2. Quote Cancel Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Options Exchanges, Market Maker Quotes, Quote Cancel Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Quote Cancel Event,
+ Quote Key,
+
+ The following data elements are required for cancel quote events.
+Quote Cancel Event
+
+ Lifecycle keys for this event:
+• Quote Key: date, exchange, optionID, quoteID
+pubdate: September 09, 2018 effdate: N/A
+ 5.2. Options Orders
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Options Exchanges, Options Orders
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Order Events,
+ Simple Option Orders,
+ Complex Option Orders,
+ CAT,
+
+ Order events for options are reported in two flavors: simple and complex. Simple option orders are orders for a single option series (including flex options). Complex option orders contain two or more simple option orders, or at least one each of a simple option order and equity order.
+For CAT, an order for a complex option will be reported at the parent complex level, and additional orders will be reported if/when orders are created for each leg. Some exchanges create leg orders as soon as the parent is created, and other exchanges create leg orders only when an execution is created. CAT supports both reporting scenarios.
+Each options order routed to (and then accepted by) an exchange must be reported to CAT. Options orders that are routed to an exchange and then rejected by the exchange are not reportable by the exchange. When an exchange accepts an options order, it must report either a single Option Order Accepted event, or a single Complex Option Order Accepted event followed by one Accepted event for each leg of the complex option.
+The field executionBroker is defined to be the Member Alias of the broker executing the order. For manual/floor trades, this will be the identifier for the physical broker. For quotes, it will be an alias for the market maker behind the quote. For system trades, it will be an alias for the system handling that order.
+pubdate: September 09, 2018 effdate: N/A
+ 5.2.1. Order Accepted Events
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Options Exchanges, Options Orders, Order Accepted Events
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Order Accepted Events,
+
+ 5.2.1.1. Simple Option Order Accepted Event
+A simple option order can represent either a stand-alone option series, or one leg of a complex parent order. If the order represents a leg of a complex order, then the field Complex Order ID will be set to the Order ID of the parent complex order. If necessary, the event timestamp and sequence number could be the same as those in the parent complex order.
+Fields marked with a lower-case 'r' are required if the event represents a normal option order, and they are conditional if the event represents a leg of a complex order.
+Simple Option Order Accepted Event
+
+ Lifecycle keys for this event:
+• Order Key: date, exchange, optionID, orderID
+• Route Link Key: date, optionID, routingParty, routedOrderID, session, exchange
+• Complex Order Key: date, exchange, [complexOptionID,] complexOrderID
+5.2.1.2. Complex Option Order Accepted Event
+Each complex option order routed to (and accepted by) an exchange must be reported to CAT. CAT requires each leg of a complex order to be reported separately, thus the parent order is relatively small with most order details reported on behalf of each leg. The complex order event includes the following data elements.
+The number of legs, and description of each leg is encapsulated in the dictionary entry for the Option ID. In addition to the Complex Order Accepted event, at least one Option Order Accepted event must be submitted for each leg of a complex order (Order Accepted for non-option legs).
+Some systems allow individual legs to carry specific instructions. Thus, order type information is relevant on a per-leg basis, and not reported for the complex parent itself. Furthermore, some exchange don't create leg orders until a trade is imminent. Thus, the model supports both processes, where leg orders can be created upon initial acceptance and at the point of execution.
+No matter when the leg orders are created, each leg must have a unique internal Order ID. Some reporters already create such derived order representations, so these IDs are easy to acquire. Others do not assign identifiers to legs. However, all reporters will be expected to report individual order events for each leg. One suggested method for creating unique leg Order IDs is to use the Order ID of the parent complex order, combined with the leg number (its ordering in the complex option definition). Another is to combine the Complex Order ID with the Option ID and Side of that leg.
+Note that the following fields are conditional in this event. If they are present, then they do not have to appear in the individual order events for option legs, unless the value for a leg would be different from the value in the complex order. In other words, these field values apply to all option legs, unless the option leg contains a different value. If these fields are missing, then the data must be present in each option leg.
+coverage, exchOriginCode, executingFirm, cmtaFirm, mktMkrSubAccount
+Complex Option Order Accepted Event
+
+ 
+ Lifecycle keys for this event:
+• Order Key: date, exchange, optionID, orderID (if not isGloballyUnique)
+Order Key: date, exchange, orderID (if isGloballyUnique)
+• Route Link Key: date, optionID, routingParty, routedOrderID, session, exchange
+5.2.1.3. Stock Leg Order Event
+Similar to option legs, stock legs are reported individually, with a link to the parent complex order. If necessary, the event timestamp and sequence number could be the same as those in the parent complex order.
+Stock Leg Event
+ +See the explanation about leg Order IDs in the section on complex orders. The same process applies to Order IDs for stock legs.
+Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, orderID
+• Complex Order Key: date, exchange, [complexOptionID,] complexOrderID
+pubdate: September 09, 2018 effdate: N/A
+ 5.2.2. Order Modified Events
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Options Exchanges, Options Orders, Order Modified Events
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Modified Events,
+ Order ID,
+
+ An event must be sent to CAT to report changes to any field of an order. Sometimes these changes are applied to the existing internal order. Other times, the modification involves a replacement of the order, causing the exchange to change its internal Order ID. If such a change is necessary, both IDs are needed to maintain the order lifecycle.
+5.2.2.1. Option Order Modified Event
+When an option series or an option leg of a complex option is modified, an instance of this event must be reported, with the following elements. The full state of the modified order must be reported, including fields that did not change value as a result of the modification.
+Option Order Modified Event
+ +Lifecycle keys for this event:
+• Order Key: date, exchange, optionID, orderID
+• Previous Order Key: date, exchange, optionID, originalOrderID
+• Complex Order Key: date, exchange, [complexOptionID,] complexOrderID
+5.2.2.2. Complex Option Order Modified Event
+If the price or quantity changes on a complex order, a complex option order modified event needs to be submitted to CAT. If a change to the parent complex order causes attributes in the leg orders to change, then Order Modified events must be reported for each affected leg. (Note that this only applies if a leg order actually exists at the time of the modification to the complex order - for exchanges that create leg orders at execution, only the complex order needs to be modified). However, if a change in net price to the complex order causes the price of the leg orders to change, changes to the leg order prices are not reportable to CAT.
+If the internal order ID of the complex order changes, then modified reports must be generated for every leg that exists at the time of the modification, referencing the new order ID of the parent complex order.
+The full state of the modified order must be reported, including fields that did not change value as a result of the modification.
+Complex Option Order Modified Event
+ +Lifecycle keys for this event:
+• Order Key: date, exchange, optionID, orderID
+• Previous Order Key: date, exchange, optionID, originalOrderID
+5.2.2.3. Stock Leg Modified Event
+When a stock leg is modified, an event must be reported to CAT with the modified data elements. The full state of the modified order must be reported, including fields that did not change value as a result of the modification.
+Stock Leg Modified Event
+ +Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, orderID
+• Previous Order Key: date, exchange, symbol, originalOrderID
+• Complex Order Key: date, exchange, [complexOptionID,] complexOrderID
+5.2.2.4. Option Order Adjusted Event
+When an option series or an option leg of a complex option is modified in such a way that only impacts the price and/or quantity, an instance of this event can be reported in place of the Option Order Modified event.
+The only types of modifications that are allowed to be reported with this event are changes to the price or quantity of the order.
+For changes in price, both price and workingPrice are required (i.e., either both are reported or neither are reported).
+For changes in quantity, both quantity and leavesQty are required (i.e., either both are reported or neither are reported).
+If either the displayPrice or the displayQty change, they both need to be reported. The only exception is if the displayQty changes from non-zero to zero. In such a case, the displayQty would be reported, but the displayPrice would not be reported since there is no display quantity.
+Option Order Adjusted Event
+ +Lifecycle keys for this event:
+• Order Key: date, exchange, optionID, orderID
+• Previous Order Key: date, exchange, optionID, originalOrderID
+• Complex Order Key: date, exchange, [complexOptionID,] complexOrderID
+5.2.2.5. Complex Option Order Adjusted Event
+When a complex option is modified in such a way that only impacts the price and/or quantity, an instance of this event can be reported in place of the Complex Option Order Modified event.
+The only types of modifications that are allowed to be reported with this event are changes to the price or quantity of the order.
+For changes in quantity, both quantity and leavesQty are required (i.e., either both are reported or neither are reported).
+Complex Option Order Adjusted Event
+ +Lifecycle keys for this event:
+• Order Key: date, exchange, optionID, orderID
+• Previous Order Key: date, exchange, optionID, originalOrderID
+5.2.2.6. Stock Leg Adjusted Event
+When a stock leg is modified in such a way that only impacts the price and/or quantity, an instance of this event can be reported in place of the Stock Leg Adjusted event.
+Stock Leg Adjusted Event
+ +Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, orderID
+• Previous Order Key: date, exchange, symbol, originalOrderID
+• Complex Order Key: date, exchange, [complexOptionID,] complexOrderID
+pubdate: September 09, 2018 effdate: N/A
+ 5.2.3. Options Order Canceled Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Options Exchanges, Options Orders, Options Order Canceled Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Cancelled Event,
+ Partially Cancelled,
+ Option Order,
+
+ An order cancelled event is used to report a cancellation of a simple option order or a complex option order. For complex options orders, if leg-level orders have been opened before a cancelled event, then cancelled events must be reported for each of the leg orders as well.
+CAT also supports partial cancels. Partial cancelled events for complex orders follow the same rule, if there are open leg-level orders before a cancelled event, partial cancelled events must also be reported for each of the legs.
+Note that the order cancelled events contains both the fields optionID and symbol. Both of these fields are conditional. If the order cancelled event is for a stock leg order corresponding to a complex option order, then the symbol field is mandatory. If the order cancelled event is for a simple option order, a complex option order, or an option leg order of a complex order, then the field optionID is mandatory.
+Option Order Canceled
+ +Lifecycle keys for this event:
+• Order Key: date, exchange, optionID, orderID
+• Order Key: date, exchange, symbol, orderID
+pubdate: September 09, 2018 effdate: N/A
+ 5.2.4. Routing Orders
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Options Exchanges, Options Orders, Routing Orders
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Internal Routes,
+ Execution Codes,
+ Note Event,
+ Order ID,
+ Quote ID,
+
+ 5.2.4.1. Internal Routing and Floor Activity
+Internal routes on the exchange are different from internal routes in a Broker Dealer. In particular, internal routes at a broker dealer are required to be reported to CAT, but internal routes at an exchange are not.
+However, there are cases where knowing the system or process of where an order executed is useful, for example when orders are routed through various internal systems on the floor. These processes differ between exchanges and the use cases are incredibly diverse. Furthermore, there is no guidance in the CAT requirements as to what is or is not supposed to be reported in these cases, so we need to be flexible in allowing a diverse set of items to be reported. These somewhat reportable data elements arrive in two forms.
+First, an order may be executed with some additional information that was not available when it was placed (e.g., as part of an auction, or through some floor trading workstation). Thus, there is an element available on Trade Events (Execution Codes), which provides a way to add special exchange specific codes to an execution. The Execution Codes is a name/value pair field (like order Handling Instructions) and can provide additional execution information, like where a trade may have been executed on the floor, or supplemental execution/clearing information.
+Second, there is the general Note Event, which contains either an Order ID or a Quote ID to link the note to a specific order or quote.
+Some systems are composed of multiple subsystems, each having their own reporting and order identification requirements. In such cases, it may be extremely difficult or time consuming to coerce events into a single set of unique order IDs and reporting. Thus, an internal route event is also provided for reporting an order as it progresses between internal subsystems, and possibly changes internal order ID.
+5.2.4.2. Option Route Event
+External routes from an options exchange come in three basic forms: routing all or part of a simple option series order to an away market, routing two stock legs to be crossed, and routing a stock leg for execution. All of these events require certain pieces of information to enable linkage creation that can track the entire order lifecycle.
+The following Option Route Event is used to report when an exchange routes a simple option order, or any leg of a complex option order. A complex order will never be routed away.
+Option Route Event
+ +Lifecycle keys for this event:
+• Order Key: date, exchange, optionID, orderID
+• Order Key: date, exchange, symbol, orderID
+• Route Link Key: date, optionID, routingParty, routedOrderID, session, exchange
+• Route Link Key: date, symbol, routingParty, routedOrderID, session, exchange
+• Complex Order Key: date, exchange, [complexOptionID,] complexOrderID
+5.2.4.3. Internal Option Route Event
+This event provides a means by which options (and legs of complex options) can be routed between internal systems.
+Internal Option Route Event
+ +Lifecycle keys for this event:
+• Order Key: date, exchange, optionID, orderID
+• Order Key: date, exchange, symbol, orderID
+• Route Link Key: date, optionID, routingParty, routedOrderID, session, exchange
+• Route Link Key: date, symbol, routingParty, routedOrderID, session, exchange
+• Complex Order Key: date, exchange, [complexOptionID,] complexOrderID
+5.2.4.4. Internal Complex Option Route Event
+While complex orders are not routed between exchanges, they may be routed internally. This event provides a means by which complex options can be routed between internal systems.
+Internal Complex Option Route Event
+ +Lifecycle keys for this event:
+• Order Key: date, exchange, optionID, orderID
+• Route Link Key: date, optionID, routingParty, routedOrderID, session, exchange
+5.2.4.5. Modify Option Route Event
+When an exchange initiates a modify or cancel/replace request on an option or stock leg order it has previously routed away, it must report its intent to modify the order, using a Modify Option Route Event.
+If the request does not change the routed order ID, then both routedOrderID and routedOriginalOrderID must be the same.
+Note that the Modify Option Route event contains both the fields optionID and symbol. Both of these fields are conditional. If the Modify Option Route event is for a stock leg order, then the symbol field is mandatory and optionID field is not necessary. If the Modify Option Route event is for a simple option order, or an option leg order of a complex order, then the field optionID is mandatory.
+Modify Option Route Event
+ +Lifecycle keys for this event:
+• Order Key: date, exchange, optionID, orderID
+• Order Key: date, exchange, symbol, orderID
+• Route Link Key: date, optionID, routingParty, routedOrderID, session, exchange
+• Route Link Key: date, symbol, routingParty, routedOrderID, session, exchange
+• Previous Route Link Key: date, optionID, routingParty, routedOriginalOrderID, session, exchange
+• Previous Route Link Key: date, symbol, routingParty, routedOriginalOrderID, session, exchange
+5.2.4.6. Option Cancel Route Event
+When an exchange initiates a cancel request on an order that has been previously routed away, it must report the intent to cancel, using a Option Cancel Route Event.
+Note that the Option Cancel Route event contains both the fields optionID and symbol. Both of these fields are conditional. If the Option Cancel Route event is for a stock leg order, then the symbol field is mandatory and optionID field is not necessary. If the Option Cancel Route event is for a simple option order, or an option leg order of a complex order, then the field optionID is mandatory.
+Option Cancel Route
+ +Lifecycle keys for this event:
+• Order Key: date, exchange, optionID, orderID
+• Order Key: date, exchange, symbol, orderID
+• Route Link Key: date, optionID, routingParty, routedOrderID, session, exchange
+• Route Link Key: date, symbol, routingParty, routedOrderID, session, exchange
+pubdate: September 09, 2018 effdate: N/A
+ 5.2.5. Trades and Fills
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Options Exchanges, Options Orders, Trades and Fills
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Two-sided Trades,
+ Simple Option Trade Event,
+ Side Trade Details,
+ Stock Leg Fill Event,
+
+ All trades on an options exchange involving options are reported as two sided trades, with appropriate clearing information for each side. In the case where an order is routed away, the trade is still reported as a two-sided trade, but without an order on one side (that side will just have clearing information).
+Trades off-exchange for non-option legs are reported as one-sided pass through fill events. Note the difference between a trade which the exchange transacted and a fill which the exchange is passing on. Both events are reportable, but they will be reported in different ways. The former as a two-sided trade, and the latter as either a one-sided fill.
+5.2.5.1. Simple Option Trade Event
+Simple option trade events are two-sided trade reports, providing details about both sides of the trade for an option. The same event is used for both simple options trades and trades for each leg of a complex option.
+This section will deal only with simple option trades, the following section will demonstrate how the same event type will be used to report trades at the leg level of complex options.
+Option Trade Event
+Each option trade contains the following data elements.
+Option Trade Event
+ +Side Trade Details
+Each side of a trade contains information pertinent to the order and/or quote that contributed to the trade. The Side Trade Details captures those data elements.
+Side Trade Details
+ +In some cases, an option trade may occur with neither a quoteID nor an orderID for one or both sides of the trade. In these cases, the quoteID/orderID can be omitted. However, the executionCodes must include NOBUYID and/or NOSELLID as appropriate.
+Lifecycle keys for this event:
+• Order Key: date, exchange, optionID, buyDetails.orderID
+• Order Key: date, exchange, optionID, sellDetails.orderID
+• Quote Key: date, exchange, optionID, buyDetails.quoteID
+• Quote Key: date, exchange, optionID, sellDetails.quoteID
+• Trade Key: date, exchange, optionID, tradeID
+5.2.5.2. Stock Leg Fill Event
+When a stock leg executes, it always executes at an away venue, which will report both sides of the trade. The options exchange, while possibly knowing both orders that crossed, did not actually perform the transaction. Thus, all transactions involving stock legs are reported as one-sided pass-along fills of the order, and contain the following data elements.
+Stock Leg Fill Event
+ +Lifecycle keys for this event:
+• Order Key: date, exchange, symbol, orderID
+• Fill Key: date, exchange, symbol, fillID
+pubdate: September 09, 2018 effdate: N/A
+ 5.2.6. Post Trade Allocation Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Options Exchanges, Options Orders, Post Trade Allocation Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Modified Event,
+ Cancelled Event,
+ Repalced Post Trade Allocation,
+
+ In the event of a modified, cancelled, or replaced post trade Allocation, only the final allocation should be reported to CAT.
+The fields quoteID and orderID must reference the quote/order from the original trade that is being allocated. If the trade has neither a quoteID nor an orderID, then this event will include neither IDs as well (this implies that the executionCodes field from the original trade message contains either NOBUYID or NOSELLID.
+Post Trade Allocation
+ +Lifecycle keys for this event:
+• Order Key: date, exchange, optionID, orderID
+• Quote Key: date, exchange, optionID, quoteID
+• Trade Key: date, exchange, optionID, tradeID
+pubdate: September 09, 2018 effdate: N/A
+ 5.3. Options Order Restatement Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Options Exchanges, Options Order Restatement Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ GTC Orders,
+ Options Order,
+ Order Key,
+ Previous Order Key,
+
+ Options orders that persist across business days (e.g., GTC orders) must be restated each day before any other activity is reported for that symbol. The restatement is an explicit confirmation that the order is still active in the reporter’s order book, and also provides an opportunity to use per-day unique order IDs for all orders.
+The attributes of the order will be restated in terms of the order's current state, after any corporate actions have been processed. Pursuant to each exchange’s rule book, some corporate action types dictate that persisted orders will be cancelled or converted. If converted, the order restatement field values should reflect the adjusted values on the effective date (e.g., if a 2:1 split occurred, the quantity and price would reflect the resulting change).
+The following fields will not be included if restating a complex option order, but are otherwise required: openCloseIndicator, orderType, exchOriginCode, coverage, executingFirm.
+Options Order Restatement
+ +Lifecycle keys for this event:
+• Order Key: date, exchange, optionID, orderID
+• Previous Order Key: originalOrderDate, exchange, optionID, originalOrderID
+pubdate: September 09, 2018 effdate: N/A
+ 5.4. Options Trade Break Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Options Exchanges, Options Trade Break Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Options Trade Break,
+ Trade Key,
+
+ When a trade is broken, an event is reported to CAT with the appropriate information. Note that CAT adds the event to the history of the order. The broken trade is not removed from the history, as it is something that actually happened and should be recorded.
+Options Trade Break
+ +Lifecycle keys for this event:
+• Trade Key: tradeDate, exchange, optionID, tradeID
+pubdate: September 09, 2018 effdate: N/A
+ 5.5. Options Trade Correction Event
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Options Exchanges, Options Trade Correction Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Corrected Trade,
+
+ If a trade is corrected in any way, a correction event must be reported to CAT with all details of the trade, after having been corrected. This event must capture the entire state of the trade after having been corrected.
+As with trade breaks, CAT will still keep the original trade, adding the correction to the audit trail of the trade being corrected.
+Options Trade Correction
+
+ Lifecycle keys for this event:
+• Order Key: date, exchange, optionID, buyDetails.orderID
+• Order Key: date, exchange, optionID, sellDetails.orderID
+• Quote Key: date, exchange, optionID, buyDetails.quoteID
+• Quote Key: date, exchange, optionID, sellDetails.quoteID
+• Trade Key: date, exchange, optionID, tradeID
+• Trade Key: date, exchange, optionID, refTradeID
+pubdate: September 09, 2018 effdate: N/A
+ 5.6. Lifecycle Keys
+Topic: CAT Participant Technical Specifications v1.7.1, Events for Options Exchanges, Lifecycle Keys
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Lifecycle Keys,
+ Quote,
+
+ The lifecycle keys for each event are summarized in the following table.
+Lifecycle Keys for Option Events
+
+ 
+ 
+ pubdate: September 09, 2018 effdate: N/A
+ 6. Other Reporting
+Topic: CAT Participant Technical Specifications v1.7.1, Other Reporting
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ FINRA,
+
+ pubdate: September 09, 2018 effdate: N/A
+ 6.1. FINRA Reporting of TRF/ORF/ADF Transaction Data
+Topic: CAT Participant Technical Specifications v1.7.1, Other Reporting, FINRA Reporting of TRF/ORF/ADF Transaction Data
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ FINRA,
+ Eligible Securities,
+
+ Transactions in Eligible Securities reported to a FINRA trade reporting facility must be reported to the CAT by FINRA as a CSV using the fields described in Appendix D: Finra TRF Fields.
+pubdate: September 09, 2018 effdate: N/A
+ 6.2. FINRA Reporting of OTCBB Quote Data
+Topic: CAT Participant Technical Specifications v1.7.1, Other Reporting, FINRA Reporting of OTCBB Quote Data
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ FINRA,
+ FINRA Reporting,
+
+ OTC Bulletin Board quote data must be reported to the CAT by FINRA as a CSV with the following fields:
+OTC BB Quote Elements
+
+ 
+ pubdate: September 09, 2018 effdate: N/A
+ 6.3. FINRA Reporting of Halt/Resume Data
+Topic: CAT Participant Technical Specifications v1.7.1, Other Reporting, FINRA Reporting of Halt/Resume Data
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ FINRA,
+
+ Halt/resume data must be reported to the CAT by FINRA as a CSV with the following fields:
+FINRA Halt/Resume
+
+ 
+ pubdate: September 09, 2018 effdate: N/A
+ 7. Stock Exchange Event Examples
+Topic: CAT Participant Technical Specifications v1.7.1, Stock Exchange Event Examples
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Stock Exchange,
+
+ pubdate: September 09, 2018 effdate: N/A
+ 7.1. Order Event Examples
+Topic: CAT Participant Technical Specifications v1.7.1, Stock Exchange Event Examples, Order Event Examples
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Accepted Event,
+ Modified Event,
+
+ This section will illustrate examples for an order accepted event, an order modified event, and an order canceled event using the following scenario: A new order is routed to the exchange, accepted by the exchange, updated by the firm that sent the order, and is finally canceled by the exchange.
+
+ 
+ 
+ 
+ pubdate: September 09, 2018 effdate: N/A
+ 7.1.1. JSON Examples
+Topic: CAT Participant Technical Specifications v1.7.1, Stock Exchange Event Examples, JSON Examples
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ JSON Examples,
+
+ Order Accepted Event
+
+ Order Modified Event
+
+ Order Canceled Event
+
+ pubdate: September 09, 2018 effdate: N/A
+ 7.2. Order Trade Event Example
+Topic: CAT Participant Technical Specifications v1.7.1, Order Trade Event Example
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Order Accepted Event,
+
+ This section will demonstrate a trade event example that occurs after a buy and sell order are matched. In this case, a sell order is accepted for a price of 157.20 and quantity of 100. A buy order is then accepted for a price of 157.20 and quantity of 100. The two orders are matched and a trade event is reported.
+In this scenario, the exchange is required to report the following events to CAT:
+1) Order Accepted Events from each of the orders; and
+2) The order trade event
+
+ 
+ 
+ 
+ pubdate: September 09, 2018 effdate: N/A
+ 7.2.1. JSON Examples
+Topic: CAT Participant Technical Specifications v1.7.1, Order Trade Event Example, JSON Examples
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ JSON Examples,
+
+ Order Accepted Event: Sell
+
+ Order Accepted Event: Buy
+
+ Order Trade Event
+
+ pubdate: September 09, 2018 effdate: N/A
+ 7.3. Order Route and Order Fill Event Examples
+Topic: CAT Participant Technical Specifications v1.7.1, Order Trade Event Example, Order Route and Order Fill Event Examples
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Order Route,
+ Order Fill Event Examples,
+ Order Accepted Event,
+ Order Route Event,
+ Order Fill Event,
+
+ This scenario illustrates the reporting requirements to CAT when an exchange routes an order to a routing broker-dealer for execution on an away exchange, and Exchange 1’s subsequent reporting obligation on fills of the routed order.
+In this scenario Exchange 1 receives and reports acceptance of an order, then routes the order to their routing broker dealer for execution on an away exchange. When an execution occurs on the away exchange, the routing broker reports the fill back to Exchange 1. The following events are reported:
+1) Order Accepted Event of the original order,
+2) The Order Route Event, and
+3) The Order Fill Event.
+
+ 
+ 
+ 
+ JSON Examples
+Order Accepted Event
+
+ Order Route Event
+
+ Order Fill Event
+
+ pubdate: September 09, 2018 effdate: N/A
+ 7.4. Order Restatement Example
+Topic: CAT Participant Technical Specifications v1.7.1, Order Trade Event Example, Order Restatement Example
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Restated Event,
+
+ This series of examples shows a restatement of a GTC order before market open the following day. Also it is assumed that a stock split on the symbol ABCD has taken effect, and that this is reflected in the restatement.
+
+ 
+ 
+ pubdate: September 09, 2018 effdate: N/A
+ 7.4.1. JSON Examples
+Topic: CAT Participant Technical Specifications v1.7.1, Order Trade Event Example, Order Restatement Example, JSON Examples
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ JSON Examples,
+
+ Order Accepted Event
+
+ Order Restatement Event
+
+ pubdate: September 09, 2018 effdate: N/A
+ 7.5. Order Modified Example
+Topic: CAT Participant Technical Specifications v1.7.1, Order Trade Event Example, Order Modified Example
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Modified Event,
+
+ This section will show how an order modified event is reported when the order type is changed by the initiating member firm from a limit order to a market order. This series of events will follow the submission of a limit order from a member firm to the exchange, that is subsequently modified by the member firm.
+
+ 
+ 
+ pubdate: September 09, 2018 effdate: N/A
+ 7.5.1. JSON Examples
+Topic: CAT Participant Technical Specifications v1.7.1, Order Trade Event Example, Order Modified Example, JSON Examples
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ JSON Examples,
+
+ Order Accepted Event
+
+ Order Modified Event
+
+ pubdate: September 09, 2018 effdate: N/A
+ 7.6. Order Adjusted Example
+Topic: CAT Participant Technical Specifications v1.7.1, Order Trade Event Example, Order Adjusted Example
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Order Adjusted Example,
+
+ This section will show how an order adjusted event is reported when a change in the NBBO causes the working price of an order to change. This series of events will follow the route of a peg order followed by an adjustment of the price.
+
+ 
+ 
+ pubdate: September 09, 2018 effdate: N/A
+ 7.6.1. JSON Examples
+Topic: CAT Participant Technical Specifications v1.7.1, Order Trade Event Example, Order Adjusted Example, JSON Examples
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ JSON Examples,
+
+ Order Accepted Event
+
+ Order Adjusted Event
+
+ pubdate: September 09, 2018 effdate: N/A
+ 8. Options Exchange Event Examples
+Topic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Exchange Event Examples,
+
+ pubdate: September 09, 2018 effdate: N/A
+ 8.1. Quote and Quote Cancel Events
+Topic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples, Quote and Quote Cancel Events
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Quote,
+ Quote Cancel Events,
+
+ Some exchanges use the term "order" to cover both quotes and non-quote orders. For the purpose of reporting to CAT, a quote is to be interpreted as an order/quote that qualifies as a market maker quote for the purposes of satisfying Section 6.4(d)(iii) of the CAT NMS Plan.
+Basically, that is the section which grants relief to market makers from reporting their quotes to CAT, leaving the exchanges themselves with the sole responsibility of reporting quotes to CAT. If such order/quotes received by the exchange would provide the market maker an exemption from reporting the quote, then the order/quote must be reported to CAT as a quote, not an order.
+CAT accepts both one-sided and two-sided quotes.
+pubdate: September 09, 2018 effdate: N/A
+ 8.1.1. Two Sided Quote Examples
+Topic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples, Quote and Quote Cancel Events, Two Sided Quote Examples
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Two Sided Quote Examples,
+
+ The following section will provide examples of reportable events for a two-sided market maker quote when it is posted as a new quote, updated by the market maker, then canceled by the market maker or the exchange. Both the new quote and the updated quote are expressed by the Quote Event, while the quote cancel is expressed by the Quote Cancel Event.
+
+ 
+ 
+ 
+ 8.1.1.1. JSON Examples
+Quote Event (Step 2)
+
+ Quote Event (Step 4)
+
+ Quote Cancel Event (Step 6a)
+
+ Quote Cancel Event (Step 5b)
+
+ pubdate: September 09, 2018 effdate: N/A
+ 8.1.2. Example One Sided Quotes
+Topic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples, Quote and Quote Cancel Events, Example One Sided Quotes
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Example One-sided,
+
+ The following section will provide examples of reported events for a one-sided market maker quote when it is posted as a new quote, updated by the market maker, then canceled by the market maker or the exchange. Both the new quote and the update are expressed by the Quote Event, while the quote cancel is expressed by the Quote Cancel Event.
+
+ 
+ 
+ 8.1.2.1. JSON Examples
+Quote Event (Step 2)
+
+ Quote Event (Step 4)
+
+ Quote Cancel Event (Step 6a)
+
+ Quote Cancel Event (Step 5b)
+
+ pubdate: September 09, 2018 effdate: N/A
+ 8.2. Option Order Event Examples
+Topic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples, Option Order Event Examples
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Option Order Event,
+
+ pubdate: September 09, 2018 effdate: N/A
+ 8.2.1. Example Simple Option Order Accepted
+Topic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples, Option Order Event Examples, Example Simple Option Order Accepted
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Simple Option Order,
+
+ This example describes a Simple Option Order Accepted Event in which the exchange receives and accepts an order for a simple option. Note that in this example Complex Order ID is not provided because there is no parent complex order.
+
+ 
+ 
+ pubdate: September 09, 2018 effdate: N/A
+ 8.2.1.1. JSON Example
+Topic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples, Option Order Event Examples, JSON Example
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ JSON Examples,
+
+ Simple Option Order Accepted Event
+
+ pubdate: September 09, 2018 effdate: N/A
+ 8.2.2. Example Complex Option Order Accepted Event
+Topic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples, Option Order Event Examples, Example Complex Option Order Accepted Event
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Complex Option Order Accepted,
+
+ In the example below, the exchange only creates leg orders at the time an order is executed. Thus, an order on the complex option would have a report sent to CAT for an order accepted event at the parent level of the complex order. Any leg reports would wait until the leg orders are actually created when a trade occurs.
+The examples in this section will use an order on the complex option with optionID 9843. This hypothetical complex option has two option series legs:
+
+ For this example, we suppose at 192411.121456789 on April 20, 2017 an order was accepted for 10 units of complex option 9843 at net price -65 per unit.
+
+ 
+ 
+ 8.2.2.1. JSON Examples
+Complex Order Accepted Event (Step 3)
+
+ pubdate: September 09, 2018 effdate: N/A
+ 8.3. Simple Option Trade Event Examples
+Topic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples, Simple Option Trade Event Examples
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Simple Option Order,
+
+ The below section will provide an example of a trade event for an option series where a broker order is executed against an existing market maker quote.
+
+ 
+ 
+ 
+ pubdate: September 09, 2018 effdate: N/A
+ 8.3.1. JSON Examples
+Topic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples, Simple Option Trade Event Examples, JSON Examples
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ JSON Examples,
+
+ Quote Event
+
+ Simple Option Order Accepted Event
+
+ Option Trade Event
+
+ pubdate: September 09, 2018 effdate: N/A
+ 8.4. Complex Options Trade Events and Examples
+Topic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples, Complex Options Trade Events and Examples
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Complex Options Trade Events,
+
+ In all cases, complex option trades are reported to CAT only at the leg level. There is no roll-up trade reported at the complex order level. For example, an order on the complex option (ID 9851) below would have had corresponding orders reported to CAT for each of the underlying legs. As the following examples will show, trades on this complex option will report by leg, with each leg trade event corresponding to an order event on the leg that is in turn attached to a parent-level complex order event.
+
+ This section follows a series of trade events on the complex option described above, along with examples of the quotes and orders that would be referenced in those trades.
+• A new market maker quote is posted for the option leg 1491
+• A new market maker quote is posted for the option leg 1492
+• An order is placed for quantity 10 of the complex option 9851
+• A trade on the first option leg 1491 is reported (10 contracts)
+• A trade on the second option leg 1492 is reported (10 contracts)
+• A route on the stock leg XYZZY is reported (1,000 shares)
+
+ • A fill on the stock leg XYZZY is reported (1,000 shares)
+
+ 
+ 
+ 
+ 
+ 
+ pubdate: September 09, 2018 effdate: N/A
+ 8.4.1. JSON Examples
+Topic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples, Complex Options Trade Events and Examples, JSON Examples
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ JSON Examples,
+
+ Quote Event (Step 2)
+
+ Quote Event (Step 4)
+
+ Complex Option Order Accepted Event (Step 7)
+
+ Simple Option Order Accepted Event (Step 8)
+
+ Simple Option Order Accepted Event (Step 9)
+
+ Stock Leg Order Accepted Event (Step 10)
+
+ Option Trade Event (Step 11)
+
+ Option Trade Event (Step 12)
+
+ Option Route Event (Step 13)
+
+ Stock Leg Fill Event (Step 14)
+
+ pubdate: September 09, 2018 effdate: N/A
+ 9. Submission Process
+Topic: CAT Participant Technical Specifications v1.7.1, Submission Process
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ This section is excluded for security purposes.
+pubdate: September 09, 2018 effdate: N/A
+ 10. Feedback and Corrections
+Topic: CAT Participant Technical Specifications v1.7.1, Feedback and Corrections
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ This section is excluded for security purposes.
+pubdate: September 09, 2018 effdate: N/A
+ 11. Testing
+Topic: CAT Participant Technical Specifications v1.7.1, Testing
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ This section is excluded for security purposes.
+pubdate: September 09, 2018 effdate: N/A
+ 12. Additional Information
+Topic: CAT Participant Technical Specifications v1.7.1, Additional Information
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ CAT Public Website,
+
+ Additional information is available from the CAT Public Website or the Service Desk. Details are provided below.
+pubdate: September 09, 2018 effdate: N/A
+ 12.1. Public Website
+Topic: CAT Participant Technical Specifications v1.7.1, Additional Information, Public Website
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Sec Rule 613,
+
+ Public Website (http://www.catnmsplan.com) is to provide primary information about CAT. The content will include: Link to SEC Rule 613, Press Releases, Technical Specifications, User Manuals, FAQs, Training Materials and Contact info.
+pubdate: September 09, 2018 effdate: N/A
+ 12.2. CAT Service Desk
+Topic: CAT Participant Technical Specifications v1.7.1, Additional Information, CAT Service Desk
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Sec Rule 613,
+
+ The Service Desk is the primary source for answers to questions about interpretation of SEC Rule 613, clock synchronization, reporting responsibilities, technical specifications for reporting to CAT, and more.
+Meanwhile, the Service Desk is the primary source that provides technical support on data submission, account maintenance, and queries. Strict security controls are applied on this type of support. Additional identification information or web portal access may be required.
+pubdate: September 09, 2018 effdate: N/A
+ Appendix
+Topic: CAT Participant Technical Specifications v1.7.1, Appendix
+ Compliance User: Self-Regulatory Organizations
+ Keywords:
+ Clock Synchronization Requirement,
+ Failure Codes,
+ Corporate Action Formats,
+ BATS Specifications,
+
+ A. Clock Synchronization Requirement
+In previous sections, details are described regarding the Order Events and data elements. Timestamp, as one of the required data elements for each order event, must be correctly recorded by Participants at predefined granularity. This section provides detailed requirements and a recommended approach to how Participants should manage clock synchronization.
+In order to comply with CAT NMS Plan requirements of Clock Synchronization and correctly record the Timestamp fields for order events. Participants are required synchronize Business Clocks at a minimum to within 100 microseconds1 of the time maintained by the National Institute of Standards and Technology (NIST).
+The tolerance includes:
+• The difference between the NIST standard and a time provider’s clock;
+• Transmission delay from the source; and
+• The amount of drift in the Participant's clock.
+In order to ensure the accuracy of timestamps for Reportable Events, Participants are anticipated to adopt policies and procedures to verify such required synchronization each Trading Day (1) before the market opens, and (2) periodically throughout the Trading Day. Participants are recommended to keep documentation which provides details of their Business Clock synchronization process, and the resulting log files from the implementation of such processes.
+Any time provider and technology may be used for clock synchronization as long as the Business Clocks are in compliance with the accuracy requirement.
+If additional details are needed, please refer to the Clock Sync User Guide to be published.
+Note: The tolerance for clock synchronization does not impact the amount of time allowed for CAT reporting. CAT does NOT require reporters to report order information within 100 microseconds of receiving an order.
+B. Failure Codes
+A failure code is a machine-parseable description of why a file or record was rejected. This differs from a failure description, which is intended for human consumption.
+Each failure code is divided into a failure category, sub-category, and value, joined together by a period. Each category roughly corresponds to the stage of processing at which a file or record was rejected. The following failure categories are defined:
+• FILE - a problem with file name or permissions, with the following sub-categories:
+• NAME - a problem with the file name
+• PERM - a problem with file permissions
+• TIMEOUT - a timeout waiting for the corresponding data or meta file
+• INT - a problem with file metadata or hash, with the following sub-categories:
+• META - an incorrect or mismatched metadata value
+• MD - a problem with a member dictionary file or record, with the following subcategories:
+• COUNT - fewer or more records in the file than specified by the Record Count
+• REC - a problem with an individual record
+• SD - a problem with a symbol dictionary file or record, with the following subcategories:
+• COUNT - fewer or more records in the file than specified by the Record Count
+• REC - a problem with an individual record
+• OD - a problem with a options dictionary file or record, with the following subcategories:
+• COUNT - fewer or more records in the file than specified by the Record Count
+• REC - a problem with an individual record
+• NASD_D, NYSE_D, BATS_D, FINRA_D - a problem with a daily submission record record, with the following sub-categories:
+• COUNT - fewer or more records in the file than specified by the Record Count
+• REC - a problem with an individual record
+• OE - a problem with an order event file or record, with the following sub-categories:
+• COUNT - fewer or more records in the file than specified by the Record Count
+• INGEST - a problem with an individual record encountered in the ingestion stage
+• NORM - a problem with an individual record encountered in the normalization stage
+• SYNC - a problem with an individual record encountered in the synchronization stage
+• LINK - a problem with an individual record encountered in the linkage discovery stage
+• FT - a problem with a FINRA transaction record, with the following sub-categories:
+• COUNT - fewer or more records in the file than specified by the Record Count
+• REC - a problem with an individual record
+• NT - a problem with a Nasdaq trade record, with the following sub-categories:
+• COUNT - fewer or more records in the file than specified by the Record Count
+• REC - a problem with an individual record
+• OQ - a problem with a OTCBB quote record, with the following sub-categories:
+• COUNT - fewer or more records in the file than specified by the Record Count
+• REC - a problem with an individual record
+• SM - a problem with a symbol master file or record, with the following sub-categories:
+• COUNT - fewer or more records in the file than specified by the Record Count
+• REC - a problem with an individual record
+• ADD - the record parsed fine, but the ADD request failed
+• UPDATE - the record parsed fine, but the UPDATE request failed
+A failure code may be used for warnings or errors, distinguished by the severity field in the failure report. The failure code itself does not distinguish between a warning (in which a record is accepted but still shows up in the failure report) and an error (which causes a record to be rejected).
+C. Corporate Action Formats
+C.1. NASDAQ Specifications
+NASDAQ will submit all data for the day using a single file type, similar to all other file submissions, with the base filename NASDDaily. The file will contain any or all record types listed in this section, and shall be submitted in JSON format. Note that each record type is identified by a type field.
+C.1.1. NASDAQ Equities Daily List - Notes for the Day
+
+ C.1.2. NASDAQ Equities Daily List
+
+ 
+ 
+ 
+ 
+ 
+ C.1.3. NASDAQ Dividends Daily List
+
+ 
+ 
+ 
+ C.1.4. NASDAQ Next Day X-Rates Daily List
+
+ 
+ 
+ 
+ C.2. BATS Specifications
+Bats will submit all reports using one single file type, with the base filename BATSDaily. Each report will be submitted in CSV format, where the first column designates the type of that record. Each record type may have different numbers of columns, but each record of the same type must have all columns in the definition for that record type.
+C.2.1. Header Record
+The very first record of the file must be a header record, which provides general information about the submitted records. There must be exactly one header record, which contains the following fields.
+Header Record
+
+ C.2.2. Daily Listed Securities Record
+Daily Listed Securities Record Fields
+
+ 
+ 
+ C.2.3. Daily Distribution Record
+Daily Distribution Record Fields
+
+ 
+ 
+ C.2.4. Daily Corporate Action Record
+Daily Corporate Actions Record Fields
+
+ 
+ 
+ 
+ C.3. NYSE Specification
+The NYSE Group Corporate Actions product is comprised of several reports and provides information for equities listed on the NYSE, NYSE MKT and NYSE Arca market centers, including, but not limited to, new listings (for example IPOs, spin-offs and structured product listings), corporate actions, cash dividends, proxy related matters, and so forth.
+NYSE will submit all reports using one single file type, with the base filename NYSEDaily. Each report will be submitted in CSV format, where the first column designates the type of that record. Each record type may have different numbers of columns, but each record of the same type must have all columns in the definition for that record type.
+Data types and formats are consistent with all other CAT reporting data types.
+C.3.1. NYSE Corporate Actions
+The NYSE corporate actions and group ex-date corporate actions will be submitted with a record of this type.
+NYSE Group Daily Corporate Actions & NYSE Group Ex-Date Corporate Actions
+
+ 
+ C.4. FINRA Daily Specification
+
+ C.4.1. FINRA Corporate Actions
+The layout of the FINRA Corporate Action.
+FINRA OTC Corporate Action
+
+ 
+ The following table contains the valid choices for the field DAILY_LIST_RSN_CD.
+Daily List Reason Codes
+
+ 
+ 
+ D. FINRA Trade Reporting Facility (TRF) Fields
+These message types go into the FinraTransactions file kind.
+TRF Trade Report Required Fields
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ E. Market Move Scenarios
+This appendix provides guidance on how some common scenarios where a listed symbol can move from one listing participant to another should be handled.
+E.1. Common Scenarios
+These are common scenarios, with well established procedures.
+E.1.1. OTC to Exchange
+Security ABCD trades OTC on 7/27/2017. Security moves to Exchange A on 7/28/2017 and is assigned new symbol WXY.
+FINRA: On 7/27/2017, submit update record for ABCD, to change end date to 20170727. This explicit delisting step is the preferred method of operation. However, a transfer can still occur without it.
+EXCHANGE A: Anytime before 7/28/2017, Exchange A will submit transfer request to change:
+• Listing Participant to Exchange A
+• Issue Type to NMS
+• Symbol to WXY
+Some time after the market closes on 7/27/2017, and before 2:00AM on 7/28/2017, a scheduled job will automatically run within the CAT system to transfer the symbol to EXCHANGE A. If the symbol is still owned (i.e., the endDate overlaps the new effectiveDate), then endDate will be set to the date the transfer job runs, so that it is released before being transferred. This job will then change the beginDate for the new owner to be the same as the effectiveDate in the transfer request, and will change the endDate for the new owner to 99991231.
+Trades in symbol WXY that occur on 7/28/2017 should be accepted. If the Exchange adds WXY, rather than submitting a transfer, the link between the two symbols will not exist – so the move should be handled with an update, rather than an add.
+E.1.2. Exchange to OTC
+Security ABC trades on Exchange A on 7/27/2017. Security is delisted effective 7/28/2017 and will trade over-the-counter as ABCF.
+EXCHANGE A: On 7/27/2017, submit update record for ABC, to change end date to 20170727. This explicit delisting step is the preferred method of operation. However, a transfer can still occur without it.
+FINRA: Anytime before 7/28/2017, FINRA will submit update record to change:
+• Listing Participant to FINRA
+• Issue Type to OTC
+• Symbol to ABCF
+Some time after the market closes on 7/27/2017, and before 2:00AM on 7/28/2017, a scheduled job will automatically run within the CAT system to transfer the symbol to FINRA. If the symbol is still owned (i.e., the endDate overlaps the new effectiveDate), then endDate will be set to the date the transfer job runs, so that it is released before being transferred. This job will then change the beginDate for the new owner to be the same as the effectiveDate in the transfer request, and will change the endDate for the new owner to 99991231.
+Trades in symbol ABCF that occur on 7/28/2017 should be accepted. If FINRA adds ABCF, rather than submitting a transfer, the link between the two symbols will not exist – so the move should be handled with an update, rather than an add.
+E.1.3. Exchange to Exchange
+The process is the same as the two examples above, with FINRA being replaced by the other listing exchange.
+E.2. Other Scenarios
+These scenarios require further discussion to determine the best procedure.
+E.2.1. No Definitive Destination
+Security is delisting from exchange, but FINRA does not have definitive indication that security will trade OTC.
+An Exchange delists a symbol, but FINRA doesn’t plan to add the symbol to OTC immediately, as we’re not sure what the issuer plans to do (company may be defunct, for example). No trades are received in the symbol after delisting.
+A delisting should submit an Update Symbol Entry record to CAT, delisting the symbol by changing the endDate to the last day that the symbol was listed for that participant. This ensures that the symbol is not listed at all. If/when the symbol is re-listed, a transfer request is submitted by the new listing participant (FINRA). This may result in some number of days where the symbol is not listed. If any events are received for that symbol during that timeframe, those events will be rejected for having an invalid symbol.
+E.2.2. Trades OTC While Suspended
+Security is suspended by the exchange, and trades over the counter while suspended
+Nasdaq may put a security in the “suspended” state prior to formally delisting it. While suspended, it can be added to the OTC master and actively trade for up to 30 days before the exchange ultimately deletes it or the issuer successfully appeals and the security resumes being listed.
+The exchange should update the endDate for when the security is suspended by submitting an Update Symbol Entry record. If FINRA picks it up for trading, then FINRA can submit a transfer request to transfer the security to FINRA. If the exchange ultimately does not de-list the security, the exchange can submit a transfer request to transfer the security back to themselves.
+E.2.3. Move From OTC to Exchange with Symbol and CUSIP Change
+Security is moving from OTC to an exchange, and simultaneously undergoing a symbol and CUSIP change
+When FINRA knows the symbol is listing, it will process the OTC delete and once the new symbol is known, send an update with the new symbol and exchange information. We do not always know the new symbol until it has actually listed, however – so that security update record will come after the listing occurs.
+This should follow Scenario A. The exchange will provide the transfer request to move the security with the correct symbol, and, if practical, FINRA will explicitly release the symbol beforehand.
+E.2.4. Move to OTC Postponed by Exchange
+The exchange tells FINRA a security will be listing on the next day, so FINRA processes the OTC end date and updates the security to the exchange – and then the listing is postponed by the exchange.
+FINRA receives an Add from the exchange on their overnight file, and FINRA relinquishes the security as a result. The exchange notifies FINRA manually the next morning that the listing has been postponed. In the event that FINRA has already sent the end date for the security and relinquished it, and now needs to retract that, what should we do?
+FINRA can submit another update to change the OTC end date back to 99991231 so that the system can continue to accept OTC trades for the security.
+E.2.5. Move to OTC Intraday
+FINRA finds out intraday that a symbol is delisting and needs to be added to OTC.
+Occasionally, FINRA needs to add a symbol intraday when it delists. If that security has already been trading under the prior symbol, in most cases, FINRA will not change the symbol/add the security until the next day. But there are rare cases where the symbol needs to be moved and changed intraday. How will that scenario be handled?
+This scenario needs further thought/discussion. While not frequent, there are cases where a security may be exchange listed at the start of the day and firms may submit orders, and then after market open, the issuer files for bankruptcy/merges, etc and the symbol is moved to OTC and begins trading there. In this case, the system needs to accommodate the security having the same End Date on the exchange as its Begin Date on OTC.
+E.2.6. Temporary Deactivation
+OTC issues can become inactive due to lack of trading or other activity, and can subsequently begin trading again and be re-activated as a result. When FINRA end-dates a security and it subsequently needs to be re-activated, should we submit an update record to provide a new Begin Date and End Date for the new period of trading?
+As long as no one has used that symbol in the interim, FINRA should just submit an update to the symbol to change the end date to 99991231 when the symbol begins trading OTC again.
+E.2.7. Trading Outside Listing Dates
+Trading in securities prior to symbol start date or as-of reporting after the symbol end date.
+In the OTC space, a security may trade before a firm requests a symbol for the security. When FINRA receives the symbol request and enters the security, the begin date for that security is the date it is set up. However, firms can enter as-of trades in that symbol with execution dates before the begin date. The report date of the trade has to be on or after the start date of the security, but the execution date does not.
+After an OTC security has been inactivated, a firm can still submit as-of trades on that security with execution dates prior to the inactivation date. In that case, execution date will be the key field, since it will be before the inactivation date of the security, but the report date will be after.
+This scenario needs further thought/discussion.
+E.2.8. As-of Trades in Delisted Symbols
+As-of trades in delisted exchange symbols
+An exchange delists security ABC, and it begins trading over the counter as ABCF. A firm has trading activity in ABC that it should have reported prior to the delisting. Because symbol ABC has delisted, the exchange will no longer accept trades in that symbol, so the firm must report the trades to ORF as-of, under symbol ABCF – but the execution date of the trades will be before the Start Date of the OTC symbol.
+This scenario needs further thought/discussion.
+F. Encryption Example
+This section is excluded for security purposes.
+G. Data Dictionary
+This dictionary contains definitions for each term used throughout the technical specification.
+askPrice
+Events: Quote Event
+The price being asked for the option in a quote.
+askQty
+Events: Quote Event
+The quantity being asked for the option in a quote.
+attributes
+Reference Data: Symbol Entry
+A Name Value Pairs field, containing attributes associated with a symbol that are meaningful, but may not be permanent. For example, the tick pilot group is meaningful now, but may not be so in the near future. In addition, there may be other "pilots" that may require additional information for symbols.
+This field is a Symbol Entry Pair data type, and allowed values for this field must be defined in the data dictionary entry for Symbol Entry Pairs.
+awayExchange
+Events: Self Help Declaration
+Exchange ID of the exchange affected by the self help event.
+beginDate
+Reference Data: Symbol Entry
+The effective date of the symbol - the first date on which a symbol is an active listing.
+bidPrice
+Events: Quote Event
+The price being bid for the option (can be zero in two-sided quote) in a quote event.
+bidQty
+Events: Quote Event
+The quantity being bid for the option (can be zero in two-sided quote) in a quote event.
+buyDetails
+Events: Order Trade Event, Trade Correction Event, Option Trade Event, Options Trade Correction Event
+Object in a trade event that contains information for the buy side of the trade. Format and element definitions for Buy Details are described in Trade Side Details. For side trade details for equities, please refer to section 4.5. For side trade details for option, please refer to section 5.2.5.1.
+cancelQty
+Events: Order Canceled Event, Options Order Canceled Event
+The quantity being canceled in Order Cancel Event and Options Order Canceled Event. A value of zero means that the cancel was for the full remaining quantity. For example, if an order for 500 shares had partially executed 200 shares, and then the remainder was canceled, the cancelQty could contain either 300 or 0.
+cancelReason
+Events: Order Canceled Event, Quote Cancel Event, Options Order Canceled Event
+Expresses the cancellation reason for a quote or order with one of the below accepted values. Additional values may be added by request.
+Allowed Values:
+IOC Immediately canceled
+EXP Expired
+REQ Explicit request to cancel the order
+DIS Session disconnected
+ALL Market Maker Canceled All Quotes
+Allowed Values (CBOE):
+NOTHING_DONE
+USER
+SYSTEM
+LOST_CONNECTION
+INSUFFICIENT_QUANTITY
+SPECIAL_ADJUSTMENT
+QRM_REMOVED
+INSUFFICIENT_QUANTITY_BUY_SIDE
+INSUFFICIENT_QUANTITY_SELL_SIDE
+WASH_TRADE_PREVENTION
+QUOTE_UPDATE_CONTROL
+FAILOVER
+QUOTE_IN_TRIGGER
+INVALID_SESSION_ID
+SAL_IN_PROGRESS
+CROSS_IN_PROGRESS
+INVALID_NBBO
+NOT_WITHIN_NBBO
+TRADE_THROUGH_CBOE
+INSUFFICIENT_CUSTOMER_ORDER_QUANTITY
+INSUFFICIENT_CROSS_ORDER_SIZE
+INSUFFICIENT_CROSS_ORDER_DOLLAR_AMOUNT
+SELL_SHORT_RULE_VIOLATION
+CANCEL_ON_RSS
+CALL_BID_EXCEEDS_UNDERLYING_PRICE
+PUT_BID_EXCEEDS_STRIKE_PRICE
+LIMIT/EXECUTION_PRICE_WOULD_BE_DEBIT
+LIMIT/EXECUTION_PRICE_EXCEEDS_MAX_VALUE
+NO_USER_ACTIVITY
+BROKER_OPTION
+CANCEL_PENDING
+CROWD_TRADE
+DUPLICATE_ORDER
+EXCHANGE_CLOSED
+GATE_VIOLATION
+INVALID_ACCOUNT
+INVALID_AUTOEX_VALUE
+INVALID_CMTA
+INVALID_FIRM
+INVALID_ORIGIN_TYPE
+INVALID_POSITION_EFFECT
+INVALID_PRICE
+INVALID_PRODUCT
+INVALID_PRODUCT_TYPE
+INVALID_QUANTITY
+INVALID_SIDE
+INVALID_SUBACCOUNT
+INVALID_TIME_IN_FORCE
+INVALID_USER
+LATE_PRINT
+NOT_FIRM
+MISSING_EXEC_INFO
+NO_MATCHING_ORDER
+NON_BLOCK_TRADE
+NOT_NBBO
+COMM_DELAYS
+ORIGINAL_ORDER_REJECTED
+OTHER
+PROCESSING_PROBLEMS
+PRODUCT_HALTED
+PRODUCT_IN_ROTATION
+STALE_EXECUTION
+STALE_ORDER
+ORDER_TOO_LATE
+TRADE_BUSTED
+TRADE_REJECTED
+ORDER_TIMEOUT
+REJECTED_LINKAGE_TRADE
+SATISFACTION_ORD_REJ_OTHER
+UNKNOWN_ORDER
+INVALD_EXCHANGE
+TRANSACTION_FAILED
+NOT_ACCEPTED
+SUSPENDED
+AWAY_EXCHANGE_CANCEL
+LINKAGE_CONDITIONAL_FIELD_MISSING
+LINKAGE_EXCHANGE_UNAVAILABLE
+LINKAGE_INVALID_MESSAGE
+LINKAGE_INVALID_DESTINATION
+LINKAGE_INVALID_PRODUCT
+LINKAGE_SESSION_REJECT
+Allowed Values (BATS):
+ +Allowed Values (BOX):
+TraderCancelled
+Eliminated
+EliminatedByCircuitBreaker
+EliminatedOnDisconnection
+EliminatedByMarketControl
+EliminatedDueToTradingRestriction
+EliminatedDueToTradeLimitExceeded
+EliminatedDueToTradeActivityLimitExceeded
+EliminatedDueToMaximumNbTriggersLimitExceeded
+EliminatedDueToDrillThroughProtection
+EliminatedOutOfLimits
+Allowed Values (MIAX):
+ +Allowed Values (MIAX Pearl):
+ +Allowed Values (CHX):
+A001_02A New SNAP Order Reject - Order Terms are not valid for SNAP
+A001_02B New SNAP Order Reject - Invalid market condition
+A001_07 Cancel Order, SNAP auction end
+A001_11 SNAP Auction - Cancel of Satisfy/Route Order
+A001_13 SNAP Auction - Reject of Satisfy/Route Order
+A001_15 Cancel Order on SNAP Auction - Resting
+U400_01 order reject-invalid content
+U400_04 order reject-invalid trading session
+U400_05 order reject-invalid market state
+U400_06 order reject-invalid market conditions
+U400_07 order message cannot be parsed
+U400_08 order from PMM not is registered stock
+U400_09 order from PMM did not include position
+U400_10 order from PMM with position/side discrepancy
+U400_11 IOC Order Reject-No PM LS
+U400_14 Market IOC orders not allowed during extended sessions
+U400_17 New AOO reject
+U415_01 ME DAS Order Cancel on Restart
+U430_01 satisfy cross reject-not regular-way settlement
+U430_02 satisfy cross reject-short sale test failure
+U430_03 satisfy cross reject-NBBO trade through
+U430_04 satisfy cross reject-insufficient satisfy volume available
+U430_05 satisfy cross reject-outside crossed NBBO
+U430_06 satisfy cross reject-crossed market
+U431_01 yield cross reject-not regular-way settlement
+U431_02 yield cross reject-short sale test failure
+U431_03 yield cross reject-NBBO trade through
+U431_04 yield cross reject-unwilling to yield appropriate side
+U431_05 yield cross reject-outside crossed NBBO
+U431_06 yield cross reject-crossed market
+U432_01 cross reject-too late for cash settlement
+U432_02 cross reject-short sale test failure
+U432_03 cross reject-NBBO trade through
+U432_04 cross reject-outside crossed NBBO U432_05 cross reject-crossed market
+U432_06 cross reject-CHX trade through
+U432_07 cross reject-CHX lock-insufficient size out
+U432_09 Cross Reject - Price is outside the band
+U432_10 For cross order rejected price at trade-at
+U433_01 order reject-outside crossed market NBBO
+U433_02 order reject-crossed market
+U433_03 order cancel-unable to display remaining volume
+U433_04 FOK/IOC Cancel-No Match Opportunity
+U436_01 midpoint cross reject-market crossed
+U436_02 midpoint cross reject-market halted
+U437_01 order cancel-TIF expired
+U441_01A reject incoming order-NBBO trade through
+U441_01B cancel resting undisplayed order-NBBO trade through
+U441_02 Post Only Cancel
+U441_03 Quote Only
+U441_05 order was cancelled because received reject message from away market
+U441_06 SSH Violation
+U441_07 New incoming order get cancelled because of order’s limit price cross price
+band (reserved, un-displayed order)
+U441_08 Resting order get cancelled because of order’s limit price cross price band (reserved, un-displayed order)
+U441_09 Order was canceled because of stale order.
+U450_01 cancel order activity
+U450_03 cancel reject-order not found
+U451_01 cancel change reject-market halted
+U451_02 cancel change-cancel original order
+U451_06 cancel change reject-order not open
+U451_08 cancel change reject-order not found
+U451_11 Reject cancel replace to MKT of DAY order
+U480_02 order canceled on halt
+U482_02 close time expiration-cancel order activity
+U482_05 manual close-cancel order activity
+U482_06 Order gets cancelled because of trading pause.
+U485_05 Manual Open-Cancel Opening Crosses
+U485_06 Primary Quote Open-Cancel Opening Crosses
+U490_02 open timer expiration-cancel opening cross order activity
+U491_02 firm disconnect-cancel order activity
+U495_01 ME DAS Order Cancel on Disconnect
+U496_01 ME DAS Order Cancel on DAS Instruction
+U497_01 Manual Unsolicited Order Cancel
+U498_01 Unsolicited cancel because of MTP Cancel Incoming (N)
+U498_02 Unsolicited cancel because of MTP Cancel Resting (O)
+U498_03 Unsolicited cancel of the incoming order because of MTP Cancel Both (B)
+U498_04 Unsolicited cancel of the resting order because of MTP Cancel Both (B)
+U499_01 Unsolicited Cancel or Reject because Kill Switch Flag is ON.
+U499_02 Unsolicited cancel because of Kill Switch Cancel Request
+U900_03 ME receives an Order Cancel from ORS
+U900_05 ME receives an Order Reject from ORS
+U900_06 ME receives an internal Order Reject from ORS
+Allowed Values (IEX):
+ +Allowed Values (Nasdaq - PHLX, NASD, and BX Options exchanges):
+1 AUTOPURGE
+2 POD
+3 FIRM
+4 REASSIGN
+5 HALT
+6 AIQ
+7 MANUPURGE
+8 OPENPURGE
+9 REPRICE
+10 SUSPEND
+11 LIQUIDITY TAKER
+12 RAPID FIRE VOL
+13 ZAP DELETE
+14 KILLSWITCH AUTO
+15 KILLSWITCH CMD LINE
+16 KILLSWITCH TRADEINFO
+17 notPermitted
+18 badStopPrice
+19 systemClosed
+20 invalidDisplay
+21 invalidType
+22 invalidFirm
+23 invalidClearing
+24 halt
+25 invalidTime
+26 invalidCross
+27 invalidMpid
+28 invalidMinSize
+29 alreadyOpened
+30 restrictedSymbol
+31 closeCross
+32 invalidSymbol
+33 testmode
+34 invalidPrice
+35 tiedToStockNotAllowed
+36 invalidSize
+37 limitTooDeep
+38 featureNotSupported
+39 systemError
+40 invalidAttribute
+41 suspend
+42 notFreeTrading
+43 nbboTooWide
+44 changeContractsNoOrder
+45 changeContractsInvalid
+46 reentry
+47 killswitch_reentry
+48 postOnlyReprice
+49 undLULD
+50 invalidPreOpenIoc
+51 userCancel
+52 ioc
+53 timeout
+54 unsolictedOutReentry
+55 routeRequest
+56 staleOrder
+57 sppLimit
+58 auctionInProgress
+59 engineCancel
+60 tooLateToAct
+61 noAuction
+62 invalidTIF
+63 aonNotAllowed
+64 bboCross
+65 purge
+66 orderExpired
+67 aiq
+68 cnbboLimit
+69 noBbo
+70 mktOrder
+71 treasuryOptionsNotAllowed
+72 openingCancel
+73 executionNotPossible
+74 badCapacity
+75 optionNotOpen
+76 openDelay
+77 liquidityTaker
+78 killSwitch
+79 adminCancel
+80 systemCancel
+81 brokerOption
+82 invalidCrossSurrender
+83 cod
+84 eodCancel
+OTHER Other
+Allowed Values (Nasdaq - ISE, GEMINI, and Mercury Options exchanges):
+1 AUTOPURGE
+2 POD
+3 FIRM
+4 REASSIGN
+5 HALT
+6 AIQ
+7 MANUPURGE
+8 OPENPURGE
+9 REPRICE
+10 SUSPEND
+11 LIQUIDITY TAKER
+12 RAPID FIRE VOL
+13 ZAP DELETE
+14 KILLSWITCH AUTO
+15 KILLSWITCH CMD LINE
+16 KILLSWITCH TRADEINFO
+17 KILLSWITCH USER
+18 notPermitted
+19 invalidStopPrice
+20 systemClosed
+21 invalidDisplay
+22 invalidType
+23 invalidFirm
+24 invalidClearing
+25 halt
+26 invalidTime
+27 invalidCross
+28 invalidMpid
+29 invalidMinSize
+30 alreadyOpened
+31 restrictedSymbol
+32 closeCross
+33 invalidSymbol
+34 testmode
+35 invalidPrice
+36 tiedToStockNotAllowed
+37 invalidSize
+38 limitTooDeep
+39 featureNotSupported
+40 systemError
+41 invalidAttribute
+42 suspend
+43 notFreeTrading
+44 nbboTooWide
+45 changeContractsNoOrder
+46 changeContractsInvalid
+47 reentry
+48 killswitchReentry
+49 postOnlyReprice
+50 undLULD
+51 invalidPreOpenIoc
+52 userCancel
+53 ioc
+54 timeout
+55 unsolictedOutReentry
+56 routeRequest
+57 staleOrder
+58 sppLimit
+59 auctionInProgress
+60 engineCancel
+61 tooLateToAct
+62 noAuction
+63 invalidTIF
+64 aonNotAllowed
+65 bboCross
+66 purge
+67 orderExpired
+68 aiq
+69 cnbboLimit
+70 noBbo
+71 mktOrder
+72 treasuryOptionNotAllowed
+73 openingCancel
+74 executionNotPossible
+75 invalidCapacity
+76 optionNotOpen
+77 openDelay
+78 liquidityTaker
+79 killswitchPurge
+80 adminCancel
+81 systemCancel
+82 brokerOption
+83 invalidSide
+84 invalidSpread
+85 invalidAuctionType
+86 invalidFormat
+87 frozen
+88 requestPending
+89 cancelUp
+90 cancelDown
+91 postOnlyTaker
+92 invalidState
+93 tooManyAuctions
+94 invalidAuctionParams
+95 rejectedReplace
+96 massCancel
+97 invalidReprice
+98 price
+99 size
+100 nbboLimit
+101 impliedExec
+102 tooManyImplieds
+103 complexInstrExists
+104 exceededMaxComplexInstr
+105 firmExceededMaxComplexInstr
+106 invalidPtaContracts
+107 invalidMatchId
+108 invalidTradeId
+109 invalidCrossId
+110 invalidClientId
+111 dnttNotAllowed
+112 instrumentClosed
+113 atrLimitReached
+114 invalidISO
+115 invalidStepupPrice
+116 threeTickLimitReached
+117 pending
+118 pennyNbboRestriction
+119 invalidDntt
+120 invalidInstrType
+121 invalidOrderType
+122 invalidALO
+123 invalidFlashInst
+124 invalidPrefParty
+125 invalidReserveInfo
+126 invalidPersist
+127 invalidShortSaleInd
+128 invalidProduct
+129 invalidScope
+130 invalidOpenClose
+131 invalidToken
+132 invalidKillAction
+133 invalidLegCount
+134 invalidLegType
+135 invalidLegRatio
+136 invalidCrossType
+137 prefNotAllowed
+138 orderNotFound
+139 actionNotAllowed
+140 instrumentState
+141 qccNotAllowed
+142 qccWithStockNetPriceNotAllowed
+143 qccWithMultiOptLegNotAllowed
+144 invalidDestination
+145 maxRoutesAttempted
+146 destinationNotAvailable
+147 minQtyNotSatisfied
+148 sorRespTimeout
+149 invalidAllocSplits
+150 qccWithStockPriceNotAllowed
+151 tooManyStockTradeAttempts
+152 notTob
+153 cod
+154 poolExhausted
+155 eodCancel
+OTHER OTHER
+Allowed Values (Nasdaq Equities):
+1 User requested cancel. Sent in response to a Cancel Order Message or a Replace Order Message
+2 Immediate or Cancel order.
+3 Timeout. The Time In Force for this order has expired
+4 Supervisory.
+5 This order cannot be executed because of a regulatory restriction
+6 Self Match Prevention.
+7 System cancel.
+8 Cross canceled. Non-bookable cross orders that did not execute in the cross.
+9 Order cancelled due to insufficient quantity
+10 This order cannot be executed because of Market Collars
+11 Halted. The on-open order was canceled because the symbol remained halted after the opening cross completed.
+12 Open Protection. Orders that are cancelled as a result of the Opening Price Protection Threshold.
+13 Closed. Any DAY order that was received after the closing cross is complete in a given symbol will receive this cancel reason.
+14 System cancel. This order was cancelled because it was rejected by an away destination; includes midpoint orders cancelled due to a crossed market.
+15 Administrative cancel
+16 Post Only Cancel. This Post Only order was cancelled because it would have been price slid for NMS.
+17 Post Only Cancel. This Post Only order was cancelled because it would have been price slid due to a contra side displayed order on the book
+ADMIN for an administrative cancel FEATURE in the service of a customer-requested feature
+capacity
+Events: Order Accepted Event, Order Route Event, Order Modified Event, Order Trade Event, Order Fill Event, Order Modify Route Event, Order Restatement Event
+Specifies the capacity of a given order or side of a trade.
+Allowed Values:
+Agency
+Principal
+RisklessPrincipal
+clearingFirm
+Events: Stock Leg Order Event, Stock Leg Fill Event
+The Member Alias of the clearing firm.
+clearingNumber
+Events: Order Trade Event, Order Fill Event, Stock Leg Fill Event
+DTCC clearing number reported for each side of a stock trade or for the reporting side of a fill event.
+cmtaFirm
+Events: Simple Option Order Accepted Event, Option Order Modified Event, Option Trade Event, Post Trade Allocation Event, Options Order Restatement Event
+The OCC number of the CMTA firm (only valid for CMTA trades).
+companyName
+Reference Data: Symbol Entry
+The Name of the Company in free format text.
+complexOptionID
+Events: Simple Option Order Accepted Event, Stock Leg Order Event, Option Order Modified Event, Stock Leg Modified Event, Option Route Event
+When present in an event, the complexOptionD will contain the same value as the optionID field from the Complex Order Accepted event to which this event is associated.
+complexOrderID
+Events: Simple Option Order Accepted Event, Stock Leg Order Event, Option Order Modified Event, Stock Leg Modified Event, Option Route Event
+When present in an event, the complexOrderID identifies the complex option order that is the parent order for an leg orders. Note that this will be the same value as the orderID field from the Complex Order Accepted event.
+contraClearingNumber
+Events: Order Fill Event
+DTCC clearing number for contra side of a trade.
+coverage
+Events: Simple Option Order Accepted Event, Option Order Modified Event, Option Route Event, Modify Option Route Event, Options Order Restatement Event
+Specifies whether an option order is covered or uncovered. Field may also be filled in as unspecified.
+Allowed Values:
+Covered
+Uncovered
+Unspecified
+declaredTimestamp
+Events: Self Help Declaration
+Date and time self-help was declared.
+definedNoteData
+Events: Note Event
+A list of key/value pairs, providing machine parseable data for the notation. The attributes must be defined in this specification.
+Allowed Values:
+CBOE Values
+SubNoteType Requires a Choice value (e.g SubNoteType=XXX) where XXX must be one of the following choices.
+SELECTED PAR Order Select Time and NBBO at the time
+RECEIVED PAR Order Received Time and NBBO at the time
+TRADED PAR Order Trade Time and NBBO at the time
+REPRESENT PAR Order represent time and NBBO at the time
+UID A unique number assigned by the originating system to identify the row in SBT_ORDER_HIST. The value must be Unsigned (e.g. UID=12345).
+RemQty Quantity remaining after the fill. The value must be Unsigned (e.g., RemQty=700).
+RouteSrc The source of the route as a text field (Text<40>) of workstation name, PAR broker, etc (e.g., RouteSrc=ABC123).
+RouteDest The destination of the route as a text field (Text<40>) of workstation name, PAR broker, etc (e.g., RouteSrc=ABC123).
+RouteSrcType The location type where the order is routed from. The value is one of the following integer values (e.g., RouteSrcType=3):
+0 - Unspecified
+1 - CMI
+3 - TE
+4 - PAR
+5 - BOOTH_OMT
+6 - CROWD_OMT
+7 - HELP_DESK_OMT
+8 - OHS
+9 - LINKAGE
+10 - DISPLAY
+11 - Broker Dealer (Stock orders derived from CPS Cross)
+12 - Broker Dealer (Stock Orders derived from CPS Market Order Split)
+RouteDestType The location type where the order is routed to. The value is one of the same as described in RouteSrcType.
+RouteRes Indicates the reason for the route. The value is one of the following integer values (e.g., RouteRes=7)
+1 = VOLUME_CHECK
+2 = AUTO_EXECUTION
+3 = DIRECT_ROUTE
+4 = ALTERNATE_ROUTE
+5 = DISCRETIONARY_OR_NH_ORDER
+6 = ALL_ROUTING_ATTEMPT_FAILED
+Following are for reroute attempts
+7 = HAL_REROUTING
+8 = REROUTING_TO_SENDER
+9 = REROUTING_TO_DEFAULT_OMT
+10 = LINKAGE_ROUTE
+Following are for PAR print requests
+11 = PAR_PRINT_ORDER_INTRA_DAY
+12 = PAR_PRINT_ORDER_END_OF_DAY
+13 = PAR_PRINT_CANCEL
+14 = PAR_PRINT_CANCEL_REPLACE
+Following are for PAR order reroute TA and TB
+15 = MANUAL_REROUTE_ORDER_TA
+16 = MANUAL_REROUTE_ORDER_TB
+17 = MANUAL_REROUTE_ORDER_BOOK
+18 = MANUAL_REROUTE_ORDER_AUCTION
+19 = CANCEL_FOLLOW_ORDER
+Following are for PAR order and fill timeouts
+20 = MANUAL_ORDER_TA_TIMEOUT
+21 = MANUAL_ORDER_TB_TIMEOUT
+22 = MANUAL_ORDER_BOOK_TIMEOUT
+23 = MANUAL_ORDER_AUCTION_TIMEOUT
+24 = MANUAL_ORDER_LINKAGE_TIMEOUT
+22 = CABINET_ORDER
+23 = SIMPLE_FILL_REJECT
+24 = COMPLEX_FILL_REJECT;
+25 = MANUAL_FILL_TIMEOUT
+26 = MANUAL_FILL_LINKAGE_TIMEOUT
+27 = TRADE_NOTIFICATION_BUNDLE_TIMEOUT
+28 = TRADE_NOTIFICATION_ACK_TIMEOUT
+29 = TRADE_NOTIFICATION_REJECT
+30 = FILL_REPORT_DROP_COPY
+31 = CANCEL_REPORT_DROP_COPY
+25 = CANCEL_REQUEST_ON_RSS
+26 = NBBO_REJECT
+32 = PREMIUM_EXCEEDS_REASONABILITY
+33 = VOLUME_DEVIATION_CHECK_FAILED_ALL_LEVELS
+34 = VOLUME_DEVIATION_CHECK_PASSED_LEVEL_1
+35 = VOLUME_DEVIATION_CHECK_PASSED_LEVEL_2
+36 = VOLUME_DEVIATION_CHECK_PASSED_LEVEL_3
+37 = CANCEL_REQUEST_ON_FALLBACK
+38 = TOO_MANY_ROUTES
+39 = PRODUCT_STATE_ROUTE
+40 = VOLUME_MAINTENANCE_MISMATCH
+41 = FORCED_LOGOFF_PAR
+BBOBP BBO bid price; the value is of type Price.
+BBOBS BBO bid size; the value is of type Unsigned.
+BBOAP BBO ask price; the value is of type Price.
+BBOAS BBO ask size; the value is of type Unsigned.
+NBBOBP NBBO bid price; the value is of type Price.
+NBBOBV NBBO bid exchange volume; the value is of type Unsigned.
+NBBOAP NBBO ask price; the value is of type Price.
+NBBOAV NBBO ask exchange volume; the value is of type Unsigned.
+DSMBP Derived Spread Market bid price; the value is of type Price
+DSMBS Derived Spread Market bid size; the value is of type Unsigned
+DSMAP Derived Spread Market ask price; the value is of type Price
+DSMAS Derived Spread Market: The (Integer)
+BBP Book bid price; the value is of type Price.
+BBS Book bid size; the value is of type Unsigned.
+BAP Book ask price; he value is of type Price.
+BAS Book ask size; the value is of type Unsigned.
+AuctionType The type of auction; the value is one of the following integers
+0 = Auction Unspecified,
+1 = AUCTION_INTERNALIZATION (AIM/Complex AIM),
+2 = AUCTION_STRATEGY,
+3 = AUCTION_REGULAR_SINGLE,
+4 = AUCTION_HAL,
+5 = AUCTION_SAL.
+8 = AUCTION_DAIM (for Directed AIM).
+AucTradeQty auction trade quantity; the value will be Unsigned
+AucEarlyTerm indicates if an auction ended early; the value is Boolean (true or false)
+AuctionID Optional field of type UNSIGNED
+ActTime The actual time at which activity happened on PAR or ME; the value will be Timestamp
+NYSE Options Values
+FloorTrade
+FloorTradeNamesLater
+FloorTradeNamesLaterAllocation
+desiredLeavesQty
+Events: Order Cancel Route Event, Option Cancel Route Event
+The desired number of shares remaining in the order after the cancel request has been issued for a routed order. A value of zero indicates a full cancel.
+displayPrice
+Events: Order Accepted Event, Order Modified Event, Order Restatement Event, Simple Option Order Accepted Event, Option Order Modified Event, Options Order Restatement Event
+The displayed price for an order.
+displayQty
+Events: Order Accepted Event, Order Route Event, Order Modified Event, Order Modify Route Event, Order Restatement Event, Simple Option Order Accepted Event, Stock Leg Order Event, Option Order Modified Event, Stock Leg Modified Event, Option Route Event, Modify Option Route Event, Options Order Restatement Event
+The displayed quantity for an order.
+endDate
+Reference Data: Symbol Entry
+The date a symbol will expire. A value must be entered, if unknown, use Dec 31 9999.
+eventTimestamp
+Events: All
+eventTimestamp generally refers to when an event occurred, however this is subjective depending on the event. Refer to the events definitions to see what this timestamp represents within the context of that event.
+exchange
+Events: All Stock Exchange Events, All Options Exchange Events
+The exchange ID of the exchange associated with the event being reported. Refer to each individual event definition for more specific details.
+exchOriginCode
+Events: Simple Option Order Accepted Event, Option Order Modified Event, Option Trade Event, Options Order Restatement Event, Post Trade Allocation Event
+Exchange-specific codes that specify the origin of an order. CAT will map all of these exchange-defined codes to either C - Customer, F - Firm, or M - Market Maker internally. Only the exchange specific codes as defined below need to be included in this field.
+Below are the accepted values for each exchange, with their description, and their mapping to C, F, or M in CAT in parentheses.
+Note that some values are marked as "C/M," C/M will map to customer unless an order has mktMkrSubAccount, when it will map to M.
+CBOE/C2 Allowed Values:
+B Broker Dealer (C)
+D Customer Floor Broker Workstation (C)
+E Customer Internal (C)
+F Firm (F)
+H Firm Internal (F)
+I In Crowd Market Maker (M)
+J Firm Floor Broker Workstation (F)
+K Broker Dealer Floor Broker Workstation (C)
+L B/Ds that are billed as ‘Firm’ but clear in the ‘C’ range at OCC (C)
+N Away Market Maker (M)
+R Broker Dealer Internal (C)
+U MM from FBW (C/M)
+W Broker Dealer Floor Broker Workstation (C/M)
+X Customer BD (C/M)
+Y
+Z N,Y from FBW (C/M)
+NYSE Options Allowed Values:
+C Customer (C)
+F Firm (F)
+BD Broker Dealer (C/M)
+M Market Maker (M)
+P Professional Customer (C)
+BATS Allowed Values:
+B Broker Dealer (C)
+C Customer (C)
+F Firm (F)
+J Joint Back Office (F)
+L Non TPH Affilliate (C)
+M Market Maker (M)
+N NonRegMarketMaker (M)
+U ProCustomer (C)
+BOX Allowed Values:
+6 Public Customer (C)
+7 Broker Dealer (F)
+8 Market Maker (M)
+W Broker Customer (C)
+X Away Affiliated Market Maker (M)
+T Professional Customer
+Y Floor Broker (F)
+Z Floor Market Maker (M)
+V Floor Broker Customer (C)
+U Affiliated Broker Customer (F)
+MIAX Allowed Values:
+1 Market Maker (M)
+2 Away MM (M)
+3 Broker Dealer (F)
+4 Firm (F)
+5 Pri Customer (C)
+6 Non Pri Customer (C)
+MIAX Pearl Allowed Values:
+1 Market Maker (M)
+2 Away MM (M)
+3 Broker Dealer (F)
+4 Firm (F)
+5 Pri Customer (C)
+6 Non Pri Customer (C)
+NASDAQ Options Allowed Values:
+1 Customer (C)
+2 Firm (F)
+3 Floor MM (M)
+4 Off Floor MM (M)
+5 Broker Dealer (C)
+6 Professional Customer (C)
+7 Proprietary Customer (C)
+8 Retail Customer (C)
+9 JBO (F)
+10 Broker Dealer Firm (F)
+executingFirm
+Events: Simple Option Order Accepted Event, Option Order Modified Event, Option Trade Event, Options Order Restatement Event
+The OCC number of the executing firm.
+executionCodes
+Events: Order Trade Event, Order Fill Event, Trade Correction Event, Option Trade Event, Stock Leg Fill Event, Options Trade Correction Event
+Codes that provide a way to augment executions with specific information about the execution. The Execution Codes field has the same formatting as Order Handling Instructions, where zero or more codes can be entered to provide additional execution information, like where a trade may have been executed on the floor.
+Each code is separated by a single pipe symbol (ASCII decimal 124, hex 7C). Codes which require a value will include that value immediately after the code Field Name and a single equal sign (ASCII decimal 61, hex 3D). All instructions that apply to the order are to be included.
+Allowed Values:
+AUC If the trade happened as part of an auction, this code identifies the auction by name (e.g., AUC=CROSS)
+PCTP Executions for FLEXPCT orders are reported, with the price as the final dollar value of the trade. However, the price was determined as a percentage execution. The original trade percentage value is reported using the PCTP execution code, which requires a Numeric(10,8) value, where 94.5% would be reported as PCTP=94.5.
+PCTO Executions for FLEXPCT trades are reported using the optionID of the percentage product. However, the final execution happens with a different optionID that is not percentage based. This final optionID is a Text<40> field, and is reported in the trade with the PCTO execution code (e.g., PCTO=OPTIONID1234).
+NOBUYID Indicates that there is neither a quoteID nor an orderID associated with the buy side of the trade.
+NOSELLID Indicates that there is neither a quoteID nor an orderID associated with the sell side of the trade.
+ASOF The trade is being reported as- of another date. This option requires a Date value (e.g. ASOF=20171218).
+Allowed Values (CBOE):
+TradeType This code requires a choice value (e.g., TradeType=N) where N is one of the following list of values:
+B Blocktrade
+R Regular Trade
+F Intermarket Sweep
+L No Print Linkage Trade
+M Manual Trade
+P Par Trade
+X Cross Product Leg Trade
+S Cross Product Cross Trade
+I Cross Product AIM Cross Trade
+H Handheld Trade
+Q Par to Market Maker Trade
+1 Regular trade reversal
+2 No Print Linkage Trade Reversal
+3 No Print Linkage Trade Manual
+T Two-Day Trade
+TradeSource This code requires a choice value (e.g., TradeSource=PAR) where the value is one of the three following choices:
+PAR
+System
+Manual
+FirmTradeRptTime Shows the Firm Trade Report Time (applies to Block trade and manual trades, time the firm/market maker reports the floor trade), requires a timestamp (e.g., FirmTradeRptTime=20170108T023000.123456789). Note that the timestamp must be in the CAT timestamp format described in section 1.5 of the tech specs
+FirmTradeTime Shows the Firm Trade Time - applies to manual trades - Market Makers have an option to specify when they did the trade on the floor. Requires a timestamp (e.g., FirmTradeTime=20170108T023000.123456789). Note that the timestamp must be in the CAT timestamp format described in section 1.5 of the tech specs
+TradeRptTime Shows the Tape Report Time (when the system reports to OPRA i.e. when the GUI user hits the send button) applies to manual and block trades only. Requires a timestamp. (e.g., TradeRptTime=20170108T023000.123456789). Note that the timestamp must be in the CAT timestamp format described in section 1.5 of the tech specs
+BBOBP CBOE BBO Bid Price at the time of the trade. Requires a price value. (e.g., BBOBP=12.25)
+BBOBS CBOE BBO Bid Size at the time of the trade. Requires an integer value. (e.g., BBOBS=400)
+BBOAP CBOE BBO ask price at the time of the trade. Requires a price value. (e.g., BBOAP=12.50)
+BBOAS CBOE BBO ask size at the time of the trade. Requires an integer value. (e.g., BBOAS=200)
+BDATE Shows the business date. Requires a date value expressed as YYYYMMDD (e.g., BDATE=20170112).
+INTLIQ Liquidity classification internal to BATS. Requires a choice value (e.g., INTLIQ=X) from the following list
+A added
+R removed
+X routed
+B both order washed/removed some liquidity then got booked
+D externally removed
+c conditionally added
+C auction
+Q options wait order
+SUBLIQ BATS internal subliquidity indicator. This is filled in on executions once the code offering the best price to the member is selected. Requires a choice value (e.g., SUBLIQ=N) from the following list
+N normal
+H hidden
+B SUM (Options only – step up auctions mechanism)
+R bolt route
+D dark book
+S setter
+J joiner
+I hidden improved
+T dark Book IOC
+O open auction
+C close auction
+P IPO auction
+A halt auction
+V visible improved
+E retail price improvement (BYX Equities: Retail Order vs. Retail Price Improving Order)
+K hidden reserve (hidden portion of a reserve order)
+b BamAuction (Options only - Bats Auction Mechanism)
+c Cboe Market Close
+m hidden midpoint (US Equities: Hidden midpoint execution)
+o open queued
+h halt queued
+q QCC (Options only - Qualified Contingent Cross)
+r Persisted (GTC restatement)
+s SAM Auction
+Allowed Values (BOX):
+TT Indicates when the trade was done. Requires choice value as one of the following list of values:
+Opening
+MarketOperation
+ContinuousTrading
+GuaranteedAuction
+SolicitationAuction
+FacilitationAuction
+AwayTrade
+FloorTrade
+STI Indicates the trade type. Requires choice value as one of the following list of values:
+RegularTrade
+As-of-Trade
+Block Trade
+Late Trade
+Hidden Trade
+Price Volume Adjustment
+ImpliedOption
+ImpliedStrategy
+IsoInbound
+GdoTradeThrough
+PipSweep
+USContingent
+Pip
+Crossed
+ImpliedStrategy
+FloorTrade
+SID Indicate the Strategy id. Value associated will be blank or will contain the Strategy Identification
+STID Indicate the Strategy Trade Id. Value associated will be blank or will contain the Strategy Identification
+SV Indicate the Strategy Verb. Value associated will be blank or will contain B or S
+Allowed Values (MIAX):
+AUC Indicates an auction. Requires one of the following values:
+1 Opening
+2 Reopening
+3 Closing
+4 Routing
+5 LiquidityRefresh
+6 PairedPrime
+7 CustomerCrossPrime
+8 QualifiedContingentCrossPrime
+C ImmediateUncrossing
+I IIPOpening
+P RIPReEvalutionCross
+R RIPReEvalution
+U URIPAuctionOnArrival
+Y IIPOpeningCross
+Allowed Values (CHX):
+TradeType Name value pair, which requires value to be one of the following choices:
+CSP CSS entered correspondent trades
+AWA Away Market Executions
+CHX ECHX Trade
+MAN Manual
+DRP Drop copy away market execution
+NAM Recovery required
+RCV Recovery of NAME/NAME trade
+AWE Away sent electronically thru CHX systems
+AWM Away sent manually thru CHX systems
+RPT Allocation report
+AWF Away market trades cleared by CHX
+VEN Away market clearing flip - non-ORS
+AAW IB Alternative Away Market Execution
+AOR ORS Away market clearing flip
+RPS Riskless Principal Second Component Trade
+SNAP Sub-second Non-displayed Auction Process (SNAP) Trade
+executionID For OrderFill, this is the execution ID received from the routing vendor. The value is of type Text<40>
+executionMarket For OrderFill - requires a choice from the following values:
+XCHI Chicago Stock Exchange
+XNYS New York Stock Exchange
+XASE American Stock Exchange
+ARCX NYSE ARCA
+XBOS Boston Stock Exchange
+XPHL Philadelphia Stock Exchange
+XCIS National Stock Exchange
+XADF FINRA ADF
+XCBO Chicago Board Options Exchange
+XNAS NASDAQ Stock Exchange
+BATS BATS Stock Exchange
+BATY BATS Y - Exchange, Inc.
+EDGA Direct Edge A
+EDGX Direct Edge X
+IEXG Investors Exchange
+Allowed Values (NYSE Options):
+OpenAuction
+CUBEAuction
+Complex
+Cabinet
+Flex
+Man
+Allowed Values (NYSE Equities):
+Auction
+OPEN
+CLOSE
+CROSS
+Allowed Values (IEX):
+I Continuous Trade on IEX
+L Traded with Displayed Liquidity
+S Self Trade on IEX
+X Opening Match on IEX
+O Opening Auction on IEX
+C Closing Auction on IEX
+H Halt Auction Opening on IEX
+N IPO Auction Opening on IEX
+Allowed Values (NASDAQ Options - ISE, GEMINI, Mercury only): liquidityCode Name value pair, requires one of the following values
+0 None
+1 Maker
+2 Taker
+4 Response
+5 Hidden
+6 OpeningRotation
+7 Cross
+8 FlashedOrder
+9 FlashResponse
+10 RoutedOut
+11 TradeReport
+12 ComboMakerAgainstCombo
+13 ComboTakerAgainstCombo
+14 ComboResponseAgainstCombo
+15 ComboHiddenAgainstCombo
+16 ComboOpeningRotation
+17 ComboCross
+18 ComboTakerAgainstRegular
+19 RegularMakerAgainstCombo
+20 ComboTakerAgainstIO
+21 RegularTakerAgainstIO
+22 IOMakerAgainstCombo
+23 IOMakerAgainstRegular
+24 RegularMakerAgainstIOParticipant
+25 IOParticipantTakerAgainstRegular
+26 BrokenPriceImprovement
+27 BrokenFacilitation
+28 BrokenSolicitation
+29 ComboBrokenPriceImprovement
+30 ComboBrokenFacilitation
+31 ComboBrokenSolicitation
+32 Block
+33 BlockResponse
+34 DirectedResponse
+35 Facilitation
+36 FacilitationResponse
+37 PriceImprovement
+38 PriceimprovementResponse
+39 Solicitation
+40 SolicitationResponse
+41 QualifiedContingentCross
+42 CustomerToCustomer
+43 ComboFacilitation
+44 ComboFacilitationResponse
+45 ComboPriceImprovement
+46 ComboPriceImprovementResponse
+47 ComboSolicitation
+48 ComboSolicitationResponse
+49 ComboQualifiedContingentCross
+50 ComboCustomerToCustomer
+51 SweepRoutedOut
+52 SweepTradeReport
+OTHER Other
+BuyMatchId Unsigned value
+SellMatchId Unsigned value
+AuctionId Unsigned value
+TradeSource Name value pair, requires one of the following values
+0 AUTO_EXECUTION
+1 OPENING
+2 FLASH
+3 EXPOSURE
+4 BLOCK
+5 PIM
+6 PIM_COMBO
+7 FAC
+8 FAC_COMBO
+9 SOL
+10 SOL_COMBO
+11 CCC
+12 CCC_COMBO
+13 QCC
+14 QCC_COMBO
+15 MANUAL
+16 NOS
+17 OPENING_UNCROSS
+18 UNCROSS
+OTHER OTHER
+Allowed Values (NASDAQ Options - PHLX, NASD, and BX only):
+TradeSource Name value pair, requires one of the following values
+1 AUTOEX
+2 DET
+3 EBOOK
+4 NOS
+5 FBMS
+6 SWEEP
+7 QUOTE_M
+8 CO_SWEEP
+9 LEGGING
+10 COMPLEX
+11 OPENING
+12 COLA
+13 COCRA
+14 PIXL_AUTO
+15 PIXL_STOP
+16 QCC
+17 QCC_FBMS
+FLEX FLEX
+OTHER OTHER
+Allowed Values (NASDAQ Equities):
+LIQ Name value pair, requires one of the following values
+1 Added
+2 Removed
+3 Routed
+4 DOT
+5 Opening Trade (on NYSE)
+6 On-Close order (on NYSE)
+7 Non-displayed adding liquidity
+8 Open Cross
+9 Open Cross (imbalance-only)
+10 Closing Cross
+11 Closing Cross (imbalance-only)
+12 Halt/IPO Cross
+13 Halt Cross
+14 Re-Routed by NYSE
+15 Odd Lot Execution (on NYSE)
+16 Added Liquidity (on NYSE)
+17 Routed to BX
+18 NYSE Other
+19 Routed to PSX
+20 Executed in Open, Close, or Re-open on ARCA
+21 Added post-only
+22 Removed liquidity at a midpoint
+23 Added liquidity via a midpoint order
+24 Displayed, liquidity-adding order improves the NBBO
+25 Displayed, liquidity-adding order sets the QBBO while joining the NBBO
+26 Retail designated execution that removed liquidity
+27 Retail designated execution that added displayed liquidity
+28 Retail designated execution that added non-displayed liquidity
+29 RPI (Retail Price Improving) order provides liquidity
+30 Retail Order removes RPI liquidity
+31 Retail Order removes price improving non-displayed liquidity other than RPI liquidity
+32 Added displayed liquidity in a Group A symbol
+33 Added non-displayed liquidity in a Group A symbol
+34 Removed liquidity in a Group A symbol
+35 Added non-displayed mid-point liquidity in a Group A symbol
+36 Added displayed liquidity in a SCIP Symbol
+37 Displayed, liquidity-adding order improves the NBBO in a SCIP Symbol
+38 Displayed, liquidity-adding order set the QBBO while joining the NBBO in a SCIP Symbol
+39 Displayed, liquidity-adding order improves the NBBO in pilot symbol during specified LULD Pricing Pilot timeframe
+40 Added displayed liquidity in a pilot symbol during specified LULD Pricing Pilot timeframe
+41 Removed liquidity in a pilot symbol during specified LULD Pricing Pilot timeframe
+42 Halt Cross, orders entered in pilot symbols during the LULD Trading Pause
+executionTimestamp
+Events: Order Trade Correction, Option Trade Correction
+When a trade is reported, the time of the trade is reported as the eventTimestamp. The executionTimestamp is used in a correction event if the time of the trade needs to be changed.
+exerciseStyle
+Reference Data: Simple Option Series Dictionary Entry
+Specifies the exercise style of the Option Series in Simple Option Series Dictionary Entry.
+Allowed Values:
+American
+European
+expirationDate
+Reference Data: Simple Option Series Dictionary Entry
+The date an options contract will expire, taking the format: YYYYMMDD.
+fillID
+Events: Order Fill Event, Stock Leg Fill Event
+A unique identifier for the transaction. The combination of reporter, date, symbol, side, and fillID should be unique.
+floorBroker
+Events: Option Trade Event
+The Member Alias of the executing floor broker. handlingInstructions
+Events: Order Accepted Event, Order Route Event, Order Modified Event, Order Modify Route Event, Order Restatement Event, Simple Option Order Accepted Event, Complex Option Order Accepted Event, Complex Option Order Modified Event, Stock Leg Order Event, Option Order Modified Event, Stock Leg Modified Event, Option Route Event, Modify Option Route Event, Options Order Restatement Event
+The order handling instructions field is a way to provide multiple instruction codes in a somewhat flexible manner. This field will contain zero or more order instruction codes, each separated by a single pipe symbol (ASCII decimal 124, hex 7C). Codes which require a value will include that value immediately after the code Field Name and a single equal sign (ASCII decimal 61, hex 3D).
+All instructions that apply to the order are to be included.
+Allowed Values (Boolean, presence indicates truth):
+AON All or None
+AUC Auction Eligible
+DNR Do Not Route
+FOK Fill or Kill
+IOC Immediate or Cancel
+ISB Intermarket Sweep Book
+ISO Intermarket Sweep
+NH Not Held
+OPG At the Opening
+PSO Post Only
+WTP Wash Trade Prevention
+Note: Some exchanges have special values to indicate handling of ISO orders. All ISO orders must be marked with the boolean ISO value. Thus, if an exchange denotes an ISO order with some custom attribute, it must also be marked with the common ISO value.
+Some allowed values (are name value pairs and must be accompanied by a value) must be accompanied by further explanation or additional information:
+Allowed Values (Name Value Pairs):
+MIN Minimum Quantity - requires an Integer value, representing he minimum quantity allowed to be executed in a single transaction (e.g., MIN=1000).
+WD With Discretion Price - requires a Numeric value, representing the discretion price (e.g, WD=12.50)
+STP Stop Price - requires a Numeric value representing the stop price (e.g., STP=17.95)
+XDATE Expire Date - requires a Date value, representing the date that the order expires. The value must be in Date format (e.g., May 15, 2017 would be XDATE=20170515). The order expires at the close of the specified date.
+XTIME Expire Time - requires a Time value, representing the time that the order expires. The value must in a valid Timestamp format.
+R2E Route to Exchange - requires Exchange ID (e.g., R2E=G). The desired route destination is not the party receiving the actual route. The party receiving the route does not have discretion as to where to route the order. It must be routed to a specific exchange.
+R2M Route to Industry Member - requires Member Alias (e.g., R2E=ABC123). The desired route destination is not the party receiving the actual route. The party receiving the route does not have discretion as to where to route the order. It must be routed to a specific industry member.
+R2O Route to Other - requires Text(20) (e.g., R2O=Somebody). The desired route destination is not the party receiving the actual route. The party receiving the route does not have discretion as to where to route the order. It must be routed to an entity who is neither an exchange nor an industry member (i.e., the entity does not have a CAT reporting responsibility).
+Allowed Values (CBOE Name Value Pairs):
+MIT Market if touched, becomes a market order if the price is touched. Requires a price value (e.g, MIT=20.53).
+AucResp A response to an auction, the remainder is canceled at the end of the auction. Requires a integer value representing the auction ID being responded to. (e.g., AucResp=1234).
+Reserve Reserve, only a portion of the order is displayed. Requires an integer value representing quantity. (e.g., Reserve=300).
+PMM Preferred market maker, requires a text (text, 10) value representing the acronym of the preferred market maker. (e.g., PMM=FRMA)
+AIM Automated Improvement Mechanism. Requires a choice value (e.g., AIM=AIM) selected from the following list
+AIM standard AIM
+AIQ QCC Primary Order
+AIS Sweep and AIM primary order
+AIR Re-route if cannot AIM primary order
+ARE Contra order to AIM. Requires a text (text 20) value representing the primary order ID. (e.g., ARE=AB54321)
+AREOUT Contra order to AIM where the user can opt out. Requires a text (text 20) value representing the primary order ID. (e.g., ARE=AB54321)
+Designation Order designation, requires a choice value (e.g., Designation=4) from the following list of values
+1 Tied Hedge
+2 SPXCOMBO
+3 Tied Hedge and Cash Spread
+4 SPXCOMBO and Cash Spread
+5 Cash Spread
+UHI User handling instruction, requires a choice value (e.g., UHI=4) from the following list of values
+1 Do Not Auction
+2 Held
+3 Solicited Order
+4 Held and Solicited
+5 Held and no COA
+6 Electronic Only
+7 Electronic Only and Solicited
+8 Electronic Only and no COA
+Allowed Values (BATS Name Value Pairs):
+ExecInst Provides additional values for execution instructions that aren't already present in orderType or other handlingInstructions values. Requires a choice value (e.g., ExecInst=U) from the following list
+N No special instructions
+s sweep
+M hidden peg to midpoint
+L alternative midpoint peg to less aggressive midpoint or 1 tick inside of NBBO
+m midpoint peg no lock hidden peg to midpoint but duck at or beyond limit
+d displayed peg order with discretion to the midpoint
+g AllOrNone
+I midpoint match (EDGX)
+Q market maker peg order
+v Dart dark route before outbound
+w DoNotDart opt of dart
+x ImproveOnly BATS only IOC that only matches better than NBBO
+y TAISO
+z DarkScan hit scan fast DLPs first
+t DarkScanWithoutDart
+r LateAuction late limit on open/close
+U route peg order
+u DartOnly route only to a dark venue
+F FastDart
+S SuperDart
+f ISO
+R PrimaryPeg
+Reserve Number of shares of a reserve order to display. Requires an UNSIGNED value
+ExtExecInst Requires a choice from the following values:
+N None
+T Retail Price Improving
+P Retail Order - Price Improvement Only
+R Retail Order
+S Retail Order NoFlagCLC
+MaxRemovePct The max percentage an order is allowed to remove before booking. Requires an Unsigned (e.g., MaxRemovePct=10)
+AttributedOrder Requires a choice value from the following list
+N None
+Y Attributed
+R Retail
+DisplayRange This will be of type Unsigned, and is used for a “random replenishment” reserve order. The reload quantity is randomly selected using Reserve +/- displayRange e.g. Reserve of 1000, displayRange of 200, reload quantity will be randomly selected from 800, 900, 1000, 1100, or 1200
+Allowed Values (BATS Name Value Pairs - Equities Only):
+TifMod Supplemental time-in-force information. Requires a choice value (e.g., TifMod=1) from the following list
+1 include early (7 – 8 AM) and pre-market trading sessions (8 AM – 9:30 AM)
+2 include pre-market session (8 - 9:30 AM)
+3 include early (7- 8 AM), pre (8 – 9:30 AM), and post-market sessions (4 -5 PM BZX and BYX, 4 – 8 PM for EDGA and EDGX)
+4 include pre (8 – 9:30 AM), and post-market sessions (4 -5 PM BZX and BYX, 4 – 8 PM for EDGA and EDGX
+Allowed Values (BATS Name Value Pairs - Options Only):
+TifMod Supplemental time-in-force information. Requires a choice value (e.g., TifMod=1) from the following list
+1 include pre-market session (7:30 - 9:30 AM)
+Allowed Values (BOX Name Value Pairs):
+EP Directed Order Executing Participant. Requires a BOX Participant ID string value (e.g., EP=XYZ123).
+IML Indicate the Inter Market Linkage Behavior for the order. Requires a choice value from the following list of values
+FLASH
+ROUTING
+NONE
+NBBO
+ISO
+CONTINGENT
+NOFLASH
+PT Indicate BOX Price Term for the order. Requires a choice value from the following list of values
+PIP
+SOLICITATION
+FACILITATION
+CROSS
+DIRECTED
+PREF
+FLOOR
+OT Indicate the order type for auction phase. Requires a choice value from the following list of values
+IMPROVE
+INITO
+EXPOSED
+CROSS
+CONTINGENT
+MBF
+GTD Indicates Date in YYYYMMDD Format
+QT Requires a choice value from the following list of values
+MINIMUM
+SURRENDER
+MIP
+AQ Indicate the additional quantity when QT is either MINIMUM or SURRENDER. Requires an unsigned integer value (e.g, AQ=1000)
+AP This will be field of type Price
+AT Requires a choice value from the following list of values
+PIP
+SOLICITATION
+FACILITATION
+CROSS
+FIXED
+FLOOR
+AID This will contain a n UNSIGNED number that will allow BOX to track "Auction Phase Number" (e.g., AID=123456)
+Allowed Values (CHX):
+ExecInst Requires a choice value (e.g., ExecInst=f) from the following list:
+5 Held
+E DNI - Do not increase
+F DNR - Do not reduce
+K Cancel on Trading Halt
+X TALG - Trade Along
+y Trade At Intermarket Sweep (TAISO)
+q Always Quote
+I Midpoint Cross
+v Stock-Option (for cross order only)
+TradeThruExemptReason Requires a choice value (e.g., TradeThruExemptReason=2) from the following list:
+1 Benchmark
+2 QCT Qualified Contingent Trade
+3 Bonafide Error Indicator
+PriceSliding Requires a choice value (e.g., PriceSliding=L) from the following list:
+L CHX Only – Slide limit price on lock NBBO
+S CHX Only – Slide limit price on lock or cross NBBO
+MatchTradePrevention Requires a choice value (e.g., MatchTradePrevention=N) from the following list:
+I MTP Inactivate
+N MTP Cancel Newest
+O MTP Cancel Oldest
+B MTP Cancel Both
+MTPSublevelInd Requires a choice value (e.g., MTPSublevelInd=1) from the following values:
+[0-9,A-Z,a-z]
+Allowed Values (NYSE Options):
+NOW
+ISO
+AON
+PNP
+PNPLO
+PNPB
+ALO
+FloorTrade
+FloorTradeNamesLater
+FloorTradeNamesLaterAllocation
+ClearTheBook
+Cabinet
+Flex
+CUBEAUCPI
+CUBEAUCF
+QCC
+COA
+PNP+
+Stop Requires a Price value (e.g., Stop=42.42)
+StopLimit Requires a Price value (e.g., StopLimit=42.42)
+Allowed Values (NYSE Equities):
+ALO
+ISO
+TradeAtISO
+Non-Routable
+RoutableIOC
+Tracking
+Non-Display
+RPI
+Retail
+MPEG Market Peg
+PPEG Primary Peg
+DPO
+DPP
+MPL
+PO
+945
+355
+945-355
+ImblOffset
+NonRoutableIOC
+ClosOffset
+LPEG
+DMP
+DLP
+NoMPL
+NoIOI
+NoMPL-IOI
+Allowed Values (NASDAQ Options):
+Boolean Values
+PostOnly
+PostOnlyPrice
+WAIT
+AllowFlash
+AllowExposure
+DNR
+DNTT (Do not trade through)
+DNA (Do not Auction)
+AO (Auction Only)
+Name Value Pairs
+DMM STRING; DMM Name
+DisplayWhen For reserve orders, requires one of the following
+1 Immediate
+2 onExhaust
+RefreshMax UNSIGNED; Contracts
+RefreshMin UNSIGNED; Contracts
+InitDispContracts UNSIGNED; Contracts [Initial Display Contracts for reserve orders] RoutingStrategy Must be one of the following
+SRCH
+FIND
+SEEK
+RespAuctionId UNSIGNED; auctionId
+MIN UNSIGNED; Contracts
+OrderSource Must be one of the following
+FIX
+OTTO
+SQF
+FBMS_FIX
+FBMS
+PRECISE_FIX
+BrokerPct NUMERIC<3,4>; Percentage
+EffectiveTime TIME
+StepUpPrice PRICE
+StepUpPriceType Must be one of the following
+1 Market
+2 Limit
+DMA DMA Name [for route event], where ‘DMA Name’ can have following values:
+CITI
+WEX
+MLGW
+GSG
+OTHER
+DestExch Dest Exch [for route event], where ‘DestExch’ can have following values:
+11 AMEX
+12 BOXE
+13 CBOE
+14 EDGO
+15 GMNI
+16 ISEX
+17 MCRY
+18 MIAX
+19 NYSE
+20 MPRL
+21 NSDQ
+22 NOBO
+23 CBC2
+24 PHLX
+25 BATS
+1 BNY
+2 CHBC
+3 LBKI
+4 FOGS
+OTHER OTHER
+Allowed Values (NASDAQ Options - ISE, GEMINI, and Mercury):
+CrossType Value must be on of the following
+1 None
+2 Close
+3 Open
+4 PriceImp
+5 QCC
+6 Solicit
+7 Facilit
+8 Flash
+9 Block
+10 Exposure
+11 Cust
+OTHER OTHER
+Allowed Values (NASDAQ Options - PHLX, NASD, BX):
+CrossType Value must be on of the following
+1 None
+2 Close
+3 Open
+4 Complex
+5 Open Complex
+6 Close Complex
+7 PIXL
+8 QCC
+9 SOLICIT
+10 Complex PIXL
+11 Complex SOLICIT
+OTHER OTHER
+Allowed Values (NASDAQ Equities):
+MELO for a Midpoint ELO order
+SUPL for a Supplemental order
+RPI for a Retail Price Improvement Program order
+ExecBroker Value must be on of the following
+DOTA
+DOTD
+DOTM
+DOTI
+MOPP
+TFTY
+SCAN
+SKIP
+SKNY
+SAVE
+QSAV
+QTFY
+DOTZ
+LIST
+CART
+SOLV
+QSLV
+ESCN
+MOPB
+RFTY
+QRTY
+INET
+Display Value must be one of the following
+1 Attributable-Price to Display
+2 Anonymous-Price to Comply
+3 Non-Display
+4 Post-Only
+5 Imbalance-Only (for opening and closing cross only)
+6 Mid-Point
+7 Mid-Point Post Only
+8 Post-Only and Attributable – Price to Display
+9 Retail Order Type 1
+10 Retail Order Type 2
+11 Retail Price Improvement Order
+ExecInst Value must be one of the following
+1 Midpoint Peg
+2 No Peg
+3 Market Peg
+4 Quoting Peg
+5 Primary Peg
+6 INAV pegging
+7 means Intermarket Sweep Order (ISO)
+8 means Trade-at Intermarket Sweep Order
+9 means Reactive Trade Now
+10 means Reactive Trade Now opt-out
+initiator
+Events: Order Modified Event, Order Canceled Event, Quote Cancel Event, Option Order Modified Event, Complex Option Order Modified Event, Stock Leg Modified Event, Option Order Canceled Event
+Indicates who initiated a cancel or modification request. If an order/quote is implicitly modified or canceled via an unsolicited action (e.g., peg order price change or cancelation due to timeout), then the initiator is the exchange itself.
+If an order/quote is modified or canceled as a result of an explicit request from the party that sent the order/quote, then the initiator is the firm/market maker that sent the explicit modify/ cancel request.
+Thus, all explicit modify/cancel requests will have an initiator of either Firm or MarketMaker, as appropriate and all implicit, unsolicited modify/cancel actions will have an initiator of Exchange.
+Allowed Values:
+Firm
+Exchange
+MarketMaker
+IPO
+Reference Data: Symbol Entry
+Indicates whether the issue is an Initial Public Offering ("IPO"). It will be set to false on the day after the IPO occurs (required for NMS).
+issueType
+Reference Data: Symbol Entry
+Specifies the type of equity being described in the equity symbol entry.
+Allowed Values:
+NMS
+OTC
+Index
+ETF
+kind
+Reference Data: Option Series Dictionary Entry, Complex Option Dictionary Entry
+Specifies if an option is a simple, complex, flex, or percentage denominated flex option. For the value FLEXPCT, the strike price and order prices of the option are in percentages.
+Allowed Values:
+Complex
+Standard
+Non-Standard
+FLEX
+FLEXPCT
+leavesQty
+Events: Order Canceled Event, Order Trade Event, Order Fill Event, Order Cancel Route Event, Order Restatement Event, Option Order Canceled Event, Option Cancel Route Event, Option Trade Event, Stock Leg Fill Event, Options Order Restatement Event
+The quantity remaining unfilled after the event. The meaning of this field is subjective depending on the event, refer to each individual event definition for more detail.
+legType
+Reference Data: Complex Option Dictionary Entry
+For a Complex Option Dictionary Entry, this field defines the type of each leg.
+Allowed Values:
+Equity
+Index
+Option
+liquidityCode
+Events: Order Trade Event, Option Trade Event
+Included in the side trade details for options and equity trade events, represents whether a given side was adding or removing liquidity.
+Allowed Values:
+Added
+Removed
+RoutedOut
+Opening-ReopeningAuction
+ClosingAuction
+CrossOrderExecution
+Other
+listedSymbol
+Reference Data: Symbol Dictionary Entry
+The symbol in the symbology of the listing exchange.
+listingParticipant
+Reference Data: Symbol Entry, Symbol Dictionary Entry
+The exchangeID of the listing exchange for the symbol being described in the event where this field is present.
+lotSize
+Reference Data: Symbol Entry
+Used in a symbol definition entry to state the number of shares in a round lot.
+marketMaker
+Events: Quote Event, Quote Cancel Event
+The Member Alias assigned by the SRO to identify the market maker issuing the quote or quote cancel. In the case where a market maker has multiple users (e.g., acronyms used to differentiate users within the same MM), there would be a separate Member Alias given to each user or sub-account.
+memberAliases
+Reference Data: Member Dictionary Entry
+A list of member aliases for an SRO member.
+mktMkrSubAccount
+Events: Simple Option Order Accepted Event, Option Order Modified Event, Option Trade Event, Option Order Restatement Event, Post Trade Allocation Event
+The sub-account for the market maker. This is a text field and will be treated as pass through data - not validated. nbbPrice
+Events: Order Accepted, Order Route, Order Modified, Order Trade, Order Modify Route, Simple Option Order Accepted, Stock Leg Order, Option Order Modified, Stock Leg Modified, Option Route, Modify Option Route, Simple Option Trade
+The national best bid price at the moment the event. If the event changes the NBBO, this is the national best bid price before the change effected by the event, in this sense, this field is always the national best bid price immediately before the event occurs. See this field in context of the event definitions for more info.
+nbbQty
+Events: Order Accepted, Order Route, Order Modified, Order Trade, Order Modify Route, Simple Option Order Accepted, Stock Leg Order, Option Order Modified, Stock Leg Modified, Option Route, Modify Option Route, Simple Option Trade
+The national best bid quantity at the moment the event. If the event changes the NBBO, this is the national best bid quantity before the change effected by the event, in this sense, this field is always the national best bid quantity immediately before the event occurs. See this field in context of the event definitions for more info.
+nboPrice
+Events: Order Accepted, Order Route, Order Modified, Order Trade, Order Modify Route, Simple Option Order Accepted, Stock Leg Order, Option Order Modified, Stock Leg Modified, Option Route, Modify Option Route, Simple Option Trade
+The national best offer price at the moment the event. If the event changes the NBBO, this is the national best offer price before the change effected by the event, in this sense, this field is always the national best offer price immediately before the event occurs. See this field in context of the event definitions for more info.
+nboQty
+Events: Order Accepted, Order Route, Order Modified, Order Trade, Order Modify Route, Simple Option Order Accepted, Stock Leg Order, Option Order Modified, Stock Leg Modified, Option Route, Modify Option Route, Simple Option Trade
+The national best offer quantity at the moment the event. If the event changes the NBBO, this is the national best offer quantity before the change effected by the event, in this sense, this field is always the national best offer quantity immediately before the event occurs. See this field in context of the event definitions for more info.
+note
+Events: Note Event
+Free form text provided by the exchange to describe the notation of the event.
+noteType
+Events: Note Event
+For a note event, classifies the type of note.
+Allowed Values:
+MISC
+CBOE Note Types
+CBOE:1 Order Route Event (When an order is routed between internal CBOE systems). The source and destination will indicate more details.
+CBOE:2 Cross Order Route Event
+CBOE:3 Auction Start
+CBOE:4 Auction End
+CBOE:5 PAR_BROKER_USED_MKT_DATA
+CBOE:6 PAR_BROKER_MKT_DATA
+CBOE:7 PAR_BROKER_LEG_MKT
+CBOE:8 PAR_MANUAL_MARKET_DATA
+NYSE Options Note Types
+Floor
+NYSE Equities Note Types
+CrossingSession
+onlyOneQuote
+Events: Quote Event, Quote Cancel Event
+True if the system allows only one quote for the particular market maker; false otherwise.
+openCloseIndicator
+Events: Simple Option Order Accepted, Options Modified, Post Trade Allocation, Options Restatement or sideDetail of Option Trade events. (When this field is present in the sideDetails of an options trade event, it is applicable only when the side of the trade is an order)
+Indicates the position of the order.
+Allowed Values:
+Open
+Close
+Unspecified
+optionID
+Reference Data: Simple Option Series Dictionary Entries, Complex Option Dictionary Entries Events: All events for Options Exchanges
+The unique ID assigned to this option by the reporter. None of any two simple/complex/flex options should receive the same ID.
+orderAttributes
+Events: Order Accepted, Order Modified, Order Restatement, Simple Option Order Accepted, Complex Option Order Accepted, Complex Option Order Modified, Stock Leg Order, Option Order Modified, Complex Order Modified, Stock Leg Modified, Option Order Restatement
+The order attributes field is a way to provide attributes of an order that are not necessarily the same as handling instructions.
+For example, the rank price of an order, or the participant with the best bid.
+Allowed Values:
+RNKP Rank Price - requires a Price value, representing the price used to rank the order in the book (e.g., RNKP=10.25).
+NBBPAR Participant at the best bid - requires a Participant ID, representing the participant at the best bid (e.g, NBBPAR=Par1)
+NBOPAR Participant at the best offer - requires a Participant ID, representing the participant at the best bid (e.g, NBOPAR=Par1)
+Allowed Values (CBOE):
+MPID Market participant ID, requires an alphanumeric(8) value. (e.g., MPID=A12345)
+MeetExchangeID Meet Exchange ID, requires a text(8) value. (e.g., MeetExchangeID=B76543)
+Branch Branch ID, requires a alphanumeric(8) value. (e.g., Branch=ABCD5)
+BranchSeqNbr The branch sequence number, requires an integer(10) value. (e.g., BranchSeqNbr=500321)
+CorrespFirm The corresponding firm, requires an alphanumeric(8) value. (e.g., CorrespFirm=987765B)
+UserID The user ID. Requires a text(8) value. (e.g., UserID=4321A)
+Extensions Order Extensions. Requires a text(256) value.
+NBBOProtection Specifies if the order is NBBO protected. Requires a choice value from one of the following choices: true, false. (e.g., NBBOProtection=false).
+Allowed Values (BATS):
+AckSubLiquidity This is a subset of the SubLiquidity values. Better prices are offered (in some cases) if an order is at the NBBO. This tells the member on order entry if their order did that. Requires a choice value (e.g., AckSubLiquidity=N) from the following list:
+N Normal
+S Setter
+J Joiner
+r Persisted (GTC restatement)
+AddLiquidityOnly Values used for "Post Only" orders. Requires a choice value (e.g., AddLiquidityOnly=A) from the following list of values:
+A Add only, don't remove liquidity
+B Bypass removing hidden peg
+R Allow removal
+L don't remove at limit
+AllowPriceSlide Describes what to do with an order if it locks/crosses with the NBBO. Requires a choice value (e.g., AllowSidePrice=M) from the following list:
+S allow slide and nerf
+R no nerf and no slide
+L allow slide no nerf
+P price adjust
+m multiple price adjust
+M slide nerf unnerf when possible
+H hide not slide
+N don't re-scrape book at limit
+D Slide Price
+E Slide Price but no Nerf
+X Don't Slide Don't Reject
+C Bold but no Nerf
+m Multiple Price Adjust
+K Cancel Back
+AuctionType Auction type, used for fee purposes. Requires a choice value (e.g., AuctionType=H) from the following list:
+O open
+C close
+H halt
+I IPO
+N none
+c Cboe Market Close
+Display Display. Requires a choice value (e.g., Display=V) from the following list:
+V visible
+I invisible
+Executable Further describes the status of an order if it is/ is not yet live or executable. Can be updated with a modify event. Requires a choice value (e.g. Executable=W) from the following list:
+E order is executable
+P order is route pending
+W order in a wait state
+O open auction MOO/LOO/LLOO + pre-open RHO
+C close auction MOC/LOC/LLOC
+U queued
+T order is stop pending
+S suspended
+Q non executable visible quote
+D pending queued
+I Periodic Auction
+A Step Up
+b BAM Auction
+c COA (Options only - Complex Order Auction - order is not currently executable as auction is not complete)
+q QCC
+BookLiquidity Signifies whether the order is being added to the book. Requires a choice from the following values:
+A Booked
+R Not Booked
+X Routed
+B Booked Remainder
+Q Wait
+C Auction
+MODR Modify reason, requires a choice value (e.g., MODR=+) from the following list. Note that in this list the acceptable values are surrounded by quotes because the list contains non alphanumeric values:
+'P' peg adjustment
+'C' Cboe Market Close
+'+' price was un-slid
+'L' liquidity flag was changed (resting order routed away or fully delivered)
+'R' user reduce (no loss of priority)
+'D' adjustment of discretion price ONLY no loss in priority (midpoint discretionary peg orders)
+'U' user other
+'-' an external NBBO change (sip) caused some sort of change in the order
+'^' Reroute (order lifted from book to reroute)
+'B' un-bolt OR bolt-expire
+'W' wash
+'T' wait order
+'!' reload of displaySize and loss of priority
+'K' working price slid back to display price due to another market locking our protected quote
+‘S’ stop order
+‘A’ order routed away due to ROOC e.g. a few minutes before an open/close/ipo/halt auction
+‘E’ sweep SWPA or SWPB order after route plan has been developed
+'@' Trading At Last
+'X' Locked In Cross
+'Y' Recovery
+PWASH Prevent wash, more information about wash prevention. Requires a choice value (e.g., PWASH=P) from the following list:
+N do not prevent (none)
+F prevent same firm match
+C prevent clearing firm match
+P prevent port-owner match
+RTLM Route to listing market, specifies whether the order can be routed to the opening auction, the closing auction, or both on the listing exchange. Requires a choice value (e.g., RTLM=O) from the following list:
+N none
+O only on the open
+C only on the close
+B both (on the open or close)
+H Halt
+ROUTESTRAT The route strategy used internally in the Bats system. Requires a choice value (e.g., ROUTESTRAT=O) from the following list:
+O default, let the router select the strategy
+F failover strategy for use when the router has a NoQuote condition
+L legacy (emulate the behavior of the old router)
+C cycle (sequentially route walking depth of book)
+K dark liquidity scan
+T toggle (causes the router to cycle through various other strategies on a per-order basis)
+B ParT (Parallel Top)
+S ParD (Parallel Depth), exhaust price level before proceeding
+2 Par2D (Parallel Depth including multiple price levels)
+M Slim (predefined set of markets, DRT and then ALL)
+m SlimPlus (Slim, but send to BYX before scraping the local book)
+R Trim, scrape local book on way in (predefined set of markets, DRT, and then another predefined set of markets)
+r Trim, but don't scrape local book on way in
+P Trim2
+p Trim2, but don't scrape local book on way in
+Q Trim3
+q Trim 3, but don't scrape local book on way in
+G MidPoint routing
+b SWEEPB (Route to market centers to remove least amount of protected quote shares so order can post. No executions occur is order size too small to completely remove all protected quotes)
+i Book + IOC/(Day effective 10/21/14) Nasdaq
+t Book + DRT + IOC/(Day effective 10/17/14) NYSE
+x Book + IOC/(Day effective 10/17/14) NYSE
+f Book + IOC LavaFlow
+a ISO Sweep of all protected markets (similar to BATS Parallel T)
+o ROBB
+c ROCO
+l ROUC
+Z RMPT
+z IOCM
+u Dark lit
+W Lit sweep
+D Directed
+A ALLB
+RESTA Resting action, specifies whether this order will go onto the Bats book or be routed away to post on somebody else’s book. Requires a choice value (e.g., RESTA=I) from the following list:
+I Integrated, will rest on the BATS book (though may not be resting at the point of the OA if it is a routed order, may never rest if it is a routed IOC)
+A PostAway, will rest on another exchange’s book, looking like a routed order that hasn’t come back to BATS
+D Dark
+E Expose
+REROUTE Reroute, specifies whether or not we can reroute an order (route it a second time after it has been booked), if the NBBO goes locked or crossed. Requires a choice value (e.g. REROUTE=N) from the following list:
+N none
+L onLock
+C onCross
+K onLockOddLot
+REJA Reject action, provides further information on action if the order can't be executed on entry. Requires a choice value (e.g., REJA=W) from the following list:
+O outbound
+R reject
+Z BZX only
+J BYX only
+N NASDAQ only
+A ARCA only
+C NSX only
+M CHX only
+X PHLX only
+K BEX only
+E ISE only
+U AMEX only
+D EDGA only
+G EDGX only
+Y NYSE only
+T TRACO only
+L FLOW only
+W CBSX only
+V DATA only
+H CTWO only
+S NOBX only
+F MIAX only
+g GMNI only
+r Dark Reject
+a Dark Auto
+x Dark Self Cross
+P Periodic
+t Wait
+p Primary Only
+b BXE Only
+c CXE Only
+q TRQX Only
+h XHFT Only
+l Bats Select
+e PERL Only
+m MERC Only
+i IEX Only
+Allowed Values (BOX):
+ST Requires a choice from the following list:
+InOrderBook
+Executed
+Exposed
+ToOla
+Directed
+CancelPending
+Eliminated
+TraderCancelled
+EliminatedOutOfLimit
+EliminatedByCircuitBreaker
+EliminatedOnDisconnection
+EliminatedByMarketControl
+EliminatedDueToUnpricedLeg
+EliminatedDueToTradingRestriction
+CancelledBySupervisor
+Received
+EliminatedDueToTradeLimitExceeded
+EliminatedDueToTradeActivityLimitExceeded
+EliminatedDueToMaximumNbTriggersLimitExceeded
+EliminatedDueToDrillThroughProtection
+Allowed Values (CHX Name Value Pairs):
+SettlementType Requires a choice value (e.g., SettlementType=0) from the following list:
+0 REG - Regular Way
+1 CASH - Cash
+2 NXT - Next Day
+3 T+2 - Trade Date + 2
+4 T+3 - Trade Date + 3
+5 T+4 - Trade Date + 4
+6 FUT - Future
+7 WI - When and If Issued
+8 SO - Sellers Option
+9 T+5 - Trade Date + 5
+S SLR - Settlement Days
+FutureSettlementDate Requires value (e.g., FutureSettlementDate=YYYYMMDD) when SettlementType is 6 or S. Value is a date in format YYYYMMDD.
+FutureSettlementDays Requires value (e.g., FutureSettlementDays=4) when settlementType is S. Value is an integer. It is the number of settlement days.
+ExpireSeconds Requires value (e.g., ExpireSeconds=3) when timeInForce is GFS. Value is an integer. It is the number seconds for the good-till-seconds order.
+ExpireDate Requires value (e.g., ExpireDate=YYYYMMDD) when timeInForce code is GTD. Value is an integer. It is the date for the good-till-date order.
+PegDiff Requires value (e.g., PegDiff=2) for SNAP Auction market peg order. Value is an integer. It is the number of ticks for the symbol.
+CancelOnSNAPAuctionFlag Requires value (e.g., CancelOnSNAPAuctionFlag=Y) for an order.
+Y When a SNAP Auction is invoked, the order will not participate in the SNAP Auction
+N When a SNAP Auction is invoked, the order will participate in the SNAP Auction
+SNAPMinExecRequiredFlag Requires value (e.g., SNAPMinExecRequiredFlag=Y) for a SNAP Auction order.
+Y Minimum SNAP Auction threshold required
+N Minimum SNAP Auction threshold not required
+SNAPConvertToAOOFlag Requires value (e.g., SNAPConvertToAOOFlag=Y) for a SNAP Auction order.
+Y Convert to SNAP Auction Only Order if a SNAP Auction has already started by another order.
+N Cancel Order if a SNAP Auction has already started by another order.
+SNAPAOOOneAndDoneFlag Requires value (e.g., SNAPAOOOneAndDoneFlag=Y) for a SNAP Auction order.
+Y SNAP Auction Only Order will only participate in one SNAP Auction, then it will be canceled.
+N SNAP Auction Only Order will participate in every SNAP Auction.
+CreationTimestamp Requires value (e.g., CreationTimestamp=20180415T143055.123456789) when the eventTimestamp is different from the creation timestamp.
+SNAPAuctionOrder Requires a choice value (e.g., SNAPAuctionOrder=s) from the following list:
+s SNAP Auction Order. Order used to potentially initiate a SNAP Auction.
+Allowed Values (NYSE Options):
+STP
+Reserve
+BOLD
+Exposed
+Covered
+Allowed Values (NYSE Equities):
+STP
+Reserve
+QOrder
+SOrder
+BOrder
+YGOrder
+RMO
+BrokerOrder
+ProactiveIns
+MinQty Requires Unsigned value (e.g., MinQty=1000)
+MFS <MinQty>; Requires Unsigned value (e.g., MFS=1000)
+PriceOffset <Price_offset>; Requires Price value (e.g., PriceOffset=0.01)
+MinTriggerSize <OppSideMinSizeTriggerValue>; Requires Unsigned value (e.g., MinTriggerSize=1000)
+MinPegSize <MinPegSize>; Requires Unsigned value (e.g., MinPegSize=1000)
+MaxDiscVol <MaxDiscVol>; Requires Unsigned value (e.g., MaxDiscVol=1000)
+CeilingFloorPrice <Peg_Price>; Requires Price value (e.g., CeilingFloorPrice=0.01)
+DiscPriceRange <disc_price_range>; Requires Price value (e.g., DiscPriceRange=0.01)
+TypeOfInterest A value from the following list of choices.
+DOTR
+CO
+EQAA
+EQBB
+EQDA
+EQDB
+EQGA
+RQGB
+SQAA
+SQBB
+SQDA
+SQDB
+DSQCC
+SQDC
+Allowed Values (IEX):
+RoutingStrategy Allowed values from the following list.
+u Router
+s Router Basic
+MinQtyInstruction Allowed values from the following list.
+C Composite
+M Minimum Execution Size with Cancel Remaining
+A Minimum Execution Size with AON Remaining
+AntiInternalizationGroupId Used for wash trade prevention. Allowed any two alphanumeric characters or the two-character string "--".
+[A-Za-z0-9][A-Za-z0-9] Depending upon the value used, these will be used to identify orders which have elected to not trade with identically marked orders from the same firm. The lower case and upper case characters are two distinct values. For example, "a1" and "A1" will be two distinct values.
+-- Represents free to trade with anyone.
+Allowed Values (NASDAQ Options):
+Boolean
+Persist
+PrimarySide
+Name Value Pairs
+PrivateReference Text<20>
+BrokerText Text<6>
+BranchSeqNum Text<20>
+Text Text<64>
+FloorBrk Text<6>
+Tag1AcctId Text<32>
+CrossClOrderId Text<64>
+CrossOrderId Text<64>
+StortSaleInd Value must be on of the following
+1 SHORT SALE
+2 SHORT SALE EXEMPT
+StockCapacity Value must be one of the following
+1 Agent
+2 Principal
+3 Riskless Principal
+Allowed Values (NASDAQ Equities):
+CrossType Value must be one of the following
+0 None
+1 Open
+2 Halt
+3 Close
+4 Pause
+5 Supplemental
+6 Retail
+CustomerType Value must be one of the following
+1 Retail Designated
+2 Non Retail Designated
+orderID
+Events: Order Accepted, Route, Modified, Canceled, Trade (sideDetails), Fill, Cancel Route, Modify Route and Restatement events, Simple Option Order Accepted, Complex Option Order Accepted, Stock Leg Order, Option Route, Option Order Modified, Complex Option Order Modified, Option Order Canceled, Modify Option Route, Option Cancel Route, Simple Option Trade, Stock Leg Fill, Option Order Restatement and Options Post Trade Allocation events
+The internal order ID assigned to the order by the exchange.
+orderType
+Events: Order Accepted, Order Routed, Order Modified, Order Restatement, Order Modify Route, Simple Option Order Accepted, Complex Option Order Accepted, Stock Leg Order, Option Order Modified, Complex Option Order Modified, Option Route, Option Order Restatement, Modify Option Route events
+The order type defines the type of order being placed, and must be exactly one of the permitted values. Some values are exchange specific. This document details the technical specifications for what is reported in this field, not necessarily how to determine what value to be included in each report. See the CAT website for exchange-specific guidance on how to determine which values to use for reporting specific orders.
+All Exchanges:
+AMPEG Alt Midpoint Peg - pegs to less aggressive of midpoint or 1 tick inside the NBBO
+BLK Block
+CAB Cabinet
+FAC Facilitation
+LEG Leg - Computed Price
+LMT Limit
+LOB Limit or Better
+LOC Limit on Close
+LOO Limit on Open
+LW Limit With or With Out
+MA At Market
+MIT Market If Touched
+MKT Market
+MOC Market on Close
+MOO Market on Open
+MDPEG Midpoint Discretionary Peg - a primary peg, but has discretion to the midpoint of the NBBO
+MPEG Midpoint Peg
+MMPEG Market Maker Peg - will peg at 8%, 20%, or 28% of the NBBO depending on symbol and time of day (follows the LULD bands). Designed to allow MMs to satisfy their quoting obligations without stub orders
+OB On Basis
+PPEG Primary Peg
+RPEG Market Peg
+RTPEG Route Peg - Non-displayed primary peg order that only interacts with orders that are about to be routed out with size <= peg order size
+SIM Simple
+SOL Solicitation
+STL Stop Limit
+STP Stop
+WW With or Without
+Allowed Values (NYSE Options):
+AutoMatch
+LimitCross
+Allowed Values (NYSE Equities):
+Peg
+LimitCross
+Allowed Values (IEX):
+DPEG Discretionary Peg
+originalOrderDate
+Events: Order Restatement, Option Order Restatement
+This field represents the most recent trading day for which the order was active. Note that this may not be the date when the order was originally accepted. If the order has been active for multiple trading days, this field must reference the most recent trading day when the order was active.
+originalOrderID
+Events: Order Modified, Order Restatement, Option Order Modified Event, Complex Option Order Modified Event, Stock Leg Modified, Option Order Restatement
+The most recent internal order ID before the modify / replacement created a new order ID.
+originalQuoteID
+Events: Quote Event
+The most recent quoteID of the existing quote before being updated or replaced.
+Participant ID
+Valid Participant ID values. Note that participants will use their Participant ID as their
+Reporter ID.
+Allowed Values:
+BZX Cboe BZX Exchange
+BYX Cboe BYX Exchange
+BOX BOX Options Exchange
+C2 Cboe C2 Exchange
+CBOE Cboe Exchange
+CHX Chicago Stock Exchange
+EDGA Cboe EDGA Exchange
+EDGX Cboe EDGX Exchange
+FINRA Financial Industry Regulatory Authority
+GEMX Nasdaq GEMX
+MRX Nasdaq MRX
+ISE Nasdaq ISE
+IEX Investor’s Exchange
+MIAMI Miami International Securities Exchange
+PEARL MIAX PEARL
+BX Nasdaq BX
+PHLX Nasdaq PHLX
+NASD The NASDAQ Stock Market
+NSX NYSE National
+NYSE The New York Stock Exchange
+AMER NYSE American
+ARCA NYSE ARCA
+price
+Events: Order Accepted, Route, Modified, Modify Route or Restatement events, Simple Option Order Accepted, Complex Option Order Accepted, Stock Leg Order, Option Order Modified, Complex Option Order Modified, Option Route, Modify Option Route, Option Order Restatement
+The limit price of the order. For a complex option, this is the net price of the order, which can be either positive, negative, or zero.
+Events: Order Trade, Order Fill, Trade Break, Trade Correction
+Trade/fill price of the trade/fill.
+Events: Post Trade Allocation
+The price of the allocation.
+primaryDeliverable
+Reference Data: Simple Option Series Dictionary Entries
+The symbol for the primary deliverable component of the option, in the symbology of the listing exchange for that symbol. Alternatively, if a symbol dictionary is provided, a valid alias could be used.
+putCall
+Reference Data: Simple Option Series Dictionary Entries
+Specifies if this simple option or option leg is a put or call.
+Allowed Values:
+Put
+Call
+quantity
+Events: Order Accepted, Route, Modified, Canceled, Trade, Fill, Modify Route, Order Restatement events; Simple Option Order Accepted, Complex Option Order Accepted, Stock Leg Order, Option Order Modified, Complex Option Order Modified, Stock Leg Modified, Option Route, Option Order Cancelled, Simple Option Trade, Stock Leg Fill, Modify Option Route, Option Order Restatement events
+The quantity of the order.
+quoteID
+Events: Note Event, Options Quote, Quote Cancel, Options Trade (sideDetails) and Stock Leg Fill events
+The ID assigned to this quote by the exchange to uniquely identify the quote.
+ratio
+Reference Data: Complex Option Dictionary Entries
+The ratio quantity of a complex option leg, relative to other legs. Ratios must already be
+reduced to the smallest units possible.
+reason
+Events: Trade Break, Trade Correction, Option Trade Break, Option Trade Correction, Post Trade
+Allocation
+Free format text field, with reason for the trade break or correction.
+reporter
+Events: Note event, Self Help Declaration
+Reference Data: Member Dictionary Entry, Symbol Dictionary Entry and Option Series Dictionary Entry
+Reporter ID of the entity reporting the events or reference data.
+result
+Events: Order Route, Order Cancel Route, Order Modify Route; Option Route, Modify Option Route, Option Cancel Route
+The result of the Route, Cancel Route or Modify Route request communicated to the exchange.
+Allowed Values:
+ACK Acknowledged
+REJ Rejected
+NR No Response
+UNSOL Unsolicited: only valid for an unsolicited cancel route
+resultTimestamp
+Events: Order Route, Order Cancel Route, Order Modify Route; Option Route, Modify Option Route, Option Cancel Route
+The date/time the result of Route, Modify Route, or Cancel Route request was received.
+revokedTimestamp
+Events: Self Help Declaration
+Date and time the self-help was revoked. If self-help is not revoked by the end of the day, this field may be left unreported or can be set to the closing time. However, another self-help event must be reported for the next day.
+routedOrderID
+Events: Order Accepted, Order Modified, Simple Option Order Accepted, Complex Option Order Accepted, Stock Leg Order, Option Order Modified, Complex Option Order Modified, Stock Leg Modified
+The ID assigned to this order by the routing firm when submitting the order to the exchange.
+Events: Order Route, Modify Route or Cancel Route, Option Route, Modify Option Route, Option Cancel Route
+The ID assigned to this order by the exchange for sending message to the routing broker.
+routedOriginalOrderID
+Events: Order Modified, Option Order Modified, Complex Option Order Modified, Stock Leg Modified
+The routedOrderID for the order, as sent by the routing broker in the original route message, or the most recent modify message (in FIX OrigClOrdId, in OUCH Existing Order Token).
+Events: Order Modify Route, Modify Option Route events
+The routedOrderID as represented in the original or most recent Route/Modify Route message sent to the routing broker.
+routingParty
+A string used to identify the entity on the other side of an accepted or route event.
+Events: Order Accepted, Order Modified, Simple Option Order Accepted, Complex Option Order Accepted
+In the events above, this is the unique identifier for the firm that sent the order to the exchange.
+Events: Order Route, Order Fill, Order Modify Route, Order Cancel Route, Option Route, Modify Option Route, Option Cancel Route
+In the events above, this is the firm to which the exchange routed the order.
+The routingParty on a ROUTE event must match the routingParty on the other side's ACCEPTED event.
+saleCondition
+Events: Order Trade, Order Fill, Trade Correction, Simple Option Trade, Stock Leg Fill, Option Trade Correction
+Indicates a special condition under which a trade was reported.
+The first character must be either 'E' or 'O' indicating whether the following characters are to be interpreted as OPRA sale condition codes for options or UTP/CTS sale condition codes for equities. 'E' stands for the UTP/CTS, while 'O' stands for the OPRA.
+The following characters will use the single-character codes as defined in the OPRA, UTP, and CTS specifications - one character code for as many conditions as apply. Note that the <space> character is a valid code.
+Second character if first character is O (OPRA Values):
+blank Indicates that the transaction was a regular sale and was made without stated conditions
+A Transaction previously reported (other than as the last or opening report for the particular option contract) is not to be cancelled
+B Transaction is being reported late and is out of sequence, i.e. later transactions have been reported for the particular option contract.
+C Transaction is the last reported for the particular option contract and is now cancelled.
+D Transaction is being reported late, but is in the correct sequence, i.e. no later transactions have been reported for the particular option contract.
+E Transaction was the first one (opening) reported for this day for the particular option contract. Although later transactions have been reported, this transaction is not to be cancelled.
+F Transaction is a late report of the opening trade and is out of sequence: i.e. other transactions have been reported for the particular option contract.
+G Transaction was the only one reported this day for the particular option contract and is now to be cancelled
+H Transaction is a late report of the opening trade, but is in the correct sequence, i.e., no other transactions have been reported for this particular option contract.
+I Transaction was executed electronically. This prefix appears solely for information; process as a regular transaction.
+J Transaction is a reopening of an option contract in which trading has been previously halted. This prefix appears solely for information; process as a regular transaction.
+K Transaction is an option contract for which the terms have been adjusted to reflect a stock dividend, stock split, or similar event. This prefix appears solely for information; process as a regular transaction.
+L Transaction represents a trade in two options in the same option class (a buy and sell in the same class). This prefix appears solely for information; process as a regular transaction.
+M Transaction represents a trade in two options in the same option class (a buy and sell in a put and a call). This prefix appears solely for information; process as a regular transaction
+N Transaction is the execution of a sale at a price agreed upon by the floor personnel involved, where a condition of the trade is that it be reported following a non-stopped trade of the same series at the same price.
+O Cancel stopped transaction
+P Transaction represents the option portion of an order involving a single option leg (buy or sell of a call or put) and stock. The prefix appears solely for information; process as a regular transaction.
+Q Transaction represents the buying of a call and the selling of a put for the same underlying stock or index. This prefix appears solely for information; process as a regular transaction
+R Transaction was the execution of an order that was ‘stopped’ at a price that did not constitute a Trade-Through on another market at the time of the stop.
+S Transaction was the execution of an order identified as an Intermarket Sweep Order
+T Transaction reflects the execution of a ‘benchmark trade’.
+X Transaction is Trade Through Exempt. The transaction should be treated like a regular sale.
+Second character if first character is E (UTP and CTS Values):
+@ Regular Sale
+blank No Sale Condition required within the category it appears (Long Trade Format Only)
+A Acquisition
+B Bunched Trade or Average Price Trade
+C Cash Sale
+D Distribution
+E Automatic Execution
+F Intermarket Sweep
+G Bunched Sold Trade
+H Price Variation Trade
+I Odd Lot Trade
+K Rule 155 Trade (AMEX)
+L Sold Last
+M Market Center Official Close
+N Next Day Trade (Next Day Clearing)
+O Opening Prints / Market Center Opening Trade
+P Prior Reference Price
+Q Market Center Official Open
+R Seller
+S Split Trade
+T Form T (Extended Hours Trade)
+U Extended Trading Hours (Sold Out of Sequence)
+V Contingent Trade
+W Average Price Trade
+X Cross Trade
+Y Yellow Flag Regular Trade
+Z Sold (out of Sequence)
+1 Stopped Stock (Regular Trade)
+4 Derivatively Priced
+5 Re-Opening Prints (Market Center Reopening Trade)
+6 Closing Prints (Market Center Closing Trade)
+7 Qualified Contingent Trade (QCT)
+8 Placeholder for 611 Exempt
+9 Corrected Consolidated Close (per listing market)
+sellDetails
+Events: Order Trade, Trade Correction, Simple Option Trade, Option Trade Correction
+Information for the sell side of the trade. Format and element definitions for sellDetails are described in sideTradeEvent in section 4.5.
+sentTimestamp
+Events: Quote Event, Quote Cancel Event
+The date/time when the market maker sent the quote or quote cancel to the exchange.
+sequenceNumber
+Events: All Stock Exchange Events, All Options Exchange Events
+The sequence number of the event, used to identify the sequence of events when multiple events have the same timestamps.
+The sequence number is required to be strictly increasing for a given reporter, date, and symbol, and can be used to sort each event in chronological order where multiple events have the same timestamp.
+For more detail, please refer to section 3.1: Timestamps and Sequence Numbers.
+session
+Events: Order Accepted, Order Route, Order Modified, Order Fill, Order Cancel Route, Order Modify Route, Simple Option Order Accepted, Complex Option order Accepted, Option Route, Modify Option Route, Option Cancel Route
+The name/ID of the session being used to send the order (from the routing firm to the exchange, or from the exchange to the routing broker). If this event represents a leg of a complex order, the Session must be the same as reported in the parent complex order.
+settlement
+Reference Data: Simple Option Series Dictionary Entry
+Specifies the settlement of option in Simple Option Series Dictionary Entries.
+Supported Values:
+AM At the open
+PM At the close
+Asian European/PM settlement, but the exercise settlement value is the arithmetic average of the closing prices of the underlying index on 12 pre-determined, consecutive monthly observation dates.
+Cliquet European/PM settlement, but the exercise settlement value is the greater of zero, or [(closing price of the underlying index on the initial trade date) * (sum of the monthly capped returns)] + strike price.
+side
+Reference Data: Complex Option Dictionary Entry
+Events: Order Accepted, Order Route, Order Trade, Order Fill, Order Restatement, Trade Correction, Simple Option Order Accepted, Complex Option Order Accepted, Stock Leg Order, Option Route, Option Trade, Stock Leg Fill, Post Trade Allocation
+Side of the event. Note that AsDirected and Opposite are only used for complex option order accepted events.
+Supported Values:
+Buy
+Sell
+Short
+Exempt
+Cross
+CrossExempt
+CrossShort
+CrossShortExempt
+AsDirected
+Opposite
+status
+Reference Data: Member Dictionary Entry
+The status of the member on the reporting date.
+Supported Values:
+Active An active member of the SRO (ID must be CRD)
+Inactive An inactive member of the SRO (ID must be CRD)
+NonMember An entity that is not a member of the SRO. For example, if the routing broker dealer is not a member of the exchange, it would be listed here (ID must be CRD).
+Internal Some internal part of the SRO system (a utility or facility) which will be used in reportable events. In this case, the ID must have been a preregistered with CAT via the web GUI.
+Other Another entity (e.g., foreign firm) without a CRD number. In this case, the ID must have been pre-registered with CAT via the web GUI.
+strikePrice
+Reference Data: Simple Option Series Dictionary Entry
+In Simple Option Series Dictionary Entries, this field is the pre-arranged transaction price if the option is exercised. Note that if option kind = FLEXPCT, this will be the percentage.
+symbol
+Events: All Stock Exchange Events, All Options Stock Leg Events
+Reference Data: Symbol Entry, Complex Option Dictionary Entry
+The stock symbol. Note that for all events of stock exchange, or options stock leg related events, this field may be in either the symbology of the listing exchange, or the reporter's symbology mapping as appropriate. However, in Symbol Entry, or stock leg of Complex Option Dictionary entry, this must be in the symbology of the listing exchange.
+symbolAliases
+Reference Data: Symbol Dictionary Entry
+A list of symbol aliases for a listed symbol. Using an alias allows a reporter to submit events using the symbol in their own format rather than the symbology of the listed exchange.
+Symbol Entry Pairs
+This is a data type. Currently, this data type must be used for the field "attributes" found in the reference data element: Symbol Entry.
+Allowed values for this data type include the following:
+Allowed values for Symbol Entry:
+TPG Tick Pilot Group (Choice) - requires one of the defined values from the list below (e.g., TPG=TG2).
+CTRL Control Group
+TG1 Test Group 1
+TG2 Test Group 2
+TG3 Test Group 3
+test
+Reference Data: Symbol Entry
+Indicates whether the symbol is a "test" symbol used for testing production systems.
+timeInForce
+Events: Order Accepted, Order Route, Order Modified, Order Modify Route, Order Restatement, Simple Option Order Accepted, Complex Option Order Accepted, Complex Option Order Modified, Stock Leg Order, Option Order Modified, Option Route, Modify Option Route, Option Order Restatement
+Specifies the Time-In-Force for an order. Supported TIF values are listed below.
+Supported Values:
+AOK Auction or Kill
+CLO At the Close
+DAY A day order
+IOC Immediate or Cancel
+GTC Good till Canceled
+GTT Good till Time (requires XTIME in handlingInstructions)
+GTD Good till Date
+GTX Good till Crossing
+FOK Fill or Kill
+OPG At the Open
+REG Regular Hours Only
+WCO While Connected
+Additional Values Allowed (BATS):
+EXT Extended Day
+Additional Values Allowed (CHX):
+AOO Auction-only order
+GFS Good for Seconds
+Additional Values Allowed (IEX):
+SYS System Hours
+EXT Day + Extended Hours
+Additional Values Allowed (NASDAQ Equities):
+EXT Extended Days
+OPG On Open
+CLO On Close
+Additional Values Allowed (MIAX):
+AOC Auction or Cancel
+Additional Values Allowed (MIAX) Pearl:
+AOC Auction or Cancel
+tradeDate
+The date on which a trade occurred.
+tradeID
+Events: Order Trade, Trade Break, Trade Correction, Option Trade, Post Trade Allocation, Option Trade Break, Option Trade Correction
+An identifier for the trade, unique for the given exchange, date, and Symbol/OptionID.
+type
+Specifies the event type.
+General Events:
+NOTE Note
+SHD Self Help Declaration
+STE Supplemental Trade Event
+Stock Exchange Events:
+EOA Order Accepted
+EOR Order Route
+EIR
+Internal Order Route
+EOM Order Modified
+EOJ Order Adjusted
+EOC Order Canceled
+EOT Order Trade
+EOF Order Fill
+EBP Bulk Print
+ECR Order Cancel Route
+EMR Order Modify Route
+EORS Order Restatement
+ETB Trade Break
+ETC Trade Correction
+Options Exchange Events:
+OQ Quote
+OQC Quote Cancel
+OOA Simple Option Order Accepted
+OCOA Complex Option Order Accepted
+OSL Stock Leg Order
+OOM Option Order Modified
+OCOM Complex Option Order Modified
+OSLM Stock Leg Modified
+OOJ Option Order Adjusted
+OCOJ Complex Option Order Adjusted
+OSLJ Stock Leg Adjusted
+OOC Option Order Canceled
+OOR Option Route
+OIR Internal Option Route
+OCIR Internal Complex Option Route
+OOMR Modify Option Route
+OOCR Option Cancel Route
+OT Simple Option Trade
+OSLF Stock Leg Fill
+OPTA Post Trade Allocation
+OORS Option Order Restatement
+OTB Option Trade Break
+OTC Option Trade Correction
+undefinedNoteData
+Events: Note Event
+A list of key/value pairs, providing machine parseable data for the notation in a Note Event. The attributes are not defined in the specs, and can be any values as long as they conform to the format for a list of name/value pairs.
+underlyingType
+Reference Data: Option Series Dictionary Entry
+This field specifies whether a simple option series has an equity or index as its underlying. The underlying type mapping is consistent with the same mapping used at OCC (e.g., ETF is treated as Equity and WCO is treated as Index).
+Allowed Values:
+Equity
+Index
+version
+This is a data type, not a field. Digits and decimals are the only allowed characters. The first character must be a digit group followed by any number of optional pairs of decimals and digit groups.
+workingPrice
+Events: Order Accepted, Order Restatement, Simple Option Order Accepted, Option Order Modified, Option Order Restatement
+The working price of the order.
+| fn |
+ 1 Industry Members are required to maintain the accuracy to within 50 milliseconds of the time maintained by NIST. 100 microseconds requirement is for Participants only. + |
jurisdiction: US
regulatory_authority: US/SEC
content_type: periodic
- document_title: CAT NMS PLAN Clock Synchronization
- document_type: Assessment
- source: US/SEC/Assessment/Clock Synchronization Assessment
- source_type: Clock Synchronization Assessment
+ document_title: Joint Industry Plan (Notice of Plan Amendment No. 1 Release 34-74223)
+ document_type: Notices
+ source: US/SEC/Notices/Notice of Plan Amendment
+ source_type: Notice of Plan Amendment
language: English
- citation: N/A
- pubdate: May 15, 2017 effdate: N/A
- CAT NMS PLAN Clock Synchronization
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization
- Compliance User: Broker-dealers
+ citation: Notice of Plan Amendment No. 1 Release 34-74223
+ pubdate: February 06, 2015 effdate: N/A
+ Joint Industry Plan (Notice of Plan Amendment No. 1 Release 34-74223)
+Topic: SEC Release, Release No. 34-74223, Release No. 34-74223, Joint Industry Plan; Notice of Amendment
+ Compliance User: Self-Regulatory Organization
Keywords:
- File Number 4-698,
- Consolidated Audit trail,
+ Joint Industry Plan,
+ Selection Plan,
- May 15, 2017
-Brent J. Fields
-Secretary
-Securities and Exchange Commission
-100 F Street, NE
-Washington, DC 20549-1090
-Re: File Number 4-698
-National Market System Plan Governing the Consolidated Audit Trail Clock Synchronization Assessment
-Dear Mr. Fields:
-In accordance with Section 6.6(a)(ii) of the National Market System Plan Governing the Consolidated Audit Trail (the “CAT NMS Plan” or “Plan”),1 the Operating Committee2 for CAT NMS, LLC respectfully provides the Securities and Exchange Commission (“SEC” or “Commission”) with this assessment of the clock synchronization standard for the Consolidated Audit Trail (“CAT”), including consideration of industry standards based on the type of CAT Reporter, Industry Member and type of system, and recommendation for appropriate amendments based on this assessment.3 This Assessment is divided into four sections: (1) executive summary; (2) description of current clock synchronization requirements under the CAT NMS Plan; (3) description of the CAT Clock Synchronization Survey (the “Survey”), including responses to the Survey; and (4) an assessment of the current clock synchronization requirements based on the analysis of the data collected in the Survey, including whether the current requirements should be amended.
-pubdate: May 15, 2017 effdate: N/A
- I. Executive Summary
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, Executive Summary
- Compliance User: Broker-dealers
+ SECURITIES AND EXCHANGE COMMISSION
+(Release No. 34-74223; File No. 4-668)
+February 6, 2015
+Joint Industry Plan; Notice of Amendment to the National Market System Plan Governing the Process of Selecting a Plan Processor and Developing a Plan for the Consolidated Audit Trail by BATS Exchange, Inc., BATS-Y Exchange, Inc., BOX Options Exchange LLC, C2 Options Exchange, Incorporated, Chicago Board Options Exchange, Incorporated, Chicago Stock Exchange, Inc., EDGA Exchange, Inc., EDGX Exchange, Inc., Financial Industry Regulatory Authority, Inc., International Securities Exchange, LLC, ISE Gemini, LLC, Miami International Securities Exchange LLC, NASDAQ OMX BX, Inc., NASDAQ OMX PHLX LLC, The NASDAQ Stock Market LLC, National Stock Exchange, Inc., New York Stock Exchange LLC, and NYSE MKT LLC, NYSE Arca, Inc.
+pubdate: February 07, 2015 effdate: N/A
+ I. Introduction
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Introduction
+ Compliance User: Self-Regulatory Organization
Keywords:
- CAT NMS Plan - Section 6.6,
- Participants,
- CAT Reporting,
+ Securities Exchange Act of 1934,
+ SEC Rule 608,
+ National Market System Plan,
+ Developing a Plan for the Consolidated Audit Trail,
- As previously noted, Section 6.6(a)(ii) of the CAT NMS Plan requires that the Participants provide the SEC with an assessment of the clock synchronization standard, including consideration of industry standards based on the type of CAT Reporter, Industry Member and type of system, and a recommendation for appropriate amendments based on this assessment. To prepare this assessment, the Participants sought information regarding Industry Members’ clock synchronization practices through the Survey. This assessment provides a summary of the results of this Survey. Based on an analysis of the results of the Survey as well as information about Participant clock synchronization practices, the Participants do not believe that it is necessary or appropriate to amend the Business Clock synchronization requirements set forth in the Plan at this time. The Participants believe this assessment is consistent with the SEC’s finding that the current 50 milliseconds standard for Industry Members “is acceptable for the initial phase of CAT reporting.”4 The Participants will reassess whether the Business Clock synchronization requirements remain consistent with industry standards – or whether it may be necessary to amend such requirements – in the future as part of the annual assessment required by Section 6.8(c) of the Plan; however, the Participants note that the first annual assessment will occur before the initial phase of Industry Member CAT reporting.
+Pursuant to Section 11A of the Securities Exchange Act of 1934 (“Act”)1 and Rule 608 thereunder2, notice is hereby given that, on December 12, 2014, BATS Exchange, Inc., BATS-Y Exchange, Inc., BOX Options Exchange LLC, C2 Options Exchange, Incorporated, Chicago Board Options Exchange, Incorporated, Chicago Stock Exchange, Inc., EDGA Exchange, Inc., EDGX Exchange, Inc., Financial Industry Regulatory Authority, Inc., International Securities Exchange, LLC, ISE Gemini, LLC, Miami International Securities Exchange LLC, NASDAQ OMX BX, Inc., NASDAQ OMX PHLX LLC, The NASDAQ Stock Market LLC, National Stock Exchange, Inc., New York Stock Exchange LLC, NYSE MKT LLC, and NYSE Arca, Inc. (collectively, “SROs” or “Participants”), filed with the Securities and Exchange Commission (the “Commission”) a proposal to amend the Plan Governing the Process of Selecting a Plan Processor and Developing a Plan for the Consolidated Audit Trail (the “Selection Plan”).
pubdate: May 15, 2017 effdate: N/A
- II. Current Clock Synchronization Requirements
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, Current Clock Synchronization Requirements
- Compliance User: Broker-dealers
+ pubdate: February 08, 2015 effdate: N/A
+ II. Background
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Background
+ Compliance User: Self-Regulatory Organization
Keywords:
- CAT NMS Plan - Section 6.8,
- Participants,
- CAT Reporting,
- Business Clocks,
- Industry Member,
- SEC,
- Clock Synchronization,
+ Sec Rule 613,
+ CAT NMS plan,
+ SRO,
+ Selection Plan,
- Section 6.8 of the CAT NMS Plan sets forth the clock synchronization requirements related to the CAT for Participants and Industry Members. With regard to Participants, Section 6.8(a)(i) of the Plan requires each Participant to synchronize its Business Clocks at a minimum to within 100 microseconds of the time maintained by the National Institute of Standards and Technology (“NIST”), consistent with industry standards, except for Business Clocks used solely for Manual Order Events. Section 6.8(a)(iii) of the Plan requires each Participant to synchronize its Business Clocks used solely for Manual Order Events at a minimum to within one second of the time maintained by NIST, consistent with industry standards, and maintain such synchronization.
-With regard to Industry Members, Section 6.8(a)(ii) of the Plan requires each Participant to require its Industry Members to synchronize their Business Clocks at a minimum to within 50 milliseconds of the time maintained by NIST, except for Business Clocks used solely for Manual Order Events or the time of allocation on Allocation Reports, and maintain such a synchronization. Section 6.8(a)(iii) of the Plan requires each Participant to require its Industry Members to synchronize their Business Clocks used solely for Manual Order Events at a minimum to within one second of the time maintained by NIST, consistent with industry standards, and maintain such synchronization. Section 6.8(a)(iv) of the Plan requires each Participant to require its Industry Members to synchronize their Business Clocks used solely for the time of allocation on Allocation Reports at a minimum to within one second of the time maintained by NIST, consistent with industry standards, and maintain such synchronization. Each Participant has adopted rules requiring its Industry Members to comply with these clock synchronization requirements.5
-In approving the Plan, the SEC noted that the 50 milliseconds standard was reasonable for the initial implementation of the CAT.6 The SEC stated further that it “believes that a standard of 50 milliseconds for Industry Members will allow regulators to sequence orders and events with a level of accuracy that is acceptable for the initial phases of reporting.”7 Nevertheless, the SEC stated further that it:
-believes that it is appropriate for the Participants to consider the type of CAT Reporter (e.g., Participant, Industry Member), the type of Industry Member (e.g., ATS, small broker-dealer), and type of system (e.g., order handling, post-execution) when establishing appropriate industry standards. The Commission does not believe that one industry standard should apply across all CAT Reporters and systems.8
-Accordingly, the Commission amended Section 6.8(c) of the Plan to state that industry standards for purposes of clock synchronization should be determined based on the type of CAT Reporter, type of Industry Member and type of system. In recognition of the expectation that narrower clock synchronization thresholds may be appropriate for Industry Members, or certain categories or systems thereof, the Commission amended the Plan to require the Participants to provide this assessment of the clock synchronization standards set forth in the Plan.
+On July 11, 2012, the Commission adopted Rule 613 to require the SROs to jointly submit a national market system (“NMS”) plan to create, implement, and maintain a consolidated audit trail (“CAT NMS Plan”).3 To facilitate the development of the consolidated audit trail, following the adoption of Rule 613, the SROs created a working group consisting of representatives from each SRO. The SROs also decided to engage in a request for proposal (“RFP”) process to help them develop the CAT NMS Plan and to solicit bids (“Bids4”) for the role of Plan Processor to build, operate, administer, and maintain the consolidated audit trail.5 In addition, on September 3, 2013, the SROs filed, for approval, the Selection Plan to govern how the SROs would proceed with formulating and submitting the CAT NMS Plan—and, as part of that process, how the SROs would review, evaluate, and narrow down the Bids submitted in response to the RFP—and ultimately selecting the Plan Processor.6 The Selection Plan was approved on February 21, 2014.7
+The SROs propose to amend the Selection Plan in two ways. First, the SROs propose to provide opportunities to accept revised Bids prior to approval of the CAT NMS Plan, and second, to allow the list of Shortlisted Bids to be narrowed prior to Commission approval of the CAT NMS Plan. A copy of the proposed amendment to the Selection Plan is attached as Exhibit A hereto. The Commission is publishing this notice to solicit comments from interested persons on the proposed amendment to the Selection Plan.
pubdate: May 15, 2017 effdate: N/A
- III. CAT Clock Synchronization Survey
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey
- Compliance User: Broker-dealers
+ pubdate: February 09, 2015 effdate: N/A
+ III. Description of the Plan
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan
+ Compliance User: Self-Regulatory Organization
Keywords:
- Participant,
- Business Clock Syncronization Practice,
- CAT NMS plan,
+ Selection Plan,
+ Rule 608,
+ SRO,
- The Participants determined that the use of a survey was an appropriate method for gaining additional data on Industry Members’ Business Clock synchronization practices to inform this assessment. On April 11, 2017, the Participants released the Survey, which was made available to the public on the CAT NMS Plan’s public website.9 Responses were collected through April 23, 2017. The Participants drafted the Survey in consultation with the Advisory Committee to help ensure that the Survey was designed to seek detailed and meaningful data regarding Business Clock synchronization practices and trends, and industry views regarding potential modifications to the Business Clock synchronization standards set forth in the Plan. When the Survey was posted, the Participants notified their respective members and the Advisory Committee and industry trade associations,10 to encourage a significant and diverse sample size.
-pubdate: May 15, 2017 effdate: N/A
- A. Overview of CAT Clock Synchronization Survey
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Overview of CAT Clock Synchronization Survey
- Compliance User: Broker-dealers
+ Set forth in this Section II is the statement of the purpose of the Selection Plan, along with the information required by Rule 608(a)(4) and (5) under the Exchange Act,8 prepared and submitted by the SROs to the Commission.9
+pubdate: February 10, 2015 effdate: N/A
+ A. Background
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan, Background
+ Compliance User: Self-Regulatory Organization
Keywords:
- Syncronization Survey,
- Business Clock,
+ Selection Plan,
+ CAT NMS plan,
+ Sec Rule 613,
- The Survey was divided into five main sections: (1) demographic questions; (2) general questions; (3) current clock synchronization practices; (4) changes to Business Clock synchronization practices; and (5) costs. Each of these sections is discussed in greater detail below.
-pubdate: May 15, 2017 effdate: N/A
- 1. Demographic Questions
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Overview of CAT Clock Synchronization Survey, Demographic Questions
- Compliance User: Broker-dealers
+ The Selection Plan governs the process for Participant review of Bids for the role of Plan Processor for the CAT NMS Plan, the procedures for evaluating the Bids, and ultimately, until approval of the CAT NMS Plan, the selection of the Plan Processor. The CAT NMS Plan was filed with the Commission for approval on September 30, 2014.
+After gaining experience with the development process for the CAT NMS Plan, the Participants believe it is necessary to amend the Selection Plan to ensure that the Participants will be able to choose a Plan Processor within the timeframe provided in the Selection Plan and Rule 613. The Participants propose amending the Selection Plan to (1) provide for additional opportunities to accept revised Bids and (2) allow the set of Shortlisted Bids to be narrowed prior to Commission approval of the CAT NMS Plan.
+pubdate: February 11, 2015 effdate: N/A
+ 1. The Selection Plan Currently Allows Bid Revisions Only Following CAT NMS Plan Approval, and Does Not Allow for Narrowing of the Set of Shortlisted Bids
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan, Background, The Selection Plan Currently Allows Bid Revisions Only Following CAT NMS Plan Approval, and Does Not Allow for Narrowing of the Set of Shortlisted Bids
+ Compliance User: Self-Regulatory Organization
Keywords:
+ Selection Plan,
+ Shortlisted Bidders,
CAT NMS plan,
- Vendors,
- CAT Reporters,
- Broker-dealer,
- Sec Rule 613,
- Industry Members,
- FINRA,
- OATS,
+ Plan Processor,
+ Selection Plan Section VI(B),
- The first section of the Survey asked that respondents provide their firm name and contact information. The section also asked that respondents, if applicable, identify themselves as a third-party vendor, technology services provider or other entity that is not subject to the CAT NMS Plan, but that provides services to CAT Reporters and maintains synchronized Business Clocks, and to explain their business and systems that contain Business Clocks. To the extent that a respondent was a small broker-dealer, as defined in Rule 613,11 they were asked to identify themselves as such.
-To help the Participants collect information from Industry Members that currently report to the Financial Industry Regulatory Authority’s (“FINRA”) Order Audit Trail System (“OATS”), the Survey asked respondents to identify whether they currently report to OATS and, if so, to identify approximately how many reportable order events they report each month. For firms that are not subject to OATS, the Survey asked that respondents provide a brief explanation of why they are excluded or exempt from OATS, as applicable. Respondents also were asked to provide estimates of the approximate number of orders for NMS Stocks and OTC Equity Securities, and listed options, that they handled in the past month (including orders given to, received by, or originated by, the respondent). Finally, respondents were asked to provide information concerning their business activities, including identifying the types of business activities in which they participate, identifying whether they are a market maker, identifying whether they are an alternative trading system (“ATS”), and identifying the instruments that they trade.
+Under the Selection Plan, Shortlisted Bidders are only eligible to revise Bids following Commission approval of the CAT NMS Plan. The Selection Plan specifies that, following approval of the CAT NMS Plan by the SEC, Shortlisted Bidders for the role of Plan Processor may be permitted to revise their Bids based on the provisions in the approved CAT NMS Plan, including further discussions if determined to be necessary by the Selection Committee described in the Selection Plan.10 The Selection Plan provides that a Shortlisted Bidder will be permitted to revise its Bid only upon approval by a majority of the Selection Committee, subject to certain recusal provisions in the Selection Plan, that revisions are necessary or appropriate in the light of the content of the Shortlisted Bidder’s initial Bid and the provisions in the approved CAT NMS Plan.11
+The Selection Plan also requires that selection of the Plan Processor occur from among the initial set of Shortlisted Bids.12 Under the current Selection Plan, the Participants are not permitted to narrow the list of Shortlisted Bids determined pursuant to Section VI(B) of the Selection Plan.
pubdate: May 15, 2017 effdate: N/A
- 2. General Questions
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Overview of CAT Clock Synchronization Survey, General Questions
- Compliance User: Broker-dealers
+ pubdate: February 12, 2015 effdate: N/A
+ 2. Allowing Revision(s) of Bids In Light of Additional Information Available to Shortlisted Bidders and Providing for Narrowing the Set of Shortlisted Bidders Will Allow the Participants to Select the Plan Processor More Effectively and Efficiently Within the Rule 613 Timeframe
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan, Background, The Selection Plan Currently Allows Bid Revisions Only Following CAT NMS Plan Approval, and Does Not Allow for Narrowing of the Set of Shortlisted Bids
+ Compliance User: Self-Regulatory Organization
Keywords:
- CAT Reporter,
- Business Clock Synchronization Requirements,
- Survey questions,
-
- The next section of the Survey included general questions requesting views on whether the Business Clock synchronization requirements set forth in the Plan should vary depending on the type of CAT Reporter, the type of Industry Member and/or the type of system. To the extent that a respondent believed that the requirements should vary, the Survey asked that they explain how and why. Next, the Survey asked if respondents believed that firms voluntarily seek to improve Business Clock synchronization requirements, or if they believed that firms typically avoid changing such standards or practices absent a regulatory requirement to do so. Finally, this section asked that the respondents describe the factors that primarily affect costs related to complying with the Business Clock synchronization requirements and whether such factors vary by system or Industry Member.
-pubdate: May 15, 2017 effdate: N/A
- 3. Current Clock Synchronization Practices
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Overview of CAT Clock Synchronization Survey, Current Clock Synchronization Practices
- Compliance User: Broker-dealers
- Keywords:
- Survey questions,
- Survey Information,
- Business Clock synchronization,
-
- The next section asked that respondents provide information regarding their current Business Clock synchronization practices. To the extent that respondents currently maintain synchronized Business Clocks, they were asked to identify the types of systems in which such Business Clocks are maintained.12 To collect information on Business Clocks used in different systems, respondents also were asked to provide responses to various questions regarding the systems that they operate that contain Business Clocks. Respondents were asked whether they maintain different synchronization tolerances for Business Clocks used for different systems and, if so, for what types of systems the respondents maintain different tolerances and the tolerance of each respective system. The Survey requested information regarding the technologies that respondents use to maintain Business Clock synchronization, such as: PTP; NTP; PPS; GPS; CDMA; or other. Respondents also had the option of indicating that they “do not know” the technologies that they currently use to maintain Business Clock synchronization.
-Respondents were then asked to provide information regarding their current Business Clock drift tolerances by choosing from the following responses: more than 1 second; 500 milliseconds to 1 second; 50 milliseconds to 499 milliseconds; 1 millisecond to 49 milliseconds; 500 microseconds to 999 microseconds; 1 microsecond to 499 microseconds; and “do not know.” Respondents also were asked if tolerances vary by where a Business Clock is located (e.g., internal broker-dealer data center; third-party data center; exchange co-location). Next, respondents were asked to identify how often they check Business Clock synchronization by choosing from the following responses: once a day; more than once a day, but less than once an hour; once an hour or more, but less than once a minute; once a minute or more, but less than once a second; once a second or more, but less than once a hundredth of a second; more than once a hundredth of a second; or “do not know.” Next, respondents were asked to identify what source they currently use as a “master” clock by identifying: GPS; CDMA; NIST atomic clock; data center-provided time; other vendor or hardware provided time; or “do not know.” To the extent that respondents maintain Business Clock synchronization across geographically disparate systems, they were asked to identify this fact and explain any challenges encountered and costs incurred to maintain such synchronization.
-pubdate: May 15, 2017 effdate: N/A
- 4. Changes to Business Clock Synchronization Practices
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Overview of CAT Clock Synchronization Survey, Current Clock Synchronization Practices, Changes to Business Clock Synchronization Practices
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- Business Clock Practices,
-
- Respondents were asked to provide information on how often they assess Business Clock synchronization tolerance and whether this practice varies by the type of Business Clock or system being considered. To collect information regarding changes to synchronization practices, respondents also were asked how often they assess their Business Clock synchronization tolerances and how often they have changed tolerances in the past year. Next, respondents were asked, to the best of their knowledge, how often their Business Clock tolerances are exceeded.
-pubdate: May 15, 2017 effdate: N/A
- 5. Costs
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Overview of CAT Clock Synchronization Survey, Costs
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- Projected Cost,
+ Shortlisted Bidders,
+ CAT NMS plan,
+ Plan Processor,
+ Sec Rule 613,
+ Selection Plan Section VI(D),
- The final section of the Survey sought information regarding the costs to the industry of Business Clock synchronization. This section asked respondents to provide information regarding the initial costs that they incurred (or that they anticipate that they will incur) to comply with the Business Clock synchronization tolerance of 50 milliseconds or 1 second, as applicable. Respondents also were asked to explain any ongoing costs that they will incur to maintain applicable synchronization tolerance and to explain how this response varies by type of Business Clock or system. Respondents also were asked how long it took them (or how long they anticipate that it will take them) to comply with the Business Clock synchronization requirements, and to explain how this response varies by the type of Business Clock or system.
-The next set of questions sought information on the projected costs of further reducing the Business Clock synchronization tolerance. Respondents were asked to describe the costs (initial and ongoing), if any, that they expect to incur if the Business Clock synchronization tolerance is reduced and how these costs vary by type of Business Clock or system. Respondents also were asked how long they anticipate that it will take them to comply with any new Business Clock synchronization tolerances.
+The Participants believe that providing the Shortlisted Bidders with an additional opportunity or opportunities to revise their Bids prior to the approval of the CAT NMS Plan is critical to the timely and considered selection of the Plan Processor. Since the Bidders submitted their Bids, the Participants have expended substantial effort in analyzing potential solutions for the consolidated audit trail (“CAT”) by gathering and evaluating data and information from a variety of market participants, including Bidders, broker-dealers, vendors, regulators and others. As a result, since the original Bid date, the Participants have made substantial strides in identifying characteristics of an optimal solution and formalizing these determinations in the proposed CAT NMS Plan and related technical documents. Given the development of the requirements for an optimal solution for the CAT, the Participants believe that waiting until after the approval of the CAT NMS Plan to permit the Shortlisted Bidders to revise their Bids will shortchange the Bid process to the detriment of the final plan. Moreover, given the passage of time since the original Bids, Bidders have indicated that new technological and other beneficial solutions are now available that may further improve the Bids, and, ultimately, the proposed solutions.
+In addition, the Participants believe that delaying the Bid revision process until after the approval of the CAT NMS Plan will prevent Bidders from submitting, and the Participants from adequately reviewing the most relevant, informative and fulsome Bids before selecting a Plan Processor. Specifically, Rule 613(a)(2)(i) requires the Participants to select the Plan Processor within two months after effectiveness of the CAT NMS Plan. The Participants anticipate permitting the Shortlisted Bidders to revise their Bids, pursuant to Section VI(D) of the Selection Plan, after approval of the CAT NMS Plan, if there are substantial changes to the CAT NMS Plan before the CAT NMS Plan is approved by the Commission. Therefore, the Participants will have only a short time period of two months to analyze the Shortlisted Bids – Bids that are likely to have substantial revisions after the approval of the CAT NMS Plan for the reasons discussed above. Given the very large amount of information to digest in the revised Bids and the importance of appropriately analyzing such information, the Participants do not believe that two months will be sufficient to select the Plan Processor given the limitations of the current Selection Plan. However, if the Shortlisted Bidders are able to revise their Bids to reflect the provisions of the proposed CAT NMS Plan and any draft technical materials, as well as any new technology or other relevant developments, prior to the approval of the CAT NMS Plan, then the Participants believe that they will be able to select the Plan Processor within the time limits imposed by Rule 613 in a more thoughtful and deliberative manner.
+In addition, the Participants believe that providing the Selection Committee the discretion to further reduce the number of Shortlisted Bids, either before or after any revisions to Shortlisted Bids are accepted, would also facilitate the selection of the Plan Processor within the time limits imposed by Rule 613. Allowing the Selection Committee to reduce the number of Shortlisted Bids before approval of the CAT NMS Plan could allow the Participants to more efficiently select the Plan Processor by focusing attention on a more refined set of options during the limited two month time period for selection following approval of the CAT NMS Plan.
pubdate: May 15, 2017 effdate: N/A
- B. Assessment of Participants’ Business Clock Synchronization Standards
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Assessment of Participants’ Business Clock Synchronization Standards
- Compliance User: Broker-dealers
- Keywords:
- Business Clocks,
- Participant,
- Industry Member,
-
- Although the Participants did not participate in the Survey, which was designed for Industry Members and other firms in the securities industry, the Participants previously assessed their operations and use of Business Clocks to determine an appropriate synchronization threshold to apply to themselves. These assessments occurred in 2015 and 2016.13 Ultimately, the Participants determined that, collectively, they operate pursuant to a Business Clock synchronization of 100 microseconds or less with respect to their electronic systems. The Participants that are exchanges each measured average absolute matching engine clock drift across five business days. The average measured clock drift based on this analysis was approximately 36 microseconds. However, this result was an average and the Participants do not believe that it may be relied upon as a definitive statement that all Participants currently meet a threshold of 36 microseconds. In particular, Participants’ practices vary with respect to the implementation, use and measurement of synchronization. Moreover, Participants’ practices also vary with respect to the frequency with which they check the accuracy of synchronization, so it may be difficult to directly compare the synchronization of one Participant to another. Participants that operate non-electronic systems, such as manual systems operated on trading floors, manual order entry devices and certain other systems, found that they do not operate at a synchronization of 100 microseconds or less. Based on these findings, the Participants proposed, and the Commission adopted, that they be subject to a Business Clock synchronization standard of 100 microseconds of the time maintained by NIST, other than Business Clocks used solely for Manual Order Events (which must comply with a standard of 1 second of the time maintained by NIST). The Participants do not believe that their practices have changed materially since the Plan was adopted.
-pubdate: May 15, 2017 effdate: N/A
- C. Analysis of Data from Clock Synchronization Survey14
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14
- Compliance User: Broker-dealers
+ pubdate: February 13, 2015 effdate: N/A
+ B. Requirements Pursuant to Rule 608(a)
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan, Requirements Pursuant to Rule 608(a)
+ Compliance User: Self-Regulatory Organization
Keywords:
- broker-dealers,
- Business Clock Synchronization Practices,
+ Rule 608,
- pubdate: May 15, 2017 effdate: N/A
- 1. Overview of Respondents and Demographics
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Overview of Respondents and Demographics
- Compliance User: Broker-dealers
+ pubdate: February 14, 2015 effdate: N/A
+ 1. Description of the Amendments to the Selection Plan
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan, Description of the Amendments to the Selection Plan
+ Compliance User: Self-Regulatory Organization
Keywords:
- Participant,
- Survey,
- CAT Reporters,
- OATS,
+ Selection Plan,
CAT NMS plan,
- FINRA,
+ Selection Plan Section VI(D),
+ Shortlisted Bids,
- The Participants received 143 substantially complete responses to the Survey.15 The responses represent the views of a range of firms. Based on the responses, approximately 13% of respondents identified as small broker-dealers that expect to report to the CAT, approximately 60% of respondents identified as large broker-dealers that expect to be CAT reporters, and approximately 27% of respondents indicated that they do not expect to report to the CAT. Of the 143 responses, approximately 23% of respondents indicated that they are an equities market maker and approximately 13% of respondents indicated that they are an options market maker. Approximately 78% of respondents indicated that they currently report to OATS, and approximately 22% indicated that they currently do not report to OATS.16
-With respect to types of business activities, respondents indicated the following: approximately 20% operate an institutional business; approximately 17% operate a retail business; approximately 17% are introducing brokers; approximately 12% engage in proprietary trading; approximately 8% engage in clearing activities; approximately 7% engage in asset management activities; approximately 8% engage in investment banking; approximately 5% provide prime brokerage services; and approximately 6% indicated that they engage in other activities. Approximately 8% of respondents stated that they operate an ATS. Approximately 18% of respondents indicated that they are a third-party vendor, technology services provider or other entity that is not subject to the CAT NMS Plan, but that provides services to CAT Reporters and maintains synchronized Business Clocks (a “Service Provider”). The approximately 18% of respondents that identified as Service Providers indicated that they provide the following functions: back-office processing (approximately 3%); books and records (approximately 4%); clearing (approximately 1%); settlement (approximately 1%); trade order management systems (approximately 5%); trade reporting (approximately 3%); and other17 (approximately 2%).
-The approximately 78% of respondents that indicated that they currently report to OATS provided the following information regarding the approximate number of reportable events that they submit to OATS each month: 0 to 9,999 (approximately 30%); 10,000 to 99,999 (approximately 9%); 100,000 to 2,999,999 (approximately 15%); 3,000,000 to 99,999,999 (approximately 12%); and 100,000,000 or more (approximately 12%). As previously noted, approximately 12% of respondents reported that they are not FINRA members and approximately 10% of respondents indicated that they are excluded or exempt from OATS reporting.
+The Participants propose amending the Selection Plan to permit the Shortlisted Bidders to revise their Bids one or more times prior to approval of the CAT NMS Plan if the Selection Committee determines, by majority vote, subject to the applicable recusal provisions, that such revisions are necessary and appropriate. The proposed amendment would not affect Section VI(D) of the Selection Plan, which allows for revisions to Shortlisted Bids following Commission approval of the CAT NMS Plan.
+The Participants also propose amending the Selection Plan to provide the Selection Committee discretion to narrow the set of Shortlisted Bids prior to approval of the CAT NMS Plan. Specifically, the proposed amendment would authorize another round of voting to narrow the set of Shortlisted Bids. This round of voting, which could occur either before or after any revisions to Shortlisted Bids are accepted, would be commenced upon at least a two-thirds vote of the Selection Committee, and would proceed in a manner similar to the initial round for voting for the Shortlisted Bids. Each Voting Senior Officer would choose a first, second, and third choice Shortlisted Bid, with each choice receiving a weight of, respectively, three points, two points, and one point. The three bids receiving the highest cumulative number of points would constitute the new set of Shortlisted Bids. In the event of a tie that would result in more than three final Shortlisted Bids, the votes would be recounted, excluding each Voting Senior Officer’s third choice. The three Shortlisted Bids receiving the largest number of cumulative votes in this recount would be the new Shortlisted Bids. If this recount were to result in a tie leading to a larger or equal number of final Shortlisted Bids than the initial count, the results of the initial count would constitute the new set of Shortlisted Bids. The proposed amendment also includes, for the sake of clarity, a provision ensuring that at least one Non-SRO Bid is included in the narrowed set of Shortlisted Bids. The individual scores and rankings under any vote to narrow the list of Shortlisted Bids shall be kept confidential.
+Finally, the proposed amendment includes provisions with respect to the recusal of Participants that also are Shortlisted Bidders. Under this proposed provision, no Bidding Participant shall vote in the process narrowing the set of Shortlisted Bidders, if a Bid submitted by or including the Participant or an Affiliate of the Participant is a Shortlisted Bid.
+pubdate: February 15, 2015 effdate: N/A
+ 2. Governing or Constituent Documents
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan, Requirements Pursuant to Rule 608(a), Governing or Constituent Documents
+ Compliance User: Self-Regulatory Organization
+ Keywords:
+ Not applicable.
pubdate: May 15, 2017 effdate: N/A
- 2. Responses to General Questions
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Responses to General Questions
- Compliance User: Broker-dealers
+ pubdate: February 16, 2015 effdate: N/A
+ 3. Implementation of Amendment
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan, Requirements Pursuant to Rule 608(a), Implementation of Amendment
+ Compliance User: Self-Regulatory Organization
Keywords:
- Business Clock synchronization,
+ Amendment approval,
- As discussed in greater detail in this section, generally, over half of respondents did not have a view on whether there should be different Business Clock synchronization requirements applicable to different types of businesses or systems. Focusing on the respondents that did have a view, approximately 64% did not believe that there should be different requirements for different types of businesses or systems, versus approximately 36% that believed that there should be different requirements for different types of businesses or systems. However, a majority of respondents that identified as small broker-dealers believed that there should be different Business Clock synchronization standards that apply to both (1) large broker-dealers vs. small broker-dealers (approximately 83% of small broker-dealer respondents), and (2) different types of systems (100% of small broker-dealer respondents). Large broker-dealers and small broker-dealers split on the question of whether firms voluntarily seek to improve their Business Clock synchronization standards or practices, or if firms only change such standards or practices when required to do so by regulation. Large broker-dealer respondents believed that they voluntarily seek to improve such standards or practices, while most small broker-dealer respondents indicated that they change such standards or practices when required to do so. Finally, there is no majority view with respect to how often respondents exceed applicable Business Clock synchronization thresholds, but most firms indicated that they did not know the answer to this question. These findings are discussed in greater detail below.
-pubdate: May 15, 2017 effdate: N/A
- a. Execution Venues vs. Broker-Dealers
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Responses to General Questions, Execution Venues vs. Broker-Dealers
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- Execution Venues,
- broker-dealers,
-
- Approximately 50% of the respondents indicated that they did not have a view on whether there should be different Business Clock synchronization requirements applicable to Execution Venues and broker-dealers. Out of those respondents that did express a view, approximately 66% stated that they did not believe that there should be different Business Clock synchronization requirements applicable to Execution Venues and broker-dealers and approximately 34% stated that they believe that Execution Venues and broker-dealers should be subject to different requirements. Notably, of the respondents that indicated that they operate an ATS, approximately 50% did not believe that different requirements should apply to Execution Venues. Approximately 33% of respondents operating ATSs believed that there should be different requirements that apply to Execution Venues, and approximately 17% of respondents that operate ATSs did not have a view.18
-pubdate: May 15, 2017 effdate: N/A
- b. Small Broker-Dealers vs. Large Broker-Dealers
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Responses to General Questions, Small Broker-Dealers vs. Large Broker-Dealers
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- broker-dealers,
-
- A majority of respondents (approximately 52%) indicated that they did not have a view on whether there should be different Business Clock synchronization requirements for CAT Reporters that are small broker-dealers and large broker-dealers. Focusing on those respondents who did express a view, the majority (approximately 68%) did not believe that there should be different requirements applicable to small broker-dealers and large broker-dealers, and approximately 32% of respondents believed that small broker-dealers and large broker-dealers should be subject to different standards. Notably, the respondents that provided a response to this question mostly identified as large broker-dealers (approximately 60%), while approximately 12% identified as small broker-dealers and approximately 28% identified as non-CAT Reporters.
-pubdate: May 15, 2017 effdate: N/A
- c. Varying Standards by Type of System
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Responses to General Questions, Varying Standards by Type of System
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- broker-dealers,
-
- A majority of the respondents (approximately 54%) indicated that they did not have a view on whether there should be different Business Clock synchronization requirements for different types of systems. Focusing on the respondents that did express a view, approximately 60% do not believe that there should be different Business Clock synchronization requirements applicable to different types of systems versus approximately 40% of respondents that believed that different requirements should apply to different types of systems. All small broker-dealer respondents that responded to this question, as well as approximately 60% of respondents that operate a retail business and responded to this question, support there being different Business Clock synchronization requirements applicable to different types of systems.
-pubdate: May 15, 2017 effdate: N/A
- d. Improvements to Business Clock Synchronization Practices
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Responses to General Questions, Improvements to Business Clock Synchronization Practices
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- broker-dealers,
-
- Respondents split on whether firms voluntarily seek to improve their Business Clock synchronization standards or practices, or avoid changing such standards or practices absent a regulatory requirement to do so. Of the respondents that expressed a view, approximately 27% indicated that firms voluntarily19 seek to improve their Business Clock synchronization standards or practices, approximately 23% indicated that firms did not change their standards or practices absent a regulatory requirement to do so,20 and approximately 18% indicated that other factors cause them to update their Business Clock synchronization standards or practices.21 Approximately 31% of respondents indicated that they did not have a view on whether firms voluntarily seek to improve their Business Clock synchronization standards or practices, or avoid changing such standards or practices absent a regulatory requirement to do so.
-Of the respondents that identified as large broker-dealers, the largest number of responses (approximately 42%) indicated that respondents voluntarily seek to improve their Business Clock synchronization standards or practices. The opposite was true of small broker-dealer respondents, as the majority of such respondents (approximately 75%) indicated that they change their Business Clock synchronization standards or practices when a regulatory obligation requires them to do so.
-pubdate: May 15, 2017 effdate: N/A
- e. Exceeding Required Synchronization Tolerances
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Responses to General Questions, Exceeding Required Synchronization Tolerances
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- broker-dealers,
- Business Clock Tolerance,
-
- Approximately 46% of respondents that expressed a view indicated that they did not know, on average, how often their Business Clock synchronization tolerances are exceeded. Approximately 3% of respondents stated that their response depends on the type of Business Clock or system being considered. Other respondents indicated that their Business Clock tolerances are exceeded: multiple times per day (approximately 5%); monthly (approximately 15%); semiannually (approximately 16%); and less than annually (approximately 15%).
-Respondents that identified as large broker-dealers reported that, on average, their Business Clock synchronization tolerances are exceeded: multiple times per day (approximately 8%); monthly (approximately 14%); semiannually (approximately 13%); and less than annually (approximately 27%). Approximately 3% of large broker-dealer respondents indicated that their response depends on the type of Business Clock or system considered and approximately 35% of large broker-dealer respondents did not know how often their synchronization tolerances are exceeded. Small broker-dealer respondents indicated that, on average, their synchronization tolerances are exceeded: monthly (approximately 27%); semiannually (approximately 33%); and less than annually (approximately 7%). No small broker-dealer respondents reported exceeding thresholds multiple times per day or at different times depending on the type of Business Clock or system being considered. Approximately 33% of small broker-dealer respondents did not know how often their synchronization tolerances are exceeded.
-The terms of the proposed amendments will be operative immediately upon approval of the amendments by the Commission.
+pubdate: February 17, 2015 effdate: N/A
+ 4. Development and Implementation Phases
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan, Requirements Pursuant to Rule 608(a), Development and Implementation Phases
+ Compliance User: Self-Regulatory Organization
+ Keywords:
+ Not applicable.
pubdate: May 15, 2017 effdate: N/A
- 3. Costs
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Costs
- Compliance User: Broker-dealers
+ pubdate: February 18, 2015 effdate: N/A
+ 5. Analysis of Impact on Competition
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan, Requirements Pursuant to Rule 608(a), Analysis of Impact on Competition
+ Compliance User: Self-Regulatory Organization
Keywords:
- Business Clock synchronization,
- Costs Requirements,
+ Exchange Act,
+ SRO,
+ CAT NMS plan,
+ Sec Rule 613,
- Respondents generally identified software and/or hardware as the primary factors affecting costs for complying with the Business Clock synchronization requirements, with maintenance and compliance as the second and third greatest factors. The majority of respondents who expressed a view believed that such cost drivers vary by type of system. This view was generally consistent regardless of the type or size of respondents, except that small broker-dealer respondents were evenly split (i.e., 50% believed that cost drivers varied by system and 50% believed that cost drivers did not vary by system). Focusing on respondents who knew their initial costs of compliance (i.e., those that did not respond “do not know”), the majority (approximately 70%) stated that their initial costs of complying with the Business Clock synchronization requirements were less than $100,000. All small broker-dealer respondents who knew their initial compliance costs reported that such costs were below $100,000. Conversely, approximately 30% large broker-dealer respondents who knew their initial compliance costs indicated that such costs were over $100,000. Respondents provided a broad range of responses regarding the time it took to comply with the Business Clock synchronization requirements—responses ranged from less than one month to more than six months. These findings are discussed in greater detail below.
-pubdate: May 15, 2017 effdate: N/A
- a. Factors Affecting Compliance Costs
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Costs, Factors Affecting Compliance Costs
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- Compliance Costs,
-
- Approximately 35% of respondents who expressed a view indicated that software and hardware primarily affect costs related to complying with the Business Clock synchronization requirements. Maintenance and compliance were the second and third largest cost drivers, with approximately 21% and 20% of respondents indicating that these reflected their greatest costs, respectively. When asked whether factors affecting costs of complying with the Business Clock synchronization requirements vary by system, approximately 46% of respondents stated that they did not have a view, 36% of respondents indicated that they thought that such factors did vary by type of system, and approximately 18% of respondents indicated that they thought that such factors did not vary by system.
-pubdate: May 15, 2017 effdate: N/A
- b. Initial Compliance Costs
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Costs, Initial Compliance Costs
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- Compliance Costs,
- Business Clock Synchronization Threshold,
- Large Broker-Dealers,
- Service Providers,
- OATS Reporters,
-
- With respect to the costs incurred by respondents to comply with the initial Business Clock synchronization thresholds set forth in the Plan, approximately 35% of respondents did not know their initial compliance costs. Approximately 44% of respondents indicated that their initial compliance costs were less than $100,000, approximately 9% indicated that their initial compliance costs were between $100,000 and $500,000, and approximately 6% indicated that their initial compliance costs were more than $500,000. Approximately 5% of respondents indicated that they incurred other costs22 and approximately 1% indicated that costs depended on the type of Business Clock or system. Notably, no respondents that identified as small broker-dealers indicated that they incurred initial costs more than $100,000.
-Respondents that identified as large broker-dealers indicated that they incurred the following initial compliance costs: no costs (approximately 5%); less than $100,000 (approximately 45%); $100,000 to $500,000 (approximately 12%); and more than $500,000 (approximately 9%). Approximately 29% of large broker-dealer respondents did not know what costs they incurred. Approximately 53% of respondents that identified as small broker-dealers indicated that they incurred initial compliance costs of less than $100,000. Approximately 6% of small broker-dealer respondents reported that their costs varied depending on the specific Business Clock or system, approximately 6% indicated that they incurred other costs beyond what was listed in the Survey, and approximately 35% did not know what initial compliance costs they incurred.
-Respondents that identified themselves as Service Providers, OATS reporters and ATSs indicated that they incurred a range of different costs to comply with the initial Business Clock synchronization requirements. Respondents that identified as Service Providers indicated the following initial compliance costs: less than $100,000 (approximately 36%); $100,000 to $500,000 (approximately 9%); and more than $500,000 (approximately 9%). Approximately 45% of Service Providers did not know their initial compliance costs. Respondents that identified as OATS reporters indicated the following initial compliance costs: less than $100,000 (approximately 50%); $100,000 to $500,000 (approximately 10%); more than $500,000 (approximately 8%). Approximately 32% of respondents that identified as OATS reporters did not know what initial implementation costs they incurred (or would incur) to comply with the initial thresholds. Finally, respondents that indicated that they operate an ATS provided the following responses regarding initial implementation costs that they incurred (or would incur) to comply with the initial thresholds: less than $100,000 (approximately 25%); $100,000 to $500,000 (approximately 17%); and more than $500,000 (approximately 33%). Approximately 25% of respondents operating ATSs did not know their initial implementation costs.
-pubdate: May 15, 2017 effdate: N/A
- c. Time to Comply with Initial Thresholds
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Costs, Time to Comply with Initial Thresholds
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- Time Estimate,
- Large Broker-Dealers,
-
- Respondents that provided a time estimate indicated that it took (or would take) them the following amount of time to comply with the initial Business Clock synchronization thresholds set forth in the Plan: less than 1 month (approximately 30%); 1 to 2 months (approximately 5%); 2 to 6 months (approximately 12%); and more than 6 months (approximately 9%). Approximately 11% of respondents indicated it would take them some “other” amount of time,23 and approximately 33% of respondents reported that they did not know how long it took (or would take) them to comply with the initial synchronization thresholds.
-Respondents that identified as large broker-dealers indicated that it took (or would take) them the following amount of time to comply with the initial thresholds: less than 1 month (approximately 34%); 1 to 2 months (approximately 6%); 2 to 6 months (approximately 18%); and more than 6 months (approximately 12%).24 Approximately 18% of large broker-dealer respondents could not provide a time estimate and approximately 11% stated it would take them some other amount of time. Respondents identifying as small broker-dealers provided the following time estimates: less than 1 month (approximately 29%); and 2 to 6 months (approximately 6%). Approximately 6% of small broker-dealer respondents indicated that it would take them some other amount of time. Most small broker-dealer respondents (approximately 59%) could not provide a time estimate.
-The proposed amendments do not impose any burden on competition that is not necessary or appropriate in furtherance of the purposes of the Exchange Act. The SROs believe that the amendments are reasonably designed to help assure that the SROs receive more updated and informed submissions from Shortlisted Bidders before the CAT NMS Plan is finalized, thereby helping to assure that the selection of the Plan Processor for the CAT NMS Plan proceeds efficiently within the timeframe provided by Rule 613. Moreover, the SROs believe that the amended process will facilitate the development of an audit trail that maximizes its regulatory utility while minimizing unnecessary costs, to the benefit of all market participants. Furthermore, providing the ability to narrow the list of Bidders at an earlier stage will prevent Bidders whose Bids are unlikely to be selected from misallocating their resources toward the further development of their Bid.
pubdate: May 15, 2017 effdate: N/A
- 4. Changes to Business Clock Synchronization Threshold
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold
- Compliance User: Broker-dealers
+ pubdate: February 19, 2015 effdate: N/A
+ 6. Written Understanding or Agreements Relating to Interpretation of, or Participation in, Plan.
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan, Requirements Pursuant to Rule 608(a), Written Understanding or Agreements Relating to Interpretation of, or Participation in, Plan
+ Compliance User: Self-Regulatory Organization
+ Keywords:
+ Not applicable.
+pubdate: February 20, 2015 effdate: N/A
+ 7. Statement that the Amendments Have Been Approved by the Plan Sponsors
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan, Requirements Pursuant to Rule 608(a), Statement that the Amendments Have Been Approved by the Plan Sponsors
+ Compliance User: Self-Regulatory Organization
Keywords:
- Business Clock Synchronization Threshold,
+ Selection Plan,
+ Rule 608,
- Respondents generally indicated that implementation time, initial costs and ongoing costs, all increased as the Business Clock synchronization threshold became narrower. Responses also indicated that the implementation time, initial costs and ongoing costs to comply with any new threshold would vary greatly across different types or sizes of firms, as well as within firms of the same size or type. These findings are discussed in greater detail below.
-pubdate: May 15, 2017 effdate: N/A
- a. General Findings
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, General Findings
- Compliance User: Broker-dealers
- Keywords:
- Implementation Time,
- Business Clock Synchronization Threshold,
- Initial Costs,
- Ongoing Costs,
- Voluntary Assessments,
-
- Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, General Findings, Implementation Time
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Requirement,
- Business Clock Synchronization Threshold,
-
- Approximately 30% of respondents stated that they could not determine how much time it would take for them to comply with any new Business Clock synchronization requirement (e.g., 5 milliseconds, 1 millisecond, 100 microseconds or 500 microseconds). Approximately 20% of respondents indicated that it would take no time to comply with new thresholds of 5 milliseconds or 1 millisecond, and 13.5% of respondents indicated that it would take them no time to comply with new thresholds of 100 microseconds or 500 microseconds. However, approximately 35% of respondents stated that it would take them between 1 and 11 months to comply with any of the new tolerances noted in the Survey.
-Notably, the data did not reflect a substantial difference in implementation times if the Business Clock synchronization threshold was changed to 5 milliseconds or 1 millisecond. With respect to a threshold of 5 milliseconds, approximately 92% of respondents indicated that it would take them 1 year or less to implement the change, and approximately 7% indicated that it would take them 1 to 2 years to implement the change. With respect to a threshold of 1 millisecond, approximately 95% of respondents indicated that it would take them 1 year or less to implement the change, and approximately 5% indicated that it would take them 1 to 2 years to implement the change. Approximately 70% of respondents indicated that it would take them 1 year or less to implement a change to a threshold of 100 microseconds, approximately 25% indicated it would take them 1-2 years to implement such change, and approximately 5% indicated it would take them more than 2 years to implement such change.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, General Findings, Initial Costs
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
-
- The survey sought information concerning the initial costs that respondents would incur should they be required to comply with new Business Clock synchronization thresholds. Approximately 20% of respondents indicated that they would not incur any initial costs to comply with potential new thresholds of 5 milliseconds or 1 millisecond, and approximately 10% of respondents indicated that they would not incur any initial costs to comply with new thresholds of 100 microseconds or 500 microseconds. Approximately 20% of respondents stated that they would incur initial costs between $1,000 and $499,999 to comply with any new threshold (i.e., 5 milliseconds, 1 millisecond, 100 microseconds or 500 microseconds). Many respondents (approximately 35%) did not know what initial costs they would incur to comply with any new threshold.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, General Findings, Ongoing Costs
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
-
- With respect to estimated ongoing costs incurred by respondents to maintain new Business Clock synchronization thresholds (i.e., 5 milliseconds, 1 millisecond, 100 microseconds or 500 microseconds), respondents provided the following information. Approximately 15% of respondents stated that they would not incur any ongoing costs to comply with any new tolerance. Approximately 25% of respondents indicated that they would incur ongoing annual costs between $1,000 and $99,000 to comply with the new tolerances. Only approximately 2% of respondents indicated that their ongoing annual costs to comply with any of the new tolerances would be prohibitive. Approximately 40% of respondents did not know what ongoing annual costs they would incur to comply with any new tolerances.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, General Findings, Voluntary Assessments and Changes to Tolerances
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Requirement,
- Business Clock Synchronization Threshold,
- Business Clock Synchronization Practices,
- broker-dealers,
- Large Broker-Dealer,
- Small Broker-Dealer,
- Business Clock Synchronization Tolerance,
-
- Nearly half of respondents (approximately 49%) reported that they assess their Business Clock synchronization practices daily. Other respondents indicated that they assess their synchronization practices: monthly (approximately 1%); weekly (approximately 4%); quarterly (approximately 4%); and yearly (approximately 6%). Approximately 16% of respondents indicated that they assess their synchronization practices at other intervals, and approximately 3% stated that the frequency of their assessments depends on the type of Business Clock or system being considered. Approximately 17% of respondents did not know how often they assess their synchronization practices.
-Respondents that identified as large broker-dealers stated that they assess their synchronization practices: daily (approximately 53%); weekly (approximately 4%); quarterly (approximately 6%); and annually (approximately 7%). No large broker-dealer respondents reported assessing their practices monthly. Approximately 18% of large broker-dealer respondents stated that they assess their synchronization practices at other intervals, and approximately 1% indicated that their practices depend on the Business Clock or system being considered. Approximately 11% of large broker-dealer respondents did not know how often they assess their synchronization practices. Respondents that identified as small broker-dealers reported that they assess their synchronization practices: daily (approximately 53%); monthly (approximately 12%); and annually (approximately 6%). No small broker-dealer respondents indicated that they assess their practices weekly, quarterly or at different intervals depending on the type of Business Clock or system considered. Approximately 12% of small broker-dealer respondents indicated that they assess their synchronization practices at other intervals. Approximately 18% of small broker-dealer respondents did not know how often they assess their synchronization practices.
-The Survey also asked respondents how often they changed their Business Clock synchronization tolerances in the past year. Overall, in the past year, approximately 38% of respondents changed their synchronization tolerances 1 time, approximately 7% changed their synchronization tolerances 2 to 5 times, and approximately 1% changed their synchronization tolerances 6 to 10 times. Approximately 19% of respondents stated that they changed their tolerances a different number of times not indicated in the Survey and approximately 1% stated that changes depended on the type of Business Clock or system being considered. Approximately 35% of respondents did not know how often they changed their tolerances in the past year.
-Trends with respect to changing synchronization tolerances were not consistent across large and small broker-dealers. Large broker-dealer respondents indicated that in the past year they changed tolerances: 1 time (approximately 49%); 2 to 5 times (approximately 6%); and 6 to 10 times (approximately 1%). Approximately 18% of large broker-dealers changed their tolerances a number of times not indicated in the Survey. No large broker-dealer respondents stated that changes to tolerances in the past year depended on the type of Business Clock or system being considered. Approximately 26% of large broker-dealer respondents did not know how often they changed their tolerances in the past year. Small broker-dealer respondents reported that in the past year they changed tolerances: 1 time (approximately 18%); and 2 to 5 times (approximately 18%). No small broker-dealer respondents reported changing their tolerances 6 to 10 times in the past year. Approximately 18% of small broker-dealer respondents stated that changes to tolerances in the past year depended on the type of Business Clock or system, and approximately 18% changed their tolerances a number of times not indicated in the survey. Approximately 41% of small broker-dealer respondents did not know how often they changed their tolerances in the past year.
-pubdate: May 15, 2017 effdate: N/A
- b. Findings Related to Specific Thresholds
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, Findings Related to Specific Thresholds
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- 5 milliseconds,
- 1 millisecond,
- 500 microseconds,
- 100 microseconds,
-
- This section provides a more detailed discussion of the results described above in Section III.C.4.a. In particular, this section discusses the implementation time, initial cost and ongoing cost of each potential new threshold noted in the Survey (i.e., 5 milliseconds, 1 millisecond, 100 microseconds or 500 microseconds).
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, Findings Related to Specific Thresholds, 5 milliseconds
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- 5 milliseconds,
- broker-dealers,
- Large Broker-Dealer,
- Small Broker-Dealer,
-
- With respect to a possible 5 milliseconds Business Clock synchronization threshold, respondents provided the following information. In terms of the potential time to comply with a 5 milliseconds threshold, approximately 21% of respondents stated that it would take no time for them to comply with such threshold and approximately 5% of respondents stated it would take less than 1 month. Approximately 14% of respondents indicated that it would take between 1 and 2 months, approximately 4% of respondents indicated it would take between 3 and 5 months and approximately 21% of respondents indicated that it would take between 6 and 11 months, to comply with the lower threshold. Approximately 4% of respondents stated that it would take 1 to 1.5 years to comply with the lower threshold. Approximately 30% of respondents stated that they did not know how long it would take to comply with the threshold.
-Approximately 29% of large broker-dealers providing a response to this question stated that it would take them 6 to 11 months to comply with the lower threshold and approximately 23% stated that they could comply in no time. Approximately 23% of large broker-dealer respondents did not know how long it would take them to comply. Other large broker-dealer respondents provided responses that were spread across different time periods. With respect to small broker-dealer respondents, approximately 43% could not estimate how long it would take them to comply with a lower threshold. Approximately 29% of small broker-dealer respondents indicated that they could comply in no time, approximately 14% stated that they could comply in 1 to 2 months, and approximately 14% stated that they could comply in 6 to 11 months. Respondents that operate ATSs reported the following estimated initial implementation times: no time (approximately 18%); 3 to 5 months (approximately 17%); and 6 to 11 months (approximately 67%).
-In terms of initial costs to comply with a 5 milliseconds threshold, approximately 25% of respondents stated that they would incur no initial costs to comply with the threshold; however, the majority of these responses (approximately 71%) were from large broker-dealers. Another approximately 36% of respondents indicated that they did not know what initial costs they would incur to comply with a 5 milliseconds threshold. Other respondents indicated the following estimated initial compliance costs: $1 to $999 (approximately 4%); $1,000 to $9,999 (approximately 5%); $10,000 and $99,999 (approximately 9%); $100,000 and $499,999 (approximately 9%); $500,000 and $999,999 (approximately 5% of respondents—all large broker-dealers); and $1 million to $1.99 million (approximately 5% of respondents—all large broker-dealers). Approximately 2% of respondents indicated that a 5 milliseconds threshold would be cost prohibitive from an initial costs standpoint.
-The majority of respondents providing information on initial implementation costs identified as large broker-dealers (approximately 63%). Large broker-dealer respondents reported the following costs to comply with the lower threshold: $0 (approximately 29%); $1 to $999 (approximately 3%); $1,000 to $9,999 (approximately 3%); $10,000 to $99,999 (approximately 9%); $100,000 to $499,999 (approximately 6%); $500,000 to $999,999 (approximately 9%); and $1 million to $1.99 million (approximately 9%). One large broker-dealer respondent said that the initial costs of compliance would be prohibitive. Approximately 31% of large broker-dealer respondents could not estimate their initial costs to comply with a 5 milliseconds threshold. Small broker-dealer respondents reported the following initial costs to comply with the lower threshold: $0 (approximately 14%); $1,000 to $9,999 (approximately 14%); $10,000 to $99,999 (approximately 14%); and $100,000 to $499,999 (approximately 14%). Approximately 43% of small broker-dealer respondents could not estimate their initial costs to comply with the lower threshold. Respondents that operate ATSs estimated the following initial implementation costs: $0 (approximately 17%); $100,000 to $499,999 (approximately 17%); $500,000 to $999,999 (approximately 33%); and $1 million to $1.99 million (approximately 17%). Approximately 17% of respondents operating ATSs did not know their initial costs.
-In terms of ongoing costs to comply with a 5 milliseconds threshold, approximately 17% of respondents reported an estimated cost of $0 and approximately 38% of respondents could not estimate ongoing costs. Other respondents reported the following costs: $1 to $999 (approximately 4%); $1,000 to $9,999 (approximately 10%); $10,000 to $99,999 (approximately 19%); $100,000 to $499,999 (approximately 4%); $500,000 to $999,999 (approximately 4%); and $1 million to $1.99 million (approximately 2%). Approximately 2% of respondents stated that ongoing costs would be prohibitive.
-The majority of responses regarding estimated ongoing costs (approximately 63%) were from large broker-dealers. Large broker-dealers indicated the following ongoing costs: $0 (approximately 18%); $1,000 to $9,999 (approximately 9%); $10,000 to $99,999 (approximately 24%); $100,000 to $499,999 (approximately 3%); $500,000 to $999,999 (approximately 6%); and $1 million to $1.99 million (approximately 3%). Approximately 3% of large broker-dealer respondents stated that ongoing costs to comply with the lower threshold would be prohibitive. Half of the small broker-dealers that responded to this question could not estimate ongoing costs of compliance. Other small broker-dealer responses were split as follows: $0 (approximately 17%); $1,000 to $9,999 (approximately 17%); and $10,000 to $99,999 (approximately 17%). Respondents that operate ATSs reported the following estimated ongoing costs: $10,000 to $99,999 (approximately 50%); $100,000 to $499,999 (approximately 17%); and $500,000 to $999,999 (approximately 17%). Approximately 17% of respondents operating ATSs could not estimate ongoing costs of compliance.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, Findings Related to Specific Thresholds, 1 millisecond
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- 1 millisecond,
- broker-dealers,
- Large Broker-Dealer,
- Small Broker-Dealer,
-
- Approximately 28% of respondents reported that they did not know how long it would take them to comply with a 1 millisecond threshold. Other respondents reported the following time estimates: no time (approximately 21%); less than 1 month (approximately 8%); 1 to 2 months (approximately 6%); 3 to 5 months (approximately 11%); 6 to 11 months (approximately 21%); 1 to 1.5 years (approximately 4%); and 1.5 to 1.99 years (approximately 2%).
-Most of the respondents providing implementation time estimates identified as large broker-dealers (approximately 66% of the respondents). The large broker-dealer respondents provided the following implementation times: no time (approximately 23%); less than 1 month (approximately 8%); 1 to 2 months (approximately 3%); 3 to 5 months (approximately 14%); 6 to 11 months (approximately 23%); 1 to 1.5 years (approximately 6%); and 1.5 to 1.99 years (approximately 3%). Approximately 20% of large broker-dealer respondents could not estimate an implementation time to comply with the lower threshold. Approximately 33% of small broker-dealer respondents could not estimate an implementation time to comply with the lower threshold and approximately 16% stated that implementation time was unknown. Other small broker-dealer respondents provided the following implementation time estimates: no time (approximately 17%); 1 to 2 months (approximately 17%); and 6 to 11 months (approximately 17%). Respondents operating ATSs indicated the following implementation time estimates: no time (approximately 29%); 3 to 5 months (approximately 14%); and 6 to 11 months (approximately 57%).
-With respect to initial costs to comply with a 1 millisecond threshold, approximately 20% of respondents stated that they would incur no initial costs. Other respondents indicated the following estimated initial compliance costs: $1 to $999 (approximately 4%); $1,000 to $9,999 (approximately 4%); $10,000 and $99,999 (approximately 11%); $100,000 and $499,999 (approximately 9%); $500,000 and $999,999 (approximately 11%); and $1 million to $1.99 million (approximately 4%). Approximately 2% of respondents indicated that the initial costs of complying with a 1 millisecond threshold would be prohibitive. Approximately 35% of respondents could not estimate their initial compliance costs.
-Most of the respondents providing initial cost estimates were large broker-dealers (approximately 67%). Large broker-dealer respondents indicated the following initial costs of compliance: $0 (approximately 25%); $1,000 to $9,999 (approximately 3%); $10,000 to $99,999 (approximately 14%); $100,000 to $499,999 (approximately 6%); $500,000 to $999,999 (approximately 14%); and $1 million to $1.99 million (approximately 6%). One large broker-dealer said that the initial costs of compliance would be prohibitive. Approximately 31% of large broker-dealer respondents could not estimate their initial costs to comply with a 1 millisecond threshold. Small broker-dealer respondents reported the following initial costs to comply with the lower threshold: $0 (approximately 17%); $1 to $999 (approximately 17%); $10,000 to $99,999 (approximately 17%); and $100,000 to $499,999 (approximately 17%). Approximately 33% of small broker-dealer respondents could not estimate their initial costs to comply with the lower threshold. Respondents operating ATSs estimated the following initial implementation costs: $0 (approximately 17%); $100,000 to $499,999 (approximately 17%); $500,000 to $999,999 (approximately 33%); and $1 million to $1.99 million (approximately 17%). Approximately 17% of respondents operating ATSs did not know their initial costs.
-With respect to estimated ongoing costs to comply with a 1 millisecond threshold, approximately 17% of respondents reported an estimated cost of $0 and approximately 38% of respondents could not estimate ongoing costs. Other respondents reported the following costs: $1 to $999 (approximately 4%); $1,000 to $9,999 (approximately 10%); $10,000 to $99,999 (approximately 17%); $100,000 to $499,999 (approximately 6%); $500,000 to $999,999 (approximately 4%); and $2 million to $4.99 million (approximately 2%). Approximately 2% of respondents stated that ongoing costs would be prohibitive.
-The majority of responses regarding estimated ongoing costs (approximately 67%) were from large broker-dealers. Large broker-dealers indicated the following ongoing costs: $0 (approximately 17%); $1,000 to $9,999 (approximately 9%); $10,000 to $99,999 (approximately 23%); $100,000 to $499,999 (approximately 6%); $500,000 to $999,999 (approximately 6%); and $2 million to $4.99 million (approximately 2%). Approximately 3% of large broker-dealer respondents stated that ongoing costs to comply with the lower threshold would be prohibitive. Approximately 40% of small broker-dealer respondents could not estimate ongoing costs of compliance. Other responses were as follows: $0 (approximately 20%); $1,000 to $9,999 (approximately 20%); and $10,000 to $99,999 (approximately 20%). Respondents operating ATSs reported the following estimated ongoing costs: $10,000 to $99,999 (approximately 50%); $100,000 to $499,999 (approximately 17%); and $500,000 to $999,999 (approximately 17%). Approximately 17% of respondents operating ATSs could not estimate ongoing costs of compliance.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, Findings Related to Specific Thresholds, 500 microsecond
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- 500 microseconds,
- broker-dealers,
- Large Broker-Dealer,
- Small Broker-Dealer,
-
- Approximately 30% of respondents reported that they did not know how long it would take them to comply with a 500 microseconds threshold. Other respondents reported the following time estimates: no time (approximately 15%); less than 1 month (approximately 2%); 1 to 2 months (approximately 11%); 3 to 5 months (approximately 8%); 6 to 11 months (approximately 13%); 1 to 1.5 years (approximately 8%); and 1.5 to 1.99 years (approximately 4%).
-Most of the respondents providing implementation time estimates identified as large broker-dealers (approximately 66% of the respondents). The large broker-dealers provided the following implementation times: no time (approximately 14%); 1 to 2 months (approximately 11%); 3 to 5 months (approximately 11%); 6 to 11 months (approximately 17%); 1 to 1.5 years (approximately 9%); and 1.5 to 1.99 years (approximately 6%). Approximately 20% of large broker-dealer respondents could not estimate an implementation time to comply with the lower threshold. Small broker-dealer respondents provided the following implementation time estimates: no time (approximately 33%); 1 to 2 months (approximately 17%); and 6 to 11 months (approximately 17%). Approximately 33% of small broker-dealer respondents could not estimate an implementation time to comply with the lower threshold. Respondents operating ATSs reported the following estimated initial implementation times: no time (approximately 17%); 3 to 5 months (approximately 17%); and 6 to 11 months (approximately 50%). Approximately 17% of respondents that operate ATSs could not estimate their initial implementation costs.
-With respect to initial costs to comply with a 500 microseconds threshold, approximately 15% of respondents stated that they would incur no initial costs. Other respondents indicated the following estimated initial compliance costs: $1,000 to $9,999 (approximately 5%); $10,000 and $99,999 (approximately 7%); $100,000 and $499,999 (approximately 13%); $500,000 and $999,999 (approximately 2%); $1 million to $1.99 million (approximately 9%); $2 million to $4.99 million (approximately 5%); and $5 million or more (approximately 4%). Approximately 2% of respondents indicated that the initial costs of complying with a 500 microseconds threshold would be prohibitive. Approximately 38% of respondents could not estimate their initial compliance costs.
-Most of the respondents providing initial cost estimates were large broker-dealers (approximately 67%). Large broker-dealer respondents indicated the following initial costs of compliance: $0 (approximately 16%); $10,000 to $99,999 (approximately 8%); $100,000 to $499,999 (approximately 16%); $500,000 to $999,999 (approximately 3%); $1 million to $1.99 million (approximately 14%); $2 million to $4.99 million (approximately 5%); and $5 million or more (approximately 5%). One large broker-dealer said that the initial costs of compliance would be prohibitive. Approximately 27% of large broker-dealer respondents could not estimate their initial costs to comply with a 500 microseconds threshold. Small broker-dealer respondents reported the following initial costs to comply with the lower threshold: $0 (approximately 17%); $1,000 to $9,999 (approximately 17%); $10,000 to $99,999 (approximately 17%); and $100,000 to $499,999 (approximately 17%). Approximately 33% of small broker-dealer respondents could not estimate their initial costs to comply with the lower threshold. Respondents operating ATSs estimated the following initial implementation costs: $0 (approximately 14%); $100,000 to $499,999 (approximately 14%); $1 million to $1.99 million (approximately 43%); and $10 million to $20 million (approximately 14%). Approximately 14% of respondents operating ATSs did not know their initial costs.
-With respect to estimated ongoing costs to comply with a 500 microseconds threshold, approximately 12% of respondents reported an estimated cost of $0 and approximately 45% of respondents could not estimate ongoing costs. Other respondents reported the following costs: $1 to $999 (approximately 4%); $1,000 to $9,999 (approximately 2%); $10,000 to $99,999 (approximately 24%); $100,000 to $499,999 (approximately 4%); $500,000 to $999,999 (approximately 4%); $1 million to $1.99 million (approximately 2%); and $2 million to $4.99 million (approximately 2%). Approximately 2% of respondents stated that ongoing costs would be prohibitive.
-The majority of responses regarding estimated ongoing costs (approximately 67%) were from large broker-dealers. Large broker-dealers indicated the following ongoing costs: $0 (approximately 12%); $1,000 to $9,999 (approximately 3%); $10,000 to $99,999 (approximately 29%); $100,000 to $499,999 (approximately 6%); $500,000 to $999,999 (approximately 6%); $1 million to $1.99 million (approximately 3%); and $2 million to $4.99 million (approximately 3%). Approximately 3% of large broker-dealer respondents stated that ongoing costs to comply with the lower threshold would be prohibitive and approximately 36% of large broker-dealer respondents stated that ongoing costs were unknown. Small broker-dealer respondents reported the following ongoing costs: $0 (approximately 20%); $1 to $999 (approximately 20%); and $10,000 to $99,999 (approximately 20%). Approximately 40% of small broker-dealer respondents could not estimate ongoing costs of compliance. Respondents operating ATSs indicated the following estimated ongoing costs: $10,000 to $99,999 (approximately 33%); $100,000 to $499,999 (approximately 17%); and $500,000 to $999,999 (approximately 33%). Approximately 17% of respondents operating ATSs could not estimate ongoing costs of compliance.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Changes to Business Clock Synchronization Threshold, Findings Related to Specific Thresholds, 100 microseconds
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- 100 microseconds,
- broker-dealers,
- Large Broker-Dealer,
- Small Broker-Dealer,
-
- Approximately 32% of respondents reported that they did not know how long it would take them to comply with a 100 microseconds threshold. Other respondents reported the following time estimates: no time (approximately 12%); less than 1 month (approximately 2%); 1 to 2 months (approximately 11%); 3 to 5 months (approximately 9%); 6 to 11 months (approximately 11%); 1 to 1.5 years (approximately 18%); 1.5 to 1.99 years (approximately 4%); and 2 years or more (approximately 2%).
-Most of the respondents providing implementation time estimates identified as large broker-dealers (approximately 68% of the respondents). The large broker-dealers provided the following implementation times: no time (approximately 13%); 1 to 2 months (approximately 8%); 3 to 5 months (approximately 13%); 6 to 11 months (approximately 13%); 1 to 1.5 years (approximately 23%); and 1.5 to 1.99 years (approximately 5%). Approximately 23% of large broker-dealer respondents could not estimate an implementation time to comply with the lower threshold. Small broker-dealer respondents provided the following implementation time estimates: no time (approximately 33%); 1 to 2 months (approximately 17%); and 6 to 11 months (approximately 17%). Approximately 33% of small broker-dealer respondents could not estimate an implementation time to comply with the lower threshold. Respondents operating ATSs reported the following estimated initial implementation times: 3 to 5 months (approximately 17%); 6 to 11 months (approximately 50%); and 1 to 1.5 years (approximately 33%).
-With respect to initial costs to comply with a 100 microseconds threshold, approximately 9% of respondents stated that they would incur no initial costs. Other respondents indicated the following estimated initial compliance costs: $1 to $999 (approximately 7%); $1,000 to $9,999 (approximately 10%); $10,000 and $99,999 (approximately 10%); $100,000 and $499,999 (approximately 9%); $500,000 and $999,999 (approximately 7%); $2 million to $4.99 million (approximately 7%); and $5 million or more (approximately 2%). Approximately 2% of respondents indicated that the initial costs of complying with a 100 microseconds threshold would be prohibitive. Approximately 42% of respondents could not estimate their initial compliance costs.
-Most of the respondents providing initial cost estimates were large broker-dealers (approximately 69%). Large broker-dealer respondents indicated the following initial costs of compliance: $0 (approximately 10%); $1 to $999 (approximately 3%); $1,000 to $9,999 (approximately 13%); $10,000 to $99,999 (approximately 13%); $100,000 to $499,999 (approximately 13%); $500,000 to $999,999 (approximately 10%); $2 million to $4.99 million (approximately 8%); and $5 million or more (approximately 3%). One large broker-dealer said that the initial costs of compliance would be prohibitive. Approximately 28% of large broker-dealer respondents could not estimate their initial costs to comply with a 100 microseconds threshold. Small broker-dealer respondents reported the following initial costs to comply with the lower threshold: $0 (approximately 17%); $1 to $999 (approximately 17%); $1,000 to $9,999 (approximately 17%); and $10,000 to $99,999 (approximately 17%). Approximately 33% of small broker-dealer respondents could not estimate their initial costs to comply with the lower threshold. Respondents operating ATSs estimated the following initial implementation costs: $100,000 to $499,999 (approximately 14%); $500,000 to $999,999 (approximately 14%); $1 million to $1.99 million (approximately 43%); $10 million to $20 million (approximately 14%). Approximately 14% of respondents operating ATSs did not know their initial costs.
-With respect to estimated ongoing costs to comply with a 100 microseconds threshold, approximately 13% of respondents reported an estimated cost of $0 and approximately 42% of respondents could not estimate ongoing costs. Other respondents reported the following costs: $1 to $999 (approximately 2%); $1,000 to $9,999 (approximately 4%); $10,000 to $99,999 (approximately 20%); $100,000 to $499,999 (approximately 11%); $500,000 to $999,999 (approximately 4%); $1 million to $1.99 million (approximately 2%); and $2 million to $4.99 million (approximately 2%). Approximately 2% of respondents stated that ongoing costs would be prohibitive.
-The majority of responses regarding estimated ongoing costs (approximately 69%) were from large broker-dealers. Large broker-dealer respondents indicated the following ongoing costs: $0 (approximately 13%); $1,000 to $9,999 (approximately 3%); $10,000 to $99,999 (approximately 24%); $100,000 to $499,999 (approximately 16%); $500,000 to $999,999 (approximately 5%); $1 million to $1.99 million (approximately 3%); and $2 million to $4.99 million (approximately 3%). Approximately 3% of large broker-dealer respondents stated that ongoing costs to comply with the lower threshold would be prohibitive. Small broker-dealer respondents reported the following ongoing costs: $0 (approximately 20%); $1,000 to $9,999 (approximately 20%); and $10,000 to $99,999 (approximately 20%). Approximately 40% of small broker-dealer respondents could not estimate ongoing costs of compliance. Respondents operating ATSs reported the following estimated ongoing costs: $10,000 to $99,999 (approximately 33%); $100,000 to $499,999 (approximately 17%); and $500,000 to $999,999 (approximately 33%). Approximately 17% of respondents operating ATSs could not estimate ongoing costs of compliance.
-pubdate: May 15, 2017 effdate: N/A
- 5. Current Business Clock Synchronization Practices
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- broker-dealers,
- Large Broker-Dealer,
- Small Broker-Dealer,
-
- A majority of respondents (approximately 64%) indicated that their current Business Clock synchronization threshold is less than 50 milliseconds; however, these responses were skewed toward large broker-dealers, which made up approximately 80% of the responses. Respondents varied as to the particular thresholds that they currently use. In particular, respondents reported the following current thresholds: 1 microsecond to 499 microseconds (approximately 9%); 500 microseconds to 999 microseconds (approximately 8%); 1 millisecond to 49 milliseconds (approximately 47%); 50 milliseconds to 499 milliseconds (approximately 13%); 500 milliseconds to 1 second (approximately 4%) and more than one second (approximately 1%). Approximately 19% of respondents did not know their firm’s current Business Clock synchronization thresholds.
-Focusing on type of respondent, large broker-dealer respondents indicated that they have current thresholds of: 1 microsecond to 499 microseconds (approximately 12%); 500 microseconds to 999 microseconds (approximately 6%); 1 millisecond to 49 milliseconds (approximately 51%); 50 milliseconds to 499 milliseconds (approximately 12%); and 500 milliseconds to 1 second (approximately 3%). Approximately 17% of large broker-dealer respondents did not know their firm’s current threshold. Small broker-dealer respondents reported the following current thresholds: 500 microseconds to 999 microseconds (approximately 19%); 1 millisecond to 49 milliseconds (approximately 11%); 50 milliseconds to 499 milliseconds (approximately 26%); 500 milliseconds to 1 second (approximately 11%) and more than one second (approximately 7%). Approximately 26% of small broker-dealer respondents did not know their firm’s current threshold.
-Approximately 55% of respondents indicated that their Business Clock synchronization tolerances did not vary based on whether Business Clocks were located in particular systems. Respondents did not express a clear majority view on the frequency with which they check the synchronization of Business Clocks. Focusing on large and small broker-dealers, the majority of large broker-dealer respondents (approximately 57%) and small broker-dealer respondents (approximately 65%) stated that their synchronization tolerances do not vary based on where a Business Clock is located. Approximately 19% of large broker-dealer respondents indicated that their synchronization tolerances vary based on where Business Clocks are located; by comparison, no small broker-dealer respondents indicated that their tolerances vary based on the location of Business Clocks. Approximately 25% of large broker-dealer respondents and approximately 35% of small broker-dealer respondents did not know if their tolerances vary based on where Business Clocks are located.
-Generally, respondents reported that NTP was the most common technology used to maintain Business Clock synchronization, although, with respect to co-located systems in particular, PTP was the most common technology used. The most common response among large broker-dealer respondents (approximately 40%) was that they employ multiple technologies to maintain synchronization. Small broker-dealer respondents most commonly (approximately 30%) indicated that they use NTP to maintain synchronization; however, approximately 41% of small broker-dealer respondents did not know what technology they use to maintain synchronization. Overall, the NIST atomic clock was the most common master clock used by respondents.
-These findings are discussed further below.
-pubdate: May 15, 2017 effdate: N/A
- a. Maintaining Business Clock Synchronization
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Maintaining Business Clock Synchronization
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- PTP,
- NTP,
- GPS,
- CDMA,
- Large Broker-Dealer,
-
- Approximately 15% of respondents did not know what technology their firms use to maintain Business Clock synchronization. Focusing on the respondents that did know what technology their firms use, the most common response (approximately 50% of respondents) was that firms used a combination of different technologies to maintain synchronization—typically, these respondents use a combination of PTP, NTP and GPS. In terms of a single solution, NTP was the most common technology used by respondents with approximately 46% reporting that they use this solution. GPS and PTP were the next most common solutions, with each being used by approximately 22% of respondents.25
-Large broker-dealer respondents reported using the following solutions to maintain synchronization: multiple technologies (approximately 40%); NTP (approximately 27%); PTP (approximately 6%); GPS (approximately 6%); CDMA (approximately 2%); and other technologies (approximately 3%). Approximately 16% of large broker-dealer respondents did not know what technology they use to maintain synchronization. Small broker-dealer respondents reported using the following solutions to maintain synchronization: NTP (approximately 30%); other technologies (approximately 15%); GPS (approximately 7%); and multiple technologies (approximately 7%). Approximately 41% of small broker-dealer respondents did not know what technology they use to maintain synchronization.
-Results also varied when analyzed by type of system, as described further below.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Maintaining Business Clock Synchronization, Origination Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- PTP,
- GPS,
- CDMA,
-
- Respondents operating origination systems indicated that their firms use the following technologies to maintain Business Clock synchronization: PTP was the primary technology used (approximately 46% of respondents) followed by GPS and PTP (each used by approximately 22% of respondents), other technology (approximately 7% of respondents) and CDMA (approximately 3% of respondents). Approximately 25% of respondents did not know what technology their firms use to maintain synchronization.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Maintaining Business Clock Synchronization, Routing Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- PTP,
- GPS,
- CDMA,
- NTP,
-
- Respondents operating routing systems stated that their firms use the following technologies to maintain Business Clock synchronization: NTP (approximately 43%); GPS (approximately 25%); PTP (approximately 24%); CDMA (approximately 4%); and other solutions (approximately 4%). Approximately 20% of respondents did not know what technology their firms use to maintain synchronization. Based on the Survey results, routing systems appear to have the highest use of CDMA technology of any system based on the number of responses.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Maintaining Business Clock Synchronization, Execution Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- PTP,
- GPS,
- CDMA,
- NTP,
-
- Respondents operating execution systems reported that their firms use the following technologies to maintain Business Clock synchronization: NTP (approximately 44%); PTP (approximately 25%); GPS (approximately 21%); other solutions (approximately 8%); and CDMA (approximately 1%). Approximately 13% of respondents did not know what technology their firms use to maintain synchronization.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Maintaining Business Clock Synchronization, Co-located Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- PTP,
- GPS,
- CDMA,
- NTP,
-
- Respondents operating co-located systems indicated that their firms use the following technologies to maintain Business Clock synchronization: NTP (approximately 35%); PTP (approximately 33%); GPS (approximately 25%); CDMA (approximately 5%); and other solutions (approximately 2%). Approximately 10% of respondents did not know what technology their firms use to maintain Business Clock synchronization. Based on information provided by the respondents, co-located systems have the lowest use of NTP and the highest use of PTP across any systems addressed in the Survey.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Maintaining Business Clock Synchronization, Internalization Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- PTP,
- GPS,
- NTP,
-
- Respondents operating internalization systems stated that their firms use the following technologies to maintain Business Clock synchronization: NTP (approximately 42%); GPS (approximately 31%); PTP (approximately 23%); and other technology (approximately 4%). Approximately 17% of respondents indicated that they did not know what technology their firms use to maintain Business Clock synchronization. Based on information provided by respondents, internalization systems have the highest use of GPS technology across any system addressed in the Survey and, along with third-party systems (discussed below) the lowest use of CDMA technology (no respondents reported using GPS technology to maintain synchronization of internalization systems).
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Maintaining Business Clock Synchronization, Back-Office Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- PTP,
- GPS,
- CDMA,
- NTP,
-
- Respondents operating back-office systems reported that their firms use the following technologies to maintain Business Clock synchronization: NTP (approximately 56%); GPS (approximately 19%); PTP (approximately 19%); CDMA (approximately 3%); and other technology (approximately 3%). Approximately 15% of respondents did not know what technology their firms use to maintain Business Clock synchronization. Based on the information provided by respondents, back-office systems have the highest use of NTP and the lowest use of GPS across any of the systems addressed in the Survey.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Maintaining Business Clock Synchronization, Third-Party Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- PTP,
- GPS,
- CDMA,
- NTP,
-
- Respondents that use third-party systems indicated that their firms use the following technologies to maintain Business Clock synchronization: NTP (approximately 49%); GPS (approximately 26%); PTP (approximately 17%); and other technology (approximately 9%). No respondents reported using CDMA to maintain Business Clock synchronization in third-party systems. Approximately 15% of respondents indicated that they did not know what technology they use to maintain Business Clock synchronization.
-pubdate: May 15, 2017 effdate: N/A
- b. Current Business Clock Synchronization Tolerances
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Current Business Clock Synchronization Tolerances
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Tolerance,
- broker-dealers,
- Large Broker-Dealer,
- Small Broker-Dealer,
-
- As previously noted, a majority of respondents (approximately 60%) indicated that their current Business Clock synchronization tolerance is better than the standard currently set forth in the Plan. However, this result is not necessarily representative of the industry as a whole since the vast majority of these responses (approximately 80%) were provided by large broker-dealer respondents. Conversely, approximately 20% of respondents stated that their current synchronization tolerance is at or above the current standard set forth in the Plan, and the approximately 20% of respondents indicated that they did not know their current synchronization tolerance.
-Respondents that identified as large broker-dealers reported that they currently maintain the following Business Clock synchronization tolerances: 1 microsecond to 499 microseconds (approximately 12%); 500 microseconds to 999 microseconds (approximately 6%); 1 millisecond to 49 milliseconds (approximately 51%); 50 milliseconds to 499 milliseconds (approximately 12%); and 500 milliseconds to 1 second (approximately 3%). Approximately 17% of large broker-dealer respondents did not know their current synchronization tolerances. Small broker-dealer respondents reported that they currently maintain the following synchronization tolerances: 500 microseconds to 999 microseconds (approximately 19%); 1 millisecond to 49 milliseconds (approximately 11%); 50 milliseconds to 499 milliseconds (approximately 26%); and 500 milliseconds to 1 second (approximately 11%); and more than 1 second (approximately 7%). Approximately 26% of small broker-dealer respondents did not know their current synchronization tolerances.
-These findings are discussed further below, focusing on the types of systems used by respondents.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Current Business Clock Synchronization Tolerances, Origination Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- Origination Systems,
-
- Approximately 60% of respondents operating origination systems reported that they currently use a synchronization tolerance that is better than the standard set forth in the Plan. Specifically, respondents reported the following current tolerances: 1 microsecond to 499 microseconds (approximately 10%); 500 microseconds to 999 microseconds (approximately 7%); 1 millisecond to 49 milliseconds (approximately 44%); 50 milliseconds to 499 milliseconds (approximately 13%); and 500 milliseconds to 1 second (approximately 3%). Approximately 24% of respondents indicated that they did not know their current synchronization tolerances.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Current Business Clock Synchronization Tolerances, Routing Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- Routing Systems,
-
- Approximately 70% of respondents operating routing systems reported that they currently use a tolerance that is better than the standard set forth in the Plan. Specifically, respondents reported the following tolerances: 1 microsecond to 499 microseconds (approximately 10%); 500 microseconds to 999 microseconds (approximately 8%); 1 millisecond to 49 milliseconds (approximately 53%); 50 milliseconds to 499 milliseconds (approximately 10%); and more than 1 second (approximately 1%). Approximately 18% of respondents did not know their current synchronization tolerances.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Current Business Clock Synchronization Tolerances, Execution Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- Execution Systems,
-
- Approximately 57% of respondents operating execution systems reported that they currently use a synchronization tolerance that is better than the standard set forth in the Plan. Specifically, respondents reported the following current tolerances: 1 microsecond to 499 microseconds (approximately 9%); 500 microseconds to 999 microseconds (approximately 4%); 1 millisecond to 49 milliseconds (approximately 44%); 50 milliseconds to 499 milliseconds (approximately 16%); 500 milliseconds to 1 second (approximately 7%); and more than 1 second (approximately 2%). Approximately 19% of respondents did not know their current synchronization tolerances.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Current Business Clock Synchronization Tolerances, Co-located Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- Co-located Systems,
-
- Approximately 82% of respondents operating co-located systems reported that they currently use a tolerance that is better than the standard set forth in the Plan. In particular, respondents reported that they currently use the following tolerances: 1 microsecond to 499 microseconds (approximately 22%); 500 microseconds to 999 microseconds (approximately 19%); 1 millisecond to 49 milliseconds (approximately 41%); and 50 milliseconds to 499 milliseconds (approximately 14%). Approximately 5% of respondents indicated that they did not know their current synchronization tolerances.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Current Business Clock Synchronization Tolerances, Internalization Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- Internalization Systems,
-
- Approximately 73% of respondents operating internalization systems reported that they currently use a synchronization tolerance that is better than the standard set forth in the Plan. Specifically, respondents reported the following current tolerances: 1 microsecond to 499 microseconds (approximately 6%); 500 microseconds to 999 microseconds (approximately 11%); 1 millisecond to 49 milliseconds (approximately 56%); 50 milliseconds to 499 milliseconds (approximately 11%); and 500 milliseconds to 1 second (approximately 6%). Approximately 11% of respondents did not know their current synchronization tolerances.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Current Business Clock Synchronization Tolerances, Back-Office Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- Back-Office Systems,
-
- Approximately 63% of respondents operating back-office systems reported that they currently use a tolerance that is better than the standard set forth in the Plan. Specifically, respondents reported the following tolerances: 1 microsecond to 499 microseconds (approximately 4%); 500 microseconds to 999 microseconds (approximately 8%); 1 millisecond to 49 milliseconds (approximately 51%); 50 milliseconds to 499 milliseconds (approximately 15%); and 500 milliseconds to 1 second (approximately 9%). Approximately 13% of respondents did not know their current synchronization tolerances.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Current Business Clock Synchronization Tolerances, Third-Party Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- Third-Party Systems,
-
- Approximately 44% of respondents using third-party systems stated that they currently use a tolerance that is better than the standard set forth in the Plan. In particular, respondents reported the following tolerances: 1 microsecond to 499 microseconds (approximately 3%); 1 millisecond to 49 milliseconds (approximately 41%); and 50 milliseconds to 499 milliseconds (approximately 16%). Approximately 41% of respondents did not know their current synchronization tolerances.
-pubdate: May 15, 2017 effdate: N/A
- c. Business Clock Location
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Location
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Tolerance,
- broker-dealers,
- Large Broker-Dealer,
- Small Broker-Dealer,
-
- A majority of respondents (approximately 55%) stated that their Business Clock synchronization tolerances did not vary based on where a Business Clock was located. Conversely, approximately 15% of respondents indicated that their tolerances did vary based on where a Business Clocks was located. Approximately 30% of respondents did not know if their tolerances vary based on the location of a Business Clock.
-The majority of large broker-dealer respondents (approximately 57%) stated that their synchronization tolerances did not vary based on the location of Business Clocks, while approximately 19% reported that tolerances did vary based on location. Approximately 25% of large broker-dealer respondents did not know if tolerances varied by the location of Business Clocks. Similarly, the majority of small broker-dealer respondents (approximately 65%) indicated that their synchronization tolerances did not vary based on the location of Business Clocks, however, no small broker-dealer respondents reported that tolerances varied based on location of Business Clocks. Approximately 35% of small broker-dealer respondents did not know if their synchronization tolerances varied by the location of Business Clocks.
-These results are described below, focusing on type of system.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Location, Origination Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- Business Clock Location,
- Origination Systems,
-
- Approximately 56% of respondents operating origination systems indicated that their Business Clock synchronization tolerances did not vary based on where Business Clocks were located. Approximately 14% of respondents stated that their tolerances did vary based on where Business Clocks were located. Approximately 30% did not know if their synchronization tolerances varied based on the location of Business Clocks.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Location, Routing Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- Business Clock Location,
- Routing Systems,
-
- Approximately 55% of respondents operating routing systems stated that their synchronization tolerances did not vary based on where Business Clocks were located, while approximately 15% of respondents stated that their tolerances did vary based on where Business Clocks were located. Approximately 30% of respondents did not know if their tolerances varied based on the system in which Business Clocks were located.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Location, Execution Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- Business Clock Location,
- Execution Systems,
-
- Approximately 56% of respondents operating execution indicated that their Business Clock tolerances did not vary based on where Business Clocks were located, and approximately 15% of respondents indicated that their tolerances did vary based on where Business Clocks were located. Approximately 29% of respondents did not know if their tolerances varied based on the system in which Business Clocks were located.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Location, Co-located Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- Business Clock Location,
- Co-located Systems,
-
- The majority of respondents operating co-located systems (approximately 67%) indicated that their synchronization tolerances did not vary based on where Business Clocks were located, while approximately 19% of respondents indicated that their tolerances did vary based on where Business Clocks were located. Approximately 14% of respondents did not know if their synchronization tolerances varied based on where Business Clocks were located.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Location, Internalization Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- Business Clock Location,
- Internalization Systems,
-
- Respondents operating internalization systems were roughly split, with approximately 39% reporting that their synchronization tolerances did not vary based on where Business Clocks were located and 39% reporting that their tolerances did vary based on where Business Clocks were located. Approximately 22% of respondents did not know if their Business Clock synchronization tolerances varied based on where Business Clocks were located.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Location, Back-Office Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- Business Clock Location,
- Back-Office Systems,
-
- Approximately 68% of respondents operating back-office systems reported that their tolerances did not vary based on the location of Business Clocks. Approximately 10% of respondents stated that their tolerances did vary based on where Business Clocks were located. Approximately 22% of respondents did not know if their tolerances varied based on where Business Clocks were located.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Location, Third-Party Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Threshold,
- Business Clock Location,
- Third-Party Systems,
-
- Approximately 41% of respondents using third-party systems indicated that their tolerances did not vary based on where Business Clocks were located, and approximately 18% of respondents stated that their tolerances did vary based on where Business Clocks were located. Approximately 41% of respondents did not know if Business Clock synchronization tolerances varied based on where Business Clocks were located.
-pubdate: May 15, 2017 effdate: N/A
- d. Business Clock Synchronization Frequency
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Synchronization Frequency
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Accuracy,
- Business Clock Synchronization Frequency,
- broker-dealers,
- Large Broker-Dealer,
- Small Broker-Dealer,
-
- With respect to the frequency with which respondents check their Business Clock synchronization accuracy, the most common response (approximately 23%) was that respondents check synchronization accuracy once a minute or more but less than once a second. Other respondents indicated checking synchronization accuracy with the following frequencies: once an hour or more but less than once a minute (approximately 20%); once a second or more but less than once a hundredth of a second (approximately 14%); more than once a day but less than once an hour (approximately 14%); once a day (approximately 12%); and more than once a hundredth of a second (approximately 3%). Only approximately 15% of respondents reported that they did not know how often their firms checked Business Clock synchronization accuracy.
-Large broker-dealer respondents reported that they check synchronization accuracy at the following frequencies: once a day (approximately 9%); more than once a day but less than once an hour (approximately 15%); once an hour or more but less than once a minute (approximately 23%); once a minute or more but less than once a second (approximately 18%); once a second or more but less than once a hundredth of a second (approximately 17%); and more than once a hundredth of a second (approximately 4%). Approximately 14% of large broker-dealer respondents did not know how often they check the accuracy of Business Clock synchronization. Small broker-dealer respondents indicated that they check synchronization accuracy at the following frequencies: once a day (approximately 47%); more than once a day but less than once an hour (approximately 10%); and once a minute or more but less than once a second (approximately 20%). Approximately 23% of small broker-dealer respondents did not know how often they check the accuracy of Business Clock synchronization.
-These results are discussed further below, focusing on the types of systems that respondents operate.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Synchronization Frequency, Originating Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Accuracy,
- Origination Systems,
-
- Respondents operating origination systems indicated that they check Business Clock synchronization accuracy at the following frequencies: once a day (approximately 18%); more than once a day but less than once an hour (approximately 14%); once an hour or more but less than once a minute (approximately 26%); once a minute or more but less than once a second (approximately 14%); once a second or more but less than once a hundredth of a second (approximately 10%); and more than once a hundredth of a second (approximately 1%). Approximately 17% of respondents did not know how often they check the accuracy of their Business Clock synchronization.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Synchronization Frequency, Routing Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Accuracy,
- Routing Systems,
-
- Respondents operating routing systems reported that they check Business Clock synchronization accuracy at the following frequencies: once a day (approximately 9%); more than once a day but less than once an hour (approximately 13%); once an hour or more but less than once a minute (approximately 26%); once a minute or more but less than once a second (approximately 19%); once a second or more but less than once a hundredth of a second (approximately 16%); and more than once a hundredth of a second (approximately 3%). Approximately 16% of respondents did not know how often they check the accuracy of their Business Clock synchronization.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Synchronization Frequency, Execution Systems,
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Accuracy,
- Execution Systems,
-
- Respondents operating execution systems stated that they check Business Clock synchronization accuracy at the following frequencies: once a day (approximately 16%); more than once a day but less than once an hour (approximately 15%); once an hour or more but less than once a minute (approximately 16%); once a minute or more but less than once a second (approximately 18%); once a second or more but less than once a hundredth of a second (approximately 18%); and more than once a hundredth of a second (approximately 4%). Approximately 13% of respondents did not know how often they check the accuracy of their Business Clock synchronization.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Synchronization Frequency, Co-located Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Accuracy,
- Co-located Systems,
-
- Respondents operating co-located systems indicated that they check Business Clock synchronization accuracy at the following frequencies: once a day (approximately 3%); more than once a day but less than once an hour (approximately 8%); once an hour or more but less than once a minute (approximately 22%); once a minute or more but less than once a second (approximately 22%); once a second or more but less than once a hundredth of a second (approximately 31%); and more than once a hundredth of a second (approximately 3%). Approximately 11% of respondents did not know how often they check the accuracy of their Business Clock synchronization.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Synchronization Frequency, Internalization Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Accuracy,
- Internalization Systems,
-
- Respondents operating internalization systems reported that they check Business Clock synchronization accuracy at the following frequencies: once a day (approximately 11%); more than once a day but less than once an hour (approximately 17%); once a minute or more but less than once a second (approximately 44%); once a second or more but less than once a hundredth of a second (approximately 11%); and more than once a hundredth of a second (approximately 6%). Approximately 11% of respondents did not know how often they check the accuracy of their Business Clock synchronization.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Synchronization Frequency, Back-Office Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Accuracy,
- Back-Office Systems,
-
- Respondents operating back-office systems indicated that they check Business Clock synchronization accuracy at the following frequencies: once a day (approximately 13%); more than once a day but less than once an hour (approximately 15%); once an hour or more but less than once a minute (approximately 25%); once a minute or more but less than once a second (approximately 21%); once a second or more but less than once a hundredth of a second (approximately 6%); and more than once a hundredth of a second (approximately 4%). Approximately 17% of respondents did not know how often they check the accuracy of their Business Clock synchronization.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Business Clock Synchronization Frequency, Third-Party Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Accuracy,
- Third-Party Systems,
-
- Respondents using third-party systems reported that they check Business Clock synchronization accuracy at the following frequencies: once a day (approximately 13%); more than once a day but less than once an hour (approximately 15%); once an hour or more but less than once a minute (approximately 26%); once a minute or more but less than once a second (approximately 20%); once a second or more but less than once a hundredth of a second (approximately 6%); and more than once a hundredth of a second (approximately 4%). Approximately 17% of respondents did not know how often they check the accuracy of their Business Clock synchronization.
-pubdate: May 15, 2017 effdate: N/A
- e. Master Clocks
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Master Clocks
- Compliance User: Broker-dealers
- Keywords:
- Business Clock synchronization,
- PTP,
- GPS,
- NTP,
- CDMA,
- broker-dealers,
- Large Broker-Dealer,
- Small Broker-Dealer,
-
- Respondents that provided information regarding the type of master clock that they use for purposes of maintaining Business Clock synchronization most commonly reported using the NIST atomic clock (approximately 45%). The next most popular solutions were: GPS (approximately 20%); other vendor or hardware-provided time (approximately 10%); data center-provided time (approximately 4%); and CDMA (approximately 1%). Approximately 15% of respondents did not know what their firms use as a master clock.
-Large broker-dealer respondents reported using the following as a master clock: NIST atomic clock (approximately 43%); GPS (approximately 27%); other vendor or hardware-provided time (approximately 11%); data center-provided time (approximately 3%); and CDMA (approximately 3%). Approximately 13% of large broker-dealers did not know what they use as a master clock. The responses from small broker-dealer respondents differed somewhat as they indicated using the following: NIST atomic clock (approximately 37%); other vendor or hardware-provided time (approximately 19%); and data center-provided time (approximately 7%). Approximately 37% of small broker-dealer respondents did not know what they use as a master clock.
-These results are described further below, based on the types of systems that respondents operate.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Master Clocks, Origination Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Requirement,
- Master Clock,
- Origination Systems,
-
- Respondents operating origination systems reported that they use the following as a master clock for purposes of complying with the Business Clock synchronization requirement: NIST atomic clock (approximately 50%); GPS (approximately 20%); other vendor or hardware-provided time (approximately 10%); data center-provided time (approximately 4%); and CDMA (approximately 1%). Approximately 15% of respondents did not know what they use as a master clock.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Master Clocks, Routing Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Requirement,
- Master Clock,
- Routing Systems,
- NIST,
- CDMA,
- GPS,
-
- Respondents operating routing systems stated that they use the following as a master clock for purposes of complying with the Business Clock synchronization requirement: NIST atomic clock (approximately 40%); GPS (approximately 25%); other vendor or hardware-provided time (approximately 10%); data center-provided time (approximately 5%); and CDMA (approximately 5%). Approximately 15% of respondents did not know what they use as a master clock.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Master Clocks, Execution Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Requirement,
- Master Clock,
- Execution Systems,
- NIST,
- CDMA,
- GPS,
-
- Respondents operating execution systems stated that they use the following as a master clock for purposes of complying with the Business Clock synchronization requirement: NIST atomic clock (approximately 50%); GPS (approximately 20%); other vendor or hardware-provided time (approximately 15%); data center-provided time (approximately 5%); and CDMA (approximately 2%). Approximately 10% of respondents did not know what they use as a master clock.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Master Clocks, Co-located Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Requirement,
- Master Clock,
- Co-located Systems,
- NIST,
- CDMA,
- GPS,
-
- Respondents operating co-located systems stated that they use the following as a master clock for purposes of complying with the Business Clock synchronization requirement: NIST atomic clock (approximately 40%); GPS (approximately 30%); other vendor or hardware-provided time (approximately 10%); CDMA (approximately 5%); and data center-provided time (approximately 3%). Approximately 15% of respondents did not know what they use as a master clock.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Master Clocks, Internalization Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Requirement,
- Master Clock,
- Internalization Systems,
- NIST,
- CDMA,
- GPS,
-
- Respondents operating internalization systems stated that they use the following as a master clock for purposes of complying with the Business Clock synchronization requirement: GPS (approximately 40%); NIST atomic clock (approximately 35%); and other vendor or hardware-provided time (approximately 10%). No respondents reported using data center-provided time or CDMA as their master clocks. Approximately 10% of respondents did not know what they use as a master clock.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Master Clocks, Back-Office Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Requirement,
- Master Clock,
- Back-Office Systems,
- NIST,
- CDMA,
- GPS,
-
- Respondents operating back-office systems stated that they use the following as a master clock for purposes of complying with the Business Clock synchronization requirement: NIST atomic clock (approximately 50%); GPS (approximately 20%); other vendor or hardware-provided time (approximately 15%). No respondents indicated that they used data center-provided time or CDMA as their master clocks. Approximately 15% of respondents did not know what they use as a master clock.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Master Clocks, Third-Party Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Requirement,
- Master Clock,
- Third-Party Systems,
- NIST,
- CDMA,
- GPS,
-
- Respondents using third-party systems stated that they use the following as a master clock for purposes of complying with the Business Clock synchronization requirement: NIST atomic clock (approximately 50%); GPS (approximately 20%); and other vendor or hardware-provided time (approximately 15%). No respondents reported using data center-provided time or CDMA as their master clocks. Approximately 15% of respondents did not know what they use as a master clock.
-pubdate: May 15, 2017 effdate: N/A
- f. Synchronization Across Geographically Disparate Systems
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Synchronization Across Geographically Disparate Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Across Geographically Disparate System,
- broker-dealers,
- Large Broker-Dealer,
- Small Broker-Dealer,
-
- Approximately 40% of respondents responding to the question on maintaining Business Clock synchronization across geographically disparate systems indicated that they do maintain synchronization across systems that are geographically disparate.26 Approximately 30% of respondents reported that they do not synchronize Business Clocks across geographically disparate systems. Approximately 30% of respondents indicated that this question was not applicable.
-The most common response from large broker-dealer respondents was that they did maintain Business Clock synchronization across geographically disparate systems (approximately 44%). Approximately 29% of large broker-dealer respondents reported that they did not maintain synchronization across geographically disparate systems, and approximately 27% indicated that this question was not applicable to them. Approximately 38% of small broker-dealer respondents stated that they maintain synchronization across geographically disparate systems, and approximately 28% reported that they do not. Approximately 34% of small broker-dealer respondents indicated that this question was not applicable to them.
-These results are discussed further below, based on the types of systems that respondents operate.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Synchronization Across Geographically Disparate Systems, Origination Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Across Geographically Disparate System,
- Origination Systems,
-
- Approximately 30% of respondents operating origination systems indicated that they maintained Business Clock synchronization across geographically disparate systems. Approximately 35% of respondents stated that they did not maintain synchronization across geographically disparate systems. Approximately 30% of respondents indicated that this question did not apply to their operations.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Synchronization Across Geographically Disparate Systems, Routing Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Across Geographically Disparate System,
- Routing Systems,
-
- Approximately 35% of respondents operating routing systems reported that they maintained Business Clock synchronization across geographically disparate systems. Approximately 40% of respondents indicated that they did not maintain synchronization across geographically disparate systems. Approximately 25% of respondents indicated that this question did not apply to their operations.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Synchronization Across Geographically Disparate Systems, Execution Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Across Geographically Disparate System,
- Execution Systems,
-
- Approximately 40% of respondents operating execution systems stated that they maintained Business Clock synchronization across geographically disparate systems. Approximately 20% of respondents indicated that they did not maintain synchronization across geographically disparate systems. Approximately 40% of respondents indicated that this question did not apply to their operations.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Synchronization Across Geographically Disparate Systems, Co-located Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Across Geographically Disparate System,
- Co-located Systems,
-
- Approximately 50% of respondents operating co-located systems stated that they maintained Business Clock synchronization across geographically disparate systems. Approximately 20% of respondents stated that they did not maintain synchronization across geographically disparate systems. Approximately 30% of respondents indicated that this question did not apply to their operations.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Synchronization Across Geographically Disparate Systems, Internalization Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Across Geographically Disparate System,
- Internalization Systems,
-
- Approximately 50% of respondents operating internalization systems indicated that they maintained Business Clock synchronization across geographically disparate systems. Approximately 15% of respondents stated that they did not maintain synchronization across geographically disparate systems. Approximately 30% of respondents indicated that this question did not apply to their operations.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Synchronization Across Geographically Disparate Systems, Back-Office Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Across Geographically Disparate System,
- Back-Office Systems,
-
- Approximately 40% of respondents operating back-office systems indicated that they maintained Business Clock synchronization across geographically disparate systems. Approximately 40% of respondents stated that they did not maintain synchronization across geographically disparate systems. Approximately 20% of respondents indicated that this question did not apply to their operations.
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, CAT Clock Synchronization Survey, Analysis of Data from Clock Synchronization Survey14, Current Business Clock Synchronization Practices, Synchronization Across Geographically Disparate Systems, Third-Party Systems
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Across Geographically Disparate System,
- Third-Party Systems,
-
- Approximately 35% of respondents stated that they maintained Business Clock synchronization across geographically disparate systems. Approximately 40% of respondents indicated that they did not maintain synchronization across geographically disparate systems. Approximately 25% of respondents indicated that this question did not apply to their operations.
-The Selection Plan provides that amendments to the Selection Plan shall be effected by means of a written amendment that: (1) sets forth the change, addition, or deletion; (2) is executed by over two-thirds of the Participants; and (3) is approved by the SEC pursuant to Rule 608, or otherwise becomes effective under Rule 608.13
+The proposed amendments have been executed by eighteen of the Participants, and have consequently been approved by the SROs. One Participant which is also a Shortlisted Bidder, abstained from the decision whether to adopt these amendments to avoid potential conflicts of interest.
+pubdate: February 21, 2015 effdate: N/A
+ 8. Terms and Conditions of Access
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan, Requirements Pursuant to Rule 608(a), Terms and Conditions of Access
+ Compliance User: Self-Regulatory Organization
+ Keywords:
+ Not applicable.
+pubdate: February 22, 2015 effdate: N/A
+ 9. Method of Determination and Imposition, and Amount of, Fees and Charges
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan, Requirements Pursuant to Rule 608(a)
+ Compliance User: Self-Regulatory Organization
+ Keywords:
+ Not applicable.
+pubdate: February 23, 2015 effdate: N/A
+ 10. Method and Frequency of Processor Evaluation
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan, Requirements Pursuant to Rule 608(a)
+ Compliance User: Self-Regulatory Organization
+ Keywords:
+ Not applicable.
+pubdate: February 24, 2015 effdate: N/A
+ 11. Dispute Resolution
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan, Requirements Pursuant to Rule 608(a)
+ Compliance User: Self-Regulatory Organization
+ Keywords:
+ Not applicable.
pubdate: May 15, 2017 effdate: N/A
- VI. Recommendations: Current Clock Synchronization Requirements
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, Recommendations: Current Clock Synchronization Requirements
- Compliance User: Broker-dealers
+ pubdate: February 25, 2015 effdate: N/A
+ IV. Solicitation of Comments
+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Solicitation of Comments
+ Compliance User: Self-Regulatory Organization
Keywords:
- CAT NMS Plan - Section 6.6,
- Business Clock synchronization,
- Participants,
- CAT Reporter,
- Industry Member,
+ Submission of Comments,
+ Electronic Comments,
+ Paper Comments,
+ File Number 4-668,
+ 5 U.S.C. 552,
- As required by Section 6.6(a)(ii) of the CAT NMS Plan, the Participants provide these recommendations with respect to the current Business Clock synchronization requirements based on their analysis of the data collected in the Survey. As discussed further below, the Participants do not believe that it is appropriate to amend the current Business Clock synchronization requirements set forth in the Plan at this time based on the results of the Survey.
-The Participants note that data collected in the survey is limited in certain ways for general applicability.27 For instance, the data is heavily skewed towards larger broker-dealers (approximately 60% of all respondents), thus making its applicability to small broker-dealers (approximately 13% of all respondents) more questionable. In addition, many respondents indicated in their responses to various questions that they did not know their firm’s current practices and did not know, or cannot estimate, potential costs (i.e., with respect to implementation times and initial and ongoing monetary costs).
-Moreover, the Participants note that the current Business Clock synchronization standards were only recently implemented, and the Participants believe that the Participants and Industry Members should gain experience with those new standards prior to implementing more stringent or granular standards. In particular, the Participants desire to evaluate the effectiveness of current Business Clock synchronization requirements on the linkage and sequencing of independent events in the CAT, or whether more granular synchronization requirements are important to the accurate linkage and sequencing of the events. After gaining experience with
-the synchronization standards and their effect on the accuracy of the CAT, the Participants believe that they will be able to analyze whether narrower clock synchronization requirements are necessary to obtain the intended regulatory goals of the CAT and whether any narrower requirements should be applied to certain groups or types of Industry Members consistent with industry standard practices. The Participants also anticipate that Industry Members, Small Industry Members and Service Providers that maintain synchronized Business Clocks will be able to provide more detailed and accurate responses after all CAT Reporters that are Industry Members and Small Industry Members are subject to the synchronization standards set forth in the Plan.
-Nevertheless, despite these concerns and recognition of the limitations of the Survey results, the Participants provide the following suggestions for consideration at a future date regarding potential amendments related to the type of CAT Reporter, type of Industry Member and type of system.
-pubdate: May 15, 2017 effdate: N/A
- A. Type of CAT Reporter
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, Recommendations: Current Clock Synchronization Requirements, Type of CAT Reporter
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Requirements,
- Participants,
- CAT Reporter,
- Industry Member,
-
- The Participants evaluated whether it is appropriate to amend the Business Clock synchronization requirements in the Plan based on the type of CAT Reporter – Participant and Industry Members. The current clock synchronization standards impose different standards on Participants and Industry Members. Participants are required to meet a 100 microseconds standard, whereas Industry Members are required to meet a 50 milliseconds standard. The Participants do not recommend changing these standards at this time.
-As discussed above, the Survey focused on collecting data regarding Industry Members. The Participants, however, have reported that they comply with the 100 microseconds requirement currently set forth in the Plan. Based on prior analysis of the Participants’ clock synchronization practices, the Participants believe that 100 microseconds is an appropriate synchronization standard to apply to the Participants. Moreover, at this time, the Participants do not believe that the same standard should apply to the Participants and to CAT Reporters that are Industry Members and/or Small Industry Members since the Survey results do not reflect a uniformity of synchronization thresholds among all CAT Reporters.
-With regard to Industry Members, the data collected indicates that many potential CAT Reporters currently synchronize their Business Clocks at thresholds that are better (i.e., narrower) than currently required by the Plan, although not necessarily to the granularity of the Participants. For example, approximately 64% of respondents indicated that their current synchronization threshold is less than 50 milliseconds, with respondents most commonly reporting that they maintain thresholds of between 1 millisecond and 49 milliseconds (approximately 47%). By comparison, relatively few respondents indicated that they currently maintain synchronization thresholds below 1 millisecond (approximately 17%). The Participants, however, do not believe that this supports decreasing the synchronization thresholds applicable to all Industry Members as a group at this time. As discussed in this assessment, the sample set is heavily skewed toward large broker-dealers (approximately 80% of respondents providing data on current synchronization thresholds), and the Participants have not had an opportunity to fully evaluate the extent to which the Survey respondents represent large broker-dealers, so additional information is necessary before the Plan may be amended.
-pubdate: May 15, 2017 effdate: N/A
- B. Type of Industry Member
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, Recommendations: Current Clock Synchronization Requirements, Type of Industry Member
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Requirements,
- broker-dealers,
- Large Broker-Dealer,
- Small Broker-Dealer,
- CAT NMS plan,
- CAT Reporting,
-
- The Participants evaluated whether it is appropriate to amend the Business Clock synchronization requirements in the Plan based on the type of Industry Member (e.g., ATS, small broker-dealer) when establishing appropriate industry standards. Recognizing the limitations of the Survey, the data suggests that many large-broker dealer respondents may already meet or exceed the standard set forth in the Plan. However, as discussed below, the Participants believe that additional analysis is necessary for implementing any narrower thresholds that are generally applicable to Industry Members or applicable to a particular subset thereof.
-The Survey data preliminarily suggests many large broker-dealers currently synchronize their Business Clocks at thresholds that are better (i.e., narrower) than currently required by the Plan. For example, 69% of the large broker-dealer respondents indicated that they have current thresholds of less than the current 50 millisecond standard. In particular, large broker-dealer respondents reported that they used the following standards: 1 microsecond to 499 microseconds (approximately 12%); 500 microseconds to 999 microseconds (approximately 6%); 1 millisecond to 49 milliseconds (approximately 51%); 50 milliseconds to 499 milliseconds (approximately 12%); and 500 milliseconds to 1 second (approximately 3%). Approximately 16% of large broker-dealer respondents did not know their firm’s current threshold. Moreover, many large broker-dealer respondents indicated that it would take them no time to comply with narrower standards of 5 milliseconds (approximately 23%), 1 millisecond (approximately 23%), 500 microseconds (approximately 14%) and 100 microseconds (approximately 13%). Although these results do not reflect a consensus among large broker-dealer respondents, the Participants believe that future analysis may indicate that compliance implementation times will decrease due to technological advances in the industry and after large broker-dealers gain experience reporting to the Central Repository. However, large broker-dealer respondents, without a majority or consensus view, also indicated that they would incur a range of costs to comply with narrower synchronization thresholds, with some estimating costs of $5 million or more to comply with thresholds below 1 millisecond. Accordingly, the Participants believe that, although large broker-dealers may be able to comply with a narrower synchronization standard without significant costs in terms of implementation time, monetary costs may be significant and possibly prohibitive. The SEC expressed a similar view when it recently approved the Plan. It explained, “[w]hile the Commission believes that regulators’ ability to sequence orders accurately in certain cases could improve if the clock synchronization for Industry Members were finer, the Commission is sensitive to the costs associated with requiring a finer clock synchronization [standard] for Industry Members at this time, and believes that a standard of 50 milliseconds for Industry Members will allow regulators to sequence orders and events with a level of accuracy that is acceptable for the initial phases of CAT reporting.”28
-The Survey results suggest that it would be premature to lower the clock synchronization standards with regard to small broker-dealers. As noted, the number of respondents that identified as small broker-dealers was limited; only 13% of the respondents identified as small broker-dealers, which does not provide a representative view of small broker-dealers in the industry. Moreover, only approximately 30% of small broker-dealer respondents reported that they used a synchronization threshold less than the 50 milliseconds standard. Specifically, small broker-dealer respondents reported the following current thresholds: 500 microseconds to 999 microseconds (approximately 19%); 1 millisecond to 49 milliseconds (approximately 11%); 50 milliseconds to 499 milliseconds (approximately 26%); 500 milliseconds to 1 second (approximately 11%); and more than one second (approximately 7%). Approximately 26% of small broker-dealer respondents did not know their firm’s current threshold. Some, but not a majority or a representative sample, of small broker-dealer respondents indicated that it would take them no time to comply with narrower standards of 5 milliseconds (approximately 29%), 1 millisecond (approximately 17%), 500 microseconds (approximately 33%) and 100 microseconds (approximately 33%). However, as discussed throughout this assessment, the number of respondents that identified as small broker-dealers was limited, which suggests that this data may not be representative of small broker-dealers generally. In addition, given that, throughout the development of the CAT NMS Plan, small broker-dealers and industry associations have noted that they believe that small broker-dealers will be disproportionately burdened when it comes to complying with the Plan requirements, the Participants believe that it is necessary to understand the potential impact of any amendment to the Plan on small broker-dealers. For instance, as was the case with large broker-dealer respondents, small broker-dealer respondents indicated a range of potential costs to comply with a narrower synchronization threshold without a clear consensus or majority view. Although many small broker-dealers estimated that they would incur substantial costs to comply with narrower standards, a significant portion of small broker-dealer respondents could not estimate anticipated compliance costs.
-The Survey results also suggest that it may not be appropriate to subject ATSs to narrower synchronization standards at this time. Few ATS respondents indicated that it would take them no time to comply with narrower thresholds of: 5 milliseconds (approximately 18%); 1 millisecond (approximately 29%); 500 microseconds (approximately 17%); and 100 microseconds (0%). Moreover, many ATSs reported that they would incur significant costs to comply with narrower synchronization thresholds. For instance, for thresholds of 500 microseconds and 100 microseconds, the majority of ATS respondents estimated that they would incur initial compliance costs between $1 million and $20 million (approximately 57% each for thresholds of 500 microseconds and 100 microseconds). However, as is the case with data from small broker-dealer respondents, in some respects the data provided by ATS respondents is limited. For instance, as of May 3, 2017, the SEC reported that there are 83 ATSs with current Forms ATS on file, but only 12 respondents (approximately 8%) indicated that they operate an ATS.29 The Participants believe that it is necessary to better understand the synchronization practices of ATSs, as well as the potential costs that ATSs would incur to comply with narrower synchronization standards.30
-pubdate: May 15, 2017 effdate: N/A
- C. Type of System
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, Recommendations: Current Clock Synchronization Requirements, Type of System
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Requirements,
- Order Origination System,
- Order Routing System,
- Order Execution System,
- Co-located System,
- Internalization Systems,
- Back-Office Systems,
- Third Party Systems,
-
- The Participants evaluated whether it is appropriate to amend the Business Clock synchronization requirements in the Plan based on the type of system, including: order origination systems; order routing systems; order execution or matching systems; co-located systems; internalization systems; back-office systems; and third-party systems (including vendor systems). Based on the Survey, the Participants do not believe that it is appropriate to apply different synchronization thresholds to different types of systems at this time.
-The Survey results did not indicate any consistent patterns that would necessarily support implementing a narrower or higher threshold for particular systems. For instance, with the exception of third-party systems, the majority of respondents that submitted system-level responses indicated that Business Clocks in those systems tend to be narrower than required by the Plan. However, given the ranges provided in the Survey, the Participants cannot precisely determine the current synchronization thresholds commonly used in the various systems addressed in the Survey. Moreover, of the respondents that provided information regarding current synchronization thresholds, approximately 55% indicated that their Business Clock synchronization tolerances did not vary based on whether Business Clocks were located in particular systems. Approximately 19% of large broker-dealer respondents indicated that their synchronization tolerances varied based on where Business Clocks were located; by comparison, no small broker-dealer respondents indicated that their tolerances varied based on location of Business Clocks. This further indicates that additional analysis is necessary to better determine whether, if required to do so, CAT Reporters would be capable of complying with synchronization thresholds that vary by type of system, or whether the costs of doing so would be significant or otherwise prohibitive.31
-pubdate: May 15, 2017 effdate: N/A
- D. Conclusion
-Topic: SEC Reports, CAT NMS Plan Clock Synchronization, Recommendations: Current Clock Synchronization Requirements, Conclusion
- Compliance User: Broker-dealers
- Keywords:
- Business Clock Synchronization Requirements,
- Business Clock Synchronization Threshold,
- CAT Reporter,
- Business Clock Synchronization Practices,
-
- As discussed above, the Participants do not believe that it is necessary or appropriate to amend the Business Clock synchronization requirements set forth in the Plan at this time. The Participants will reassess whether the Business Clock synchronization requirements remain consistent with industry standards – or whether it may be necessary to amend such requirements – in the future as part of the annual assessment required by Section 6.8(c) of the Plan. To make such an assessment, the Participants intend to continue working with the Advisory Committee and the industry generally, including CAT Reporters of various sizes and types, to determine whether current Business Clock synchronization practices have changed sufficiently to suggest that narrower synchronization thresholds may be consistent with industry standards. As the Commission noted when it approved the Plan, if the Participants determine based on a future assessment that the clock synchronization requirements in the Plan should be changed, the Participants would need to file a proposed amendment to the Plan with the Commission. Such a submission would enable the Commission, as well as Industry Members and the public, to evaluate the proposed requirements, including anticipated costs, benefits and related implementation time frames.
-
- Interested persons are invited to submit written data, views, and arguments concerning the foregoing, including whether the Amendment to the Plan is consistent with the Act. Comments may be submitted by any of the following methods: Electronic comments:
+• Use the Commission’s Internet comment form (http://www.sec.gov/rules/sro.shtml); or
+• Send an e-mail to rule-comments@sec.gov. Please include File Number 4-668 on the
+subject line.
+Paper comments:
+• Send paper comments in triplicate to Brent J. Fields, Secretary, Securities and Exchange Commission, 100 F Street, NE, Washington, DC 20549-1090.
+All submissions should refer to File Number 4-668. This file number should be included on the subject line if e-mail is used. To help the Commission process and review your comments more efficiently, please use only one method. The Commission will post all comments on the Commission’s Internet website (http://www.sec.gov/rules/sro.shtml). Copies of the submission, all subsequent amendments, all written statements with respect to the Amendment to the Plan that are filed with the Commission, and all written communications relating to the Amendment to the Plan between the Commission and any person, other than those that may be withheld from the public in accordance with the provisions of 5 U.S.C. 552, will be available for website viewing and printing in the Commission’s Public Reference Room, 100 F Street, NE, Washington, DC 20549 on official business days between 10:00 a.m. and 3:00 p.m. Copies of the filing will also be available for inspection and copying at the Participants’ principal offices. All comments received will be posted without change; the Commission does not edit personal identifying information from submissions. You should submit only information that you wish to make available publicly. All submissions should refer to File Number 4-668 and should be submitted on or before [insert date 30 days from publication in the Federal Register].
+By the Commission.
+Brent J. Fields
+Secretary
| fn |
- 1 The CAT NMS Plan is a national market system plan approved by the Commission pursuant to Section 11A of the Exchange Act and the rules and regulations thereunder. See Securities Exchange Act Release No. 79318 (Nov. 15, 2016), 81 Fed. Reg. 84696 (Nov. 23, 2016) (the “Adopting Release”). The full text of the CAT NMS Plan is available at www.catnmsplan.com. - |
| fn |
- 2 The Participants to the CAT NMS Plan are Bats BYX Exchange, Inc., Bats BZX Exchange, Inc., Bats EDGA Exchange, Inc., Bats EDGX Exchange, Inc., BOX Options Exchange LLC, C2 Options Exchange, Incorporated, Chicago Board Options Exchange, Incorporated, Chicago Stock Exchange, Inc., Financial Industry Regulatory Authority, Inc., Investors’ Exchange LLC, Miami International Securities Exchange, LLC, MIAX PEARL, LLC, NASDAQ BX, Inc., Nasdaq GEMX, LLC, Nasdaq ISE, LLC, Nasdaq MRX, LLC, NASDAQ PHLX LLC, The NASDAQ Stock Market LLC, NYSE National, Inc., New York Stock Exchange LLC, NYSE MKT LLC, and NYSE Arca, Inc. Note that National Stock Exchange, Inc. has been renamed NYSE National, Inc. See Securities Exchange Act Rel. No. 79902 (Jan. 30, 2017), 82 Fed. Reg. 9258 (Feb. 3, 2017). Note further that ISE Gemini, LLC, ISE Mercury, LLC and International Securities Exchange, LLC have been renamed Nasdaq GEMX, LLC, Nasdaq MRX, LLC, and Nasdaq ISE, LLC, respectively. See Securities Exchange Act Rel. No. 80248 (Mar. 15, 2017), 82 Fed. Reg. 14547 (Mar. 21, 2017); Securities Exchange Act Rel. No. 80326 (Mar. 29, 2017), 82 Fed. Reg. 16460 (Apr. 4, 2017); and Securities Exchange Act Rel. No. 80325 (Mar. 29, 2017), 82 Fed. Reg. 16445 (Apr. 4, 2017). - |
| fn |
- 3 Unless otherwise defined herein, capitalized terms are defined as set forth in the CAT NMS Plan. - |
| fn |
- 4 Adopting Release at 84785. - |
| fn |
- 5 See Bats BYX Exchange, Inc. Rule 4.6; Bats BZX Exchange, Inc. Rule 4.6; Bats EDGA Exchange, Inc. Rule 4.6; Bats EDGX Exchange, Inc. Rule 4.6; BOX Options Exchange LLC Rule 16020; C2 Options Exchange, Incorporated Rulebook Chapter 6, Section F; Chicago Board Options Exchange, Incorporated Rule 6.86; Chicago Stock Exchange, Inc. Rulebook Article 23, Rule 2; Financial Industry Regulatory Authority, Inc. Rule 6820; Investors’ Exchange LLC Rule 11.620; Miami International Securities Exchange, LLC Rule 1702; MIAX PEARL, LLC Rulebook Chapter XVII; NASDAQ BX, Inc. Equity Rule 6820, Option Rulebook Chapter IX, Section 8(b); Nasdaq GEMX, LLC Rule 901; Nasdaq ISE, LLC Rule 901; Nasdaq MRX, LLC Rule 901; NASDAQ PHLX LLC Rule 920A; The NASDAQ Stock Market LLC Equity Rule 6820, Option Rulebook Chapter IX, Section 8(b); NYSE National, Inc. Rule 14.2; New York Stock Exchange LLC Rule 6820; NYSE MKT LLC Rule 6820; and NYSE Arca, Inc. Equity Rule 6.6820, Option Rule 11.6820. +pubdate: February 26, 2015 effdate: N/A
+ Exhibit A+Topic: SEC Release, Release No. 34-74223, Joint Industry Plan; Notice of Amendment, Description of the Plan
+ Compliance User: Self-Regulatory Organization
+ Keywords:
+ Proposed Amendments,
+
+ Proposed new language is italicized; proposed deletions are in [brackets]. +PROPOSED AMENDMENT TEXT +Plan Processor Evaluation and Selection Plan +I. Definitions +* * * * * +(X) “Shortlisted Bid” means a Bid submitted by a Qualified Bidder and selected as a Shortlisted Bid by the Selection Committee pursuant to Section VI(B) and, if applicable, pursuant to Section VI(C)(3) of the Plan. +* * * * * +III. Operating Committee +* * * * * +(E) Conflicts and Recusals +A Participant may recuse itself from voting on any matter under consideration by the Operating Committee if the Participant determines that voting on such matter raises a conflict of interest. Except as provided in Sections V(B)(2), and V(B)(3), and V(B)(4) of the Plan, no Participant is automatically recused from voting on any matter. +* * * * * +V. Selection Committee +* * * * * +(B) Voting +* * * * * +(2) No Bidding Participant shall vote on whether a Shortlisted Bidder will be permitted to revise its Bid pursuant to Section VI(C)(2) or Section VI(D)(1) below if a Bid submitted by or including the Participant or an Affiliate of the Participant is a Shortlisted Bid. +(3) No Bidding Participant shall vote in the process narrowing the set of Shortlisted Bidders as set forth in Section VI(C)(3) if a Bid submitted by or including the Participant or an Affiliate of the Participant is a Shortlisted Bid. +(4) No Bidding Participant shall vote in the second round set forth in Section VI(E)(4) below if a Bid submitted by or including the Participant or an Affiliate of the Participant is part of the second round. +(5) All votes by the Selection Committee shall be confidential and non-public. All such votes will be tabulated by an independent third party approved by the Operating Committee, and a Participant's individual votes will not be disclosed to other Participants or to the public. +* * * * * +VI. RFP Bid Evaluation and Plan Processor Selection +* * * * * +(C) Formulation of the CAT NMS Plan +(1) The Selection Committee shall review the Shortlisted Bids to identify optimal proposed solutions for the consolidated audit trail and provide descriptions of such proposed solutions for inclusion in the CAT NMS Plan. This process may, but is not required to, include iterative discussions with Shortlisted Bidders to address any aspects of an optimal proposed solution that were not fully addressed in a particular Bid. +(2) Prior to the approval of the CAT NMS Plan, all Shortlisted Bidders will be permitted to revise their Bids one or more times if the Selection Committee determines, by majority vote, that such revision(s) are necessary or appropriate. +(3) Prior to approval of the CAT NMS Plan, and either before or after any revisions to Shortlisted Bids are accepted, the Selection Committee may determine, by at least a two-thirds vote, to narrow the number of Shortlisted Bids to three Bids, in accordance with the process in this Paragraph (C)(3). +(a) Each Voting Senior Officer shall select a first, second, and third choice from among the Shortlisted Bids. +(b) A weighted score shall be assigned to each choice as follows: +• First—3 points +• Second—2 points +• Third—1 point +(c) The three Shortlisted Bids receiving the highest cumulative scores will be the new set of Shortlisted Bids. +(d) In the event of a tie that would result in more than three final Shortlisted Bids, the votes shall be recounted, omitting each Voting Senior Officer’s third choice, in order to break the tie. If this recount produces a tie that would result in a number of final Shortlisted Bids larger than or equal to that from the initial count, the results of the initial count shall constitute the final set of Shortlisted Bids. +(e) To the extent there are Non-SRO Bids that are Shortlisted Bids, the final Shortlisted Bids selected pursuant to this Section VI(C)(3) must, if possible, include at least one Non-SRO Bid. If following the vote set forth in this Section VI(C)(3), no Non-SRO Bid was selected as a final Shortlisted Bid, the Non-SRO Bid receiving the highest cumulative votes shall be retained as a Shortlisted Bid. +(f) The third party tabulating votes, as specified in Section V(B)(5), shall identify to the Selection Committee the new set of Shortlisted Bids, but shall keep confidential the individual scores and rankings of the Shortlisted Bids from the process in this Paragraph (C)(3). +(4) The Participants shall incorporate information on optimal proposed solutions in the CAT NMS Plan, including cost-benefit information as required by SEC Rule 613. +
|
- 
-